From hiran.chaudhuri at gmx.net  Fri Apr  1 09:58:19 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Fri, 01 Apr 2022 11:58:19 +0200
Subject: jpackage usage problems
Message-ID: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>

Hello there.

While I am trying to package my project using jpackage 16.0.1 on Ubuntu
20 LTS I have difficulty in assembling the correct commands.

The documentation covers a lot but not everything. For example, it is
not clear to me when I have to provide an option - especially since I
meanwhile take a two step approach of building the appimage, then
tweaking something (that could have done by JPackage directly) and
finally building the DEB package.

While I believe the documentation is good enough, the error messages
presented by JPackage are not. Here is one example. Hopefully you agree
that the NullPointerException does not at all tell me what is wrong and
what I could improve on.

My feeling is that JPackage should do some better error handling and
come up with improved messages.

Hiran


$ jpackage --app-image build/app-image --verbose --dest build
[10:34:45.915] Warning: app-image dir not generated by jpackage.
[10:34:45.930] Running dpkg
[10:34:45.937] Command:
    dpkg --print-architecture
[10:34:45.937] Output:
    amd64
[10:34:45.939] Returned: 0

[10:34:45.944] Running dpkg
[10:34:45.961] Command:
    dpkg -s coreutils
[10:34:45.962] Output:
    Package: coreutils
    Essential: yes
    Status: install ok installed
    Priority: required
    Section: utils
    Installed-Size: 7196
    Maintainer: Ubuntu Developers <
ubuntu-devel-discuss at lists.ubuntu.com>
    Architecture: amd64
    Multi-Arch: foreign
    Version: 8.30-3ubuntu2
    Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>=
2.28), libselinux1 (>= 2.1.13)
    Description: GNU core utilities
     This package contains the basic file, shell and text manipulation
     utilities which are expected to exist on every operating system.
     .
     Specifically, this package includes:
     arch base64 basename cat chcon chgrp chmod chown chroot cksum comm
cp
     csplit cut date dd df dir dircolors dirname du echo env expand
expr
     factor false flock fmt fold groups head hostid id install join
link ln
     logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc
numfmt
     od paste pathchk pinky pr printenv printf ptx pwd readlink
realpath rm
     rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync
tac
     tail tee test timeout touch tr true truncate tsort tty uname
unexpand
     uniq unlink users vdir wc who whoami yes
    Homepage: http://gnu.org/software/coreutils
    Original-Maintainer: Michael Stone <mstone at debian.org>
[10:34:45.962] Returned: 0

[10:34:45.963] Running dpkg-deb
[10:34:45.965] Warning: app-image dir not generated by jpackage.
[10:34:45.967] Warning: app-image dir not generated by jpackage.
[10:34:45.967] java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
        at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
        at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
        at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
xDebBundler.java:83)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
ckageBundler.java:72)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:663)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
.java:538)
        at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
        at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
[10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler DEB
Bundle failed because of java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:685)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
.java:538)
        at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
        at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
Caused by: java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
        at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
        at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
        at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
xDebBundler.java:83)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
ckageBundler.java:72)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:663)
        ... 3 more

$



From alexey.semenyuk at oracle.com  Fri Apr  1 16:37:46 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 1 Apr 2022 12:37:46 -0400
Subject: jpackage usage problems
In-Reply-To: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
Message-ID: <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>

Hi Hiran,

Looks like jpackage fails because of missing package name on the command 
line.
I agree that the error message is not helpful. Can you try one of jdk19 
EA builds [1] to see if the problem is reproducible?

[1] https://jdk.java.net/19/

- Alexey

On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
> Hello there.
>
> While I am trying to package my project using jpackage 16.0.1 on Ubuntu
> 20 LTS I have difficulty in assembling the correct commands.
>
> The documentation covers a lot but not everything. For example, it is
> not clear to me when I have to provide an option - especially since I
> meanwhile take a two step approach of building the appimage, then
> tweaking something (that could have done by JPackage directly) and
> finally building the DEB package.
>
> While I believe the documentation is good enough, the error messages
> presented by JPackage are not. Here is one example. Hopefully you agree
> that the NullPointerException does not at all tell me what is wrong and
> what I could improve on.
>
> My feeling is that JPackage should do some better error handling and
> come up with improved messages.
>
> Hiran
>
>
> $ jpackage --app-image build/app-image --verbose --dest build
> [10:34:45.915] Warning: app-image dir not generated by jpackage.
> [10:34:45.930] Running dpkg
> [10:34:45.937] Command:
>      dpkg --print-architecture
> [10:34:45.937] Output:
>      amd64
> [10:34:45.939] Returned: 0
>
> [10:34:45.944] Running dpkg
> [10:34:45.961] Command:
>      dpkg -s coreutils
> [10:34:45.962] Output:
>      Package: coreutils
>      Essential: yes
>      Status: install ok installed
>      Priority: required
>      Section: utils
>      Installed-Size: 7196
>      Maintainer: Ubuntu Developers <
> ubuntu-devel-discuss at lists.ubuntu.com>
>      Architecture: amd64
>      Multi-Arch: foreign
>      Version: 8.30-3ubuntu2
>      Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>=
> 2.28), libselinux1 (>= 2.1.13)
>      Description: GNU core utilities
>       This package contains the basic file, shell and text manipulation
>       utilities which are expected to exist on every operating system.
>       .
>       Specifically, this package includes:
>       arch base64 basename cat chcon chgrp chmod chown chroot cksum comm
> cp
>       csplit cut date dd df dir dircolors dirname du echo env expand
> expr
>       factor false flock fmt fold groups head hostid id install join
> link ln
>       logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc
> numfmt
>       od paste pathchk pinky pr printenv printf ptx pwd readlink
> realpath rm
>       rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync
> tac
>       tail tee test timeout touch tr true truncate tsort tty uname
> unexpand
>       uniq unlink users vdir wc who whoami yes
>      Homepage: http://gnu.org/software/coreutils
>      Original-Maintainer: Michael Stone <mstone at debian.org>
> [10:34:45.962] Returned: 0
>
> [10:34:45.963] Running dpkg-deb
> [10:34:45.965] Warning: app-image dir not generated by jpackage.
> [10:34:45.967] Warning: app-image dir not generated by jpackage.
> [10:34:45.967] java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>          at
> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>          at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>          at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>          at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>          at
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
> xDebBundler.java:83)
>          at
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
> ckageBundler.java:72)
>          at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
> ava:663)
>          at
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
> .java:538)
>          at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> [10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler DEB
> Bundle failed because of java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>          at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
> ava:685)
>          at
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
> .java:538)
>          at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>          at
> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>          at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>          at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>          at java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>          at
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
> xDebBundler.java:83)
>          at
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
> ckageBundler.java:72)
>          at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
> ava:663)
>          ... 3 more
>
> $
>
>


From turbanoff at gmail.com  Sat Apr  2 15:56:20 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Sat, 2 Apr 2022 18:56:20 +0300
Subject: Unused sun.nio.fs.Reflect
Message-ID: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>

Hello.
As I can see, the class 'sun.nio.fs.Reflect' is unused in JDK java code.
Is it somehow used by VM, or is it just leftovers from some refactorings?
I wonder if we can drop it.


Andrey Turbanov

From Alan.Bateman at oracle.com  Sat Apr  2 17:40:10 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 2 Apr 2022 18:40:10 +0100
Subject: Unused sun.nio.fs.Reflect
In-Reply-To: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>
References: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>
Message-ID: <36e48cfe-9a41-64cc-88e5-6e9eae1300e0@oracle.com>

On 02/04/2022 16:56, Andrey Turbanov wrote:
> Hello.
> As I can see, the class 'sun.nio.fs.Reflect' is unused in JDK java code.
> Is it somehow used by VM, or is it just leftovers from some refactorings?
> I wonder if we can drop it.
>
It was needed at one point but if no longer used on any platform then it 
should be okay to remove.

-Alan.

From claes.redestad at oracle.com  Sat Apr  2 20:45:58 2022
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 2 Apr 2022 22:45:58 +0200
Subject: Unused sun.nio.fs.Reflect
In-Reply-To: <36e48cfe-9a41-64cc-88e5-6e9eae1300e0@oracle.com>
References: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>
 <36e48cfe-9a41-64cc-88e5-6e9eae1300e0@oracle.com>
Message-ID: <66ab8067-2680-b283-de60-6e3b5d45de06@oracle.com>

On 2022-04-02 19:40, Alan Bateman wrote:
> On 02/04/2022 16:56, Andrey Turbanov wrote:
>> Hello.
>> As I can see, the class 'sun.nio.fs.Reflect' is unused in JDK java code.
>> Is it somehow used by VM, or is it just leftovers from some refactorings?
>> I wonder if we can drop it.
>>
> It was needed at one point but if no longer used on any platform then it 
> should be okay to remove.

I can't find any usage.

There's a sibling 'sun.nio.ch.Reflect' where a couple of methods are
still dubiously in use in one place only in
sun.nio.ch.InheritedChannel::createChannel to reflectively create a
java.io.FileDescriptor. Perhaps that could be refactored to use
jdk.internal.access.JavaIOFileDescriptorAccess, in which case we could
get rid of both of these. Would be more efficient (if it matters) but
also consolidate internal hacking to fewer places.

Thanks!

/Claes

From hiran.chaudhuri at gmx.net  Mon Apr  4 06:49:22 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Mon, 04 Apr 2022 08:49:22 +0200
Subject: jpackage usage problems
In-Reply-To: <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
Message-ID: <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>

Hello Alex,

I tried running the same command with the jdk19 you pointed at. As a
first, I get this output:

$JAVA_HOME/bin/jpackage --version
19-ea

With that, I invoked the command as before, and i fairly got the same
output. So the behaviour in the latest version has not changed.

Two things I'd like to point out:
- there is no JPackage version in the output itself so both you and me
have to trust the correct one was called
- I found out the mistake: I should have used
  --app-image build/app-image/SettlersRemake
  but JPackage gave a warning in the beginning and processed all the
  rest

Hiran


$JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest
build
[08:41:58.675] Warning: app-image dir not generated by jpackage.
[08:41:58.688] Running dpkg
[08:41:58.696] Command [PID: 21712]:
    dpkg --print-architecture
[08:41:58.696] Output:
    amd64
[08:41:58.698] Returned: 0

[08:41:58.702] Running dpkg
[08:41:58.719] Command [PID: 21714]:
    dpkg -s coreutils
[08:41:58.719] Output:
    Package: coreutils
    Essential: yes
    Status: install ok installed
    Priority: required
    Section: utils
    Installed-Size: 7196
    Maintainer: Ubuntu Developers <
ubuntu-devel-discuss at lists.ubuntu.com>
    Architecture: amd64
    Multi-Arch: foreign
    Version: 8.30-3ubuntu2
    Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>=
2.28), libselinux1 (>= 2.1.13)
    Description: GNU core utilities
     This package contains the basic file, shell and text manipulation
     utilities which are expected to exist on every operating system.
     .
     Specifically, this package includes:
     arch base64 basename cat chcon chgrp chmod chown chroot cksum comm
cp
     csplit cut date dd df dir dircolors dirname du echo env expand
expr
     factor false flock fmt fold groups head hostid id install join
link ln
     logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc
numfmt
     od paste pathchk pinky pr printenv printf ptx pwd readlink
realpath rm
     rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync
tac
     tail tee test timeout touch tr true truncate tsort tty uname
unexpand
     uniq unlink users vdir wc who whoami yes
    Homepage: http://gnu.org/software/coreutils
    Original-Maintainer: Michael Stone <mstone at debian.org>
[08:41:58.719] Returned: 0

[08:41:58.720] Running dpkg-deb
[08:41:58.722] Warning: app-image dir not generated by jpackage.
[08:41:58.723] Warning: app-image dir not generated by jpackage.
[08:41:58.723] java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
        at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
        at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
        at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
xDebBundler.java:84)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
ckageBundler.java:72)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:688)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
.java:561)
        at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
        at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
[08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB
Bundle failed because of java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:710)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments
.java:561)
        at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
        at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
Caused by: java.lang.NullPointerException: Cannot invoke
"java.lang.CharSequence.length()" because "this.text" is null
        at
java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
        at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
        at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
        at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Linu
xDebBundler.java:84)
        at
jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(LinuxPa
ckageBundler.java:72)
        at
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.j
ava:688)
        ... 3 more


On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote:
> Hi Hiran,
>
> Looks like jpackage fails because of missing package name on the
> command
> line.
> I agree that the error message is not helpful. Can you try one of
> jdk19
> EA builds [1] to see if the problem is reproducible?
>
> [1] https://jdk.java.net/19/
>
> - Alexey
>
> On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
> > Hello there.
> >
> > While I am trying to package my project using jpackage 16.0.1 on
> > Ubuntu
> > 20 LTS I have difficulty in assembling the correct commands.
> >
> > The documentation covers a lot but not everything. For example, it
> > is
> > not clear to me when I have to provide an option - especially since
> > I
> > meanwhile take a two step approach of building the appimage, then
> > tweaking something (that could have done by JPackage directly) and
> > finally building the DEB package.
> >
> > While I believe the documentation is good enough, the error
> > messages
> > presented by JPackage are not. Here is one example. Hopefully you
> > agree
> > that the NullPointerException does not at all tell me what is wrong
> > and
> > what I could improve on.
> >
> > My feeling is that JPackage should do some better error handling
> > and
> > come up with improved messages.
> >
> > Hiran
> >
> >
> > $ jpackage --app-image build/app-image --verbose --dest build
> > [10:34:45.915] Warning: app-image dir not generated by jpackage.
> > [10:34:45.930] Running dpkg
> > [10:34:45.937] Command:
> >      dpkg --print-architecture
> > [10:34:45.937] Output:
> >      amd64
> > [10:34:45.939] Returned: 0
> >
> > [10:34:45.944] Running dpkg
> > [10:34:45.961] Command:
> >      dpkg -s coreutils
> > [10:34:45.962] Output:
> >      Package: coreutils
> >      Essential: yes
> >      Status: install ok installed
> >      Priority: required
> >      Section: utils
> >      Installed-Size: 7196
> >      Maintainer: Ubuntu Developers <
> > ubuntu-devel-discuss at lists.ubuntu.com>
> >      Architecture: amd64
> >      Multi-Arch: foreign
> >      Version: 8.30-3ubuntu2
> >      Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44),
> > libc6 (>=
> > 2.28), libselinux1 (>= 2.1.13)
> >      Description: GNU core utilities
> >       This package contains the basic file, shell and text
> > manipulation
> >       utilities which are expected to exist on every operating
> > system.
> >       .
> >       Specifically, this package includes:
> >       arch base64 basename cat chcon chgrp chmod chown chroot cksum
> > comm
> > cp
> >       csplit cut date dd df dir dircolors dirname du echo env
> > expand
> > expr
> >       factor false flock fmt fold groups head hostid id install
> > join
> > link ln
> >       logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup
> > nproc
> > numfmt
> >       od paste pathchk pinky pr printenv printf ptx pwd readlink
> > realpath rm
> >       rmdir runcon sha*sum seq shred sleep sort split stat stty sum
> > sync
> > tac
> >       tail tee test timeout touch tr true truncate tsort tty uname
> > unexpand
> >       uniq unlink users vdir wc who whoami yes
> >      Homepage: http://gnu.org/software/coreutils
> >      Original-Maintainer: Michael Stone <mstone at debian.org>
> > [10:34:45.962] Returned: 0
> >
> > [10:34:45.963] Running dpkg-deb
> > [10:34:45.965] Warning: app-image dir not generated by jpackage.
> > [10:34:45.967] Warning: app-image dir not generated by jpackage.
> > [10:34:45.967] java.lang.NullPointerException: Cannot invoke
> > "java.lang.CharSequence.length()" because "this.text" is null
> >          at
> > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
> >          at
> > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> >          at
> > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> >          at
> > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(
> > Linu
> > xDebBundler.java:83)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Lin
> > uxPa
> > ckageBundler.java:72)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argumen
> > ts.j
> > ava:663)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argum
> > ents
> > .java:538)
> >          at
> > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> >          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > [10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler DEB
> > Bundle failed because of java.lang.NullPointerException: Cannot
> > invoke
> > "java.lang.CharSequence.length()" because "this.text" is null
> >          at
> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argumen
> > ts.j
> > ava:685)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argum
> > ents
> > .java:538)
> >          at
> > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> >          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > Caused by: java.lang.NullPointerException: Cannot invoke
> > "java.lang.CharSequence.length()" because "this.text" is null
> >          at
> > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
> >          at
> > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> >          at
> > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> >          at
> > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(
> > Linu
> > xDebBundler.java:83)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Lin
> > uxPa
> > ckageBundler.java:72)
> >          at
> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argumen
> > ts.j
> > ava:663)
> >          ... 3 more
> >
> > $
> >
> >


From Alan.Bateman at oracle.com  Mon Apr  4 07:06:36 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 4 Apr 2022 08:06:36 +0100
Subject: Unused sun.nio.fs.Reflect
In-Reply-To: <66ab8067-2680-b283-de60-6e3b5d45de06@oracle.com>
References: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>
 <36e48cfe-9a41-64cc-88e5-6e9eae1300e0@oracle.com>
 <66ab8067-2680-b283-de60-6e3b5d45de06@oracle.com>
Message-ID: <ca3be76c-ba22-d69e-2f2a-70ae062ac28b@oracle.com>

On 02/04/2022 21:45, Claes Redestad wrote:
> :
>
> There's a sibling 'sun.nio.ch.Reflect' where a couple of methods are
> still dubiously in use in one place only in
> sun.nio.ch.InheritedChannel::createChannel to reflectively create a
> java.io.FileDescriptor. Perhaps that could be refactored to use
> jdk.internal.access.JavaIOFileDescriptorAccess, in which case we could
> get rid of both of these. Would be more efficient (if it matters) but
> also consolidate internal hacking to fewer places.
There are a number of left overs in ch.Reflect that can be removed. 
However we have to careful about changing anything sockets based to use 
JavaIOFileDescriptorAccess as handle != socket on Windows. This area is 
lower level than java.io and requires direct control of the file 
descriptors.

-Alan

From claes.redestad at oracle.com  Mon Apr  4 08:37:56 2022
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 4 Apr 2022 10:37:56 +0200
Subject: Unused sun.nio.fs.Reflect
In-Reply-To: <ca3be76c-ba22-d69e-2f2a-70ae062ac28b@oracle.com>
References: <CAF+DQ5c34Y3Ao55A+ADRtSfppFBtg+gzs7nrR2pZmmARnLzRrg@mail.gmail.com>
 <36e48cfe-9a41-64cc-88e5-6e9eae1300e0@oracle.com>
 <66ab8067-2680-b283-de60-6e3b5d45de06@oracle.com>
 <ca3be76c-ba22-d69e-2f2a-70ae062ac28b@oracle.com>
Message-ID: <80f352eb-8626-bf23-0d7f-9b388333756a@oracle.com>



On 2022-04-04 09:06, Alan Bateman wrote:
> On 02/04/2022 21:45, Claes Redestad wrote:
>> :
>>
>> There's a sibling 'sun.nio.ch.Reflect' where a couple of methods are
>> still dubiously in use in one place only in
>> sun.nio.ch.InheritedChannel::createChannel to reflectively create a
>> java.io.FileDescriptor. Perhaps that could be refactored to use
>> jdk.internal.access.JavaIOFileDescriptorAccess, in which case we could
>> get rid of both of these. Would be more efficient (if it matters) but
>> also consolidate internal hacking to fewer places.
> There are a number of left overs in ch.Reflect that can be removed. 
> However we have to careful about changing anything sockets based to use 
> JavaIOFileDescriptorAccess as handle != socket on Windows. This area is 
> lower level than java.io and requires direct control of the file 
> descriptors.
> 

What I had in mind was exposing the exact constructor that
InheritedChannel is invoking via reflection to keep semantics identical.
Nothing important though, cleaning out the unused stuff is a good step
for now.

/Claes

From duke at openjdk.java.net  Tue Apr  5 20:26:18 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Tue, 5 Apr 2022 20:26:18 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add error msg for jtreg test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/e97c6fbc..8047767c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=06-07

  Stats: 41 lines in 2 files changed: 37 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Tue Apr  5 20:26:20 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Tue, 5 Apr 2022 20:26:20 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v6]
In-Reply-To: <ZbWsalEIVI8lS8729YSXAOapHZIAXlEAwfSSeXCpIEs=.1628bcce-3e33-4867-9f15-d6bec74a23bf@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <95NvO8tp9Px6gaY9DiVuMV7AzibD9SaCQBcRVVeB8eU=.7618df09-83cd-45c9-83e6-8529a3bdc491@github.com>
 <ZbWsalEIVI8lS8729YSXAOapHZIAXlEAwfSSeXCpIEs=.1628bcce-3e33-4867-9f15-d6bec74a23bf@github.com>
Message-ID: <J2ZdMpSu9sm1M7AEt-AQVNGi5jCZaHQIe8E2vT3Xeic=.da3802a0-bc8d-4f0c-8b1b-33f4718642b7@github.com>

On Tue, 5 Apr 2022 17:06:44 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add bmi1 support check and jtreg tests
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp line 362:
> 
>> 360:   void vector_popcount_long(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,
>> 361:                             XMMRegister xtmp2, XMMRegister xtmp3, Register rtmp,
>> 362:                             int vec_enc);
> 
> This doesn't seem to be related to this patch.

This is coming due to a merge with the latest upstream (jdk)

> test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 107:
> 
>> 105:             }
>> 106:             if (mismatch) {
>> 107:                 throw new RuntimeException("Test failed");
> 
> It would be good to print dividend, divisor, operation, actual result and expected result here.

Please see the updated error message in the recent commit.

> test/hotspot/jtreg/compiler/intrinsics/TestLongDivMod.java line 104:
> 
>> 102:             }
>> 103:             if (mismatch) {
>> 104:                 throw new RuntimeException("Test failed");
> 
> It would be good to print dividend, divisor, operation, actual result and expected result here.

Please see the updated error message in the recent commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From psandoz at openjdk.java.net  Tue Apr  5 22:13:10 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 5 Apr 2022 22:13:10 GMT
Subject: RFR: 8283892: Compress and expand bits
Message-ID: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>

Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.

Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.

The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.

This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).

Testing-wise the approach take is three fold:
1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
2. Tests composed of compress and expand and vice versa.
3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

-------------

Commit messages:
 - Format.
 - License update.
 - Update test.
 - Update tests.
 - JavaDoc.
 - Remove byte/short impls. Update tests.
 - Compositional test.
 - Fix array size.
 - Basic test.
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8115/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283892
  Stats: 726 lines in 5 files changed: 719 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From joehw at openjdk.java.net  Tue Apr  5 23:12:00 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 5 Apr 2022 23:12:00 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes
Message-ID: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>

Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.

Test: existing tests passed.

-------------

Commit messages:
 - 8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes

Changes: https://git.openjdk.java.net/jdk/pull/8116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279876
  Stats: 26 lines in 6 files changed: 1 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8116/head:pull/8116

PR: https://git.openjdk.java.net/jdk/pull/8116

From sviswanathan at openjdk.java.net  Tue Apr  5 23:16:46 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 5 Apr 2022 23:16:46 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
Message-ID: <Jl6rFpSC_MEHELciJ6ZME7N7ptUKq9D1xbMEF18f8dI=.165b2366-6173-410b-a003-157c10310326@github.com>

On Tue, 5 Apr 2022 20:26:18 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add error msg for jtreg test

Marked as reviewed by sviswanathan (Reviewer).

Looks good to me. You need one more review.

@vnkozlov Could you please help review this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Tue Apr  5 23:20:44 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 5 Apr 2022 23:20:44 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
Message-ID: <dQkGL731kOYd9S0UYNCVJa18UShSeR6HsNqs2G4R7v8=.e8a01aec-b2f3-4459-9e99-9946d08963ac@github.com>

On Sat, 2 Apr 2022 22:46:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in jdk.compile

src/java.base/share/classes/java/util/LinkedHashMap.java line 804:

> 802:      * @since 19
> 803:      */
> 804:     public static <K, V> LinkedHashMap<K, V> newLinkedHashMap(int numMappings) {

`LinkedHashMap` may be often extended for it has a `protected boolean removeEldestEntry(Entry)`. Should we make a separate factory method for such instances (with functional implementation) or just expose `HashMap.calculateHashMapCapacity`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From naoto at openjdk.java.net  Tue Apr  5 23:59:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 5 Apr 2022 23:59:43 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes
In-Reply-To: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
Message-ID: <EB1eWsDAacie5j1hBs4ksdLWy5nE_t8WrncGtPR0J4M=.9a3d1dca-61cd-45af-a078-0045a5087025@github.com>

On Tue, 5 Apr 2022 23:05:47 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.
> 
> Test: existing tests passed.

src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java line 326:

> 324:     public void setFeature(int index, State state, Object value) {
> 325:         boolean temp;
> 326:         if (Boolean.class.isInstance(value)) {

Could this be `value instanceof Boolean`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8116

From asemenyuk at openjdk.java.net  Wed Apr  6 00:09:45 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 6 Apr 2022 00:09:45 GMT
Subject: RFR: 8284067: jpackage'd launcher reports non-zero exit codes with
 error prompt
In-Reply-To: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
References: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
Message-ID: <06xuCPdm6hOJqRR9uHWVa3dABbfWI8VT2Vpw5u0AX3U=.224d2469-1450-4ed7-a54e-194b0e72ebe3@github.com>

On Thu, 31 Mar 2022 20:08:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing `exit(exitCode)` call.
> Add relevant unit test.

@sashamatveev please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/8064

From almatvee at openjdk.java.net  Wed Apr  6 00:41:42 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 6 Apr 2022 00:41:42 GMT
Subject: RFR: 8284067: jpackage'd launcher reports non-zero exit codes with
 error prompt
In-Reply-To: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
References: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
Message-ID: <lbGdOeeVEAvhZe6Kp3gDoXVt_7Ekdkq7vmogghmC40k=.f3700e3e-26c1-4d4c-b94c-2a03e23062a4@github.com>

On Thu, 31 Mar 2022 20:08:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing `exit(exitCode)` call.
> Add relevant unit test.

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8064

From kvn at openjdk.java.net  Wed Apr  6 00:49:43 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 6 Apr 2022 00:49:43 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
Message-ID: <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>

On Tue, 5 Apr 2022 20:26:18 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add error msg for jtreg test

I have few comments.

src/hotspot/cpu/x86/assembler_x86.cpp line 12375:

> 12373: }
> 12374: #endif
> 12375: 

Please, place it near `idivq()` so you would not need `#ifdef`.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4568:

> 4566:   subl(rdx, divisor);
> 4567:   if (VM_Version::supports_bmi1()) andnl(rax, rdx, rax);
> 4568:   else {

Please, follow our coding stile here and in following methods:

if (VM_Version::supports_bmi1()) {
  andnl(rax, rdx, rax);
} else {

src/hotspot/cpu/x86/x86_64.ad line 8701:

> 8699: %}
> 8700: 
> 8701: instruct udivI_rReg(rax_RegI rax, no_rax_rdx_RegI div, rFlagsReg cr, rdx_RegI rdx)

I suggest to follow the pattern in other `div/mod` instructions: `(rax_RegI rax, rdx_RegI rdx, no_rax_rdx_RegI div, rFlagsReg cr)`

Similar in following new instructions.

test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 55:

> 53:             dividends[i] = rng.nextInt();
> 54:             divisors[i] = rng.nextInt();
> 55:         }

I don't trust RND to generate corner cases.
Please, add cases here and in TestLongDivMod.java for MAX, MIN, 0.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7572

From kvn at openjdk.java.net  Wed Apr  6 00:49:43 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 6 Apr 2022 00:49:43 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <fJGpa0iOx6AwnUsmoZA7pzw0B-PocgklwxSWzDqoRZQ=.b12fb49a-4b2e-4514-9b84-e093d2fbbb03@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
 <oCd9O4Ecr3MnFogrUlo-lMw-MUHNTfwJqdUIV2fxXNc=.e3ec0775-0264-4cea-b1a4-657be815b390@github.com>
 <fJGpa0iOx6AwnUsmoZA7pzw0B-PocgklwxSWzDqoRZQ=.b12fb49a-4b2e-4514-9b84-e093d2fbbb03@github.com>
Message-ID: <EilN6a5RAdiHRMCwYraI3UOlaFXMc6ayUSUyLp686PU=.affe5bd9-b472-4c65-a12c-3f457f8ef3a0@github.com>

On Thu, 24 Feb 2022 19:04:37 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> src/hotspot/share/opto/divnode.cpp line 881:
>> 
>>> 879:   return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this;
>>> 880: }
>>> 881: //------------------------------Value------------------------------------------
>> 
>> Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful.
>
> Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365

You do need `Ideal()` methods at least to check for dead code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From smarks at openjdk.java.net  Wed Apr  6 00:57:43 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 6 Apr 2022 00:57:43 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
Message-ID: <9q4guk-29iN4X-EYQDJ1DIXhmOK-48HIjCoKdm9jEu4=.50c37a5f-069d-48e2-823d-b25053c44165@github.com>

On Sat, 2 Apr 2022 22:46:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in jdk.compile

src/java.base/share/classes/java/util/LinkedHashMap.java line 792:

> 790: 
> 791:     /**
> 792:      * Creates a new, empty LinkedHashMap suitable for the expected number of mappings.

Adjust wording here to read,

    Creates a new, empty, insertion-ordered LinkedHashMap suitable...

I've used this wording in the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr  6 01:19:44 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 6 Apr 2022 01:19:44 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
Message-ID: <Fi1lvRZ3D_pggYil63p5OhmDHCbloC-XP78g4Qpm2ME=.68944ba2-ed20-487a-b9f0-2ea6a44aa753@github.com>

On Sat, 2 Apr 2022 22:46:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in jdk.compile

I've drafted a CSR for this. Please review:

https://bugs.openjdk.java.net/browse/JDK-8284377

I haven't yet reviewed all the call sites in detail, but I'll continue doing so. You're ambitious! But the number of call site errors that are fixed by this new API is quite high, so doing this is worthwhile.

test/jdk/java/util/Collections/CalculateHashMapCapacityTestJMH.java line 1:

> 1: /*

I don't think we need this benchmark in this PR.

Note, for future reference, benchmarks are located in the `test/micro` directory and not with the main regression suite in `test/jdk`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr  6 01:19:44 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 6 Apr 2022 01:19:44 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <dQkGL731kOYd9S0UYNCVJa18UShSeR6HsNqs2G4R7v8=.e8a01aec-b2f3-4459-9e99-9946d08963ac@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <dQkGL731kOYd9S0UYNCVJa18UShSeR6HsNqs2G4R7v8=.e8a01aec-b2f3-4459-9e99-9946d08963ac@github.com>
Message-ID: <bDYWMDn08z6HesNf15HOwb93v-so4AzJjK3IxAxB8_k=.a708b0f6-0098-4feb-b63f-63f7628159c2@github.com>

On Tue, 5 Apr 2022 23:16:57 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in jdk.compile
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 804:
> 
>> 802:      * @since 19
>> 803:      */
>> 804:     public static <K, V> LinkedHashMap<K, V> newLinkedHashMap(int numMappings) {
> 
> `LinkedHashMap` may be often extended for it has a `protected boolean removeEldestEntry(Entry)`. Should we make a separate factory method for such instances (with functional implementation) or just expose `HashMap.calculateHashMapCapacity`?

Good question. Having to subclass and override this method in order to provide a removal policy has always seemed rather clumsy. However, it's the supported approach, and it's done fairly frequently in the wild. A new subclass requires that the caller invoke `new` on that specific subclass, which in turn must choose which superclass constructor to call. This means that a static factory method can't be used. The alternatives would be to expose another constructor or to expose `calculateHashMapCapacity` as you suggest. A new constructor might also need to control the load factor and the ordering policy (insertion vs access order) so that's a fairly complicated overload to consider.

Exposing the calculate method might help but that's mostly just a wrapper around a small computation. As we've seen it's easy to get this computation wrong, but exposing a method that _just_ does this computation seems like a really narrow case.

(Still another alternative would be to pass a lambda expression that's called at the appropriate time. That would involve adding a `BiPredicate<Map<K,V>, Map.Entry<K,V>>` to yet another constructor overload. This could work but it doesn't seem any simpler.)

The need for subclassing LinkedHashMap and overriding this method might also be reduced by the addition of new APIs from the Sequenced Collections proposal (https://openjdk.java.net/jeps/8280836). One simply needs to call `pollFirstEntry` at the right time. That might remove the need to have some expiration policy plugged directly into the map itself.

I'm not inclined to add more APIs to cover what seems to be a fairly narrow case, but we might keep this in mind to see if anything useful pops up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From joehw at openjdk.java.net  Wed Apr  6 01:23:15 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 6 Apr 2022 01:23:15 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes [v2]
In-Reply-To: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
Message-ID: <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>

> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.
> 
> Test: existing tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  replace with instanceof

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8116/files
  - new: https://git.openjdk.java.net/jdk/pull/8116/files/84a9dceb..5d6a6e3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8116&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8116&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8116/head:pull/8116

PR: https://git.openjdk.java.net/jdk/pull/8116

From joehw at openjdk.java.net  Wed Apr  6 01:23:16 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 6 Apr 2022 01:23:16 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes [v2]
In-Reply-To: <EB1eWsDAacie5j1hBs4ksdLWy5nE_t8WrncGtPR0J4M=.9a3d1dca-61cd-45af-a078-0045a5087025@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
 <EB1eWsDAacie5j1hBs4ksdLWy5nE_t8WrncGtPR0J4M=.9a3d1dca-61cd-45af-a078-0045a5087025@github.com>
Message-ID: <CpS4bSElVo35JEdWM8gjkouCiKoAp68nlgX5jeRD58Q=.ea378a06-66c1-4455-b3c3-0327e18c8c2f@github.com>

On Tue, 5 Apr 2022 23:55:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace with instanceof
>
> src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java line 326:
> 
>> 324:     public void setFeature(int index, State state, Object value) {
>> 325:         boolean temp;
>> 326:         if (Boolean.class.isInstance(value)) {
> 
> Could this be `value instanceof Boolean`?

Looks like instanceof is preferable in this case. Replaced.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8116

From duke at openjdk.java.net  Wed Apr  6 01:35:31 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 6 Apr 2022 01:35:31 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <bDYWMDn08z6HesNf15HOwb93v-so4AzJjK3IxAxB8_k=.a708b0f6-0098-4feb-b63f-63f7628159c2@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <dQkGL731kOYd9S0UYNCVJa18UShSeR6HsNqs2G4R7v8=.e8a01aec-b2f3-4459-9e99-9946d08963ac@github.com>
 <bDYWMDn08z6HesNf15HOwb93v-so4AzJjK3IxAxB8_k=.a708b0f6-0098-4feb-b63f-63f7628159c2@github.com>
Message-ID: <tPlHTyw6aWmOeqPlPBF_4vwStFPGuDwL4mhvMO2iHQ4=.3a5b8e1e-08a5-4271-b9ec-b0e459fbf877@github.com>

On Wed, 6 Apr 2022 01:13:11 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 804:
>> 
>>> 802:      * @since 19
>>> 803:      */
>>> 804:     public static <K, V> LinkedHashMap<K, V> newLinkedHashMap(int numMappings) {
>> 
>> `LinkedHashMap` may be often extended for it has a `protected boolean removeEldestEntry(Entry)`. Should we make a separate factory method for such instances (with functional implementation) or just expose `HashMap.calculateHashMapCapacity`?
>
> Good question. Having to subclass and override this method in order to provide a removal policy has always seemed rather clumsy. However, it's the supported approach, and it's done fairly frequently in the wild. A new subclass requires that the caller invoke `new` on that specific subclass, which in turn must choose which superclass constructor to call. This means that a static factory method can't be used. The alternatives would be to expose another constructor or to expose `calculateHashMapCapacity` as you suggest. A new constructor might also need to control the load factor and the ordering policy (insertion vs access order) so that's a fairly complicated overload to consider.
> 
> Exposing the calculate method might help but that's mostly just a wrapper around a small computation. As we've seen it's easy to get this computation wrong, but exposing a method that _just_ does this computation seems like a really narrow case.
> 
> (Still another alternative would be to pass a lambda expression that's called at the appropriate time. That would involve adding a `BiPredicate<Map<K,V>, Map.Entry<K,V>>` to yet another constructor overload. This could work but it doesn't seem any simpler.)
> 
> The need for subclassing LinkedHashMap and overriding this method might also be reduced by the addition of new APIs from the Sequenced Collections proposal (https://openjdk.java.net/jeps/8280836). One simply needs to call `pollFirstEntry` at the right time. That might remove the need to have some expiration policy plugged directly into the map itself.
> 
> I'm not inclined to add more APIs to cover what seems to be a fairly narrow case, but we might keep this in mind to see if anything useful pops up.

True. My initial idea was to pass a lambda expression if we do make another factory.

However, when I look at the constructor parameters, I realized that for those evicting-queue-like use cases, it's more preferable for users to just call


new LinkedHashMap<>(cacheSize + 1, 1, true) {
    protected boolean removeEldestEntry(Entry<K, V> entry) {
        return size() > cacheSize;
    }
}

which preallocates the cache, avoids growth when the cache is full, and removes by least-recently-used.

IMO this use case is better suited by the existing APIs (like the call above) than a new factory method, especially that many libraries, like guava or caffeine, offer more efficient caches.

So yes, this patch in the current state looks good. In the JDK, it seems there are a few cases of linked hash map evicting by size that can have the map initialized to be presized and avoid growth. But that's off-topic here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From xgong at openjdk.java.net  Wed Apr  6 02:18:36 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 6 Apr 2022 02:18:36 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <3gF6JzPEK-BJbxjV5c8Hj5jDN3uPWLu_a5cdvtRB7AI=.e2e66b9a-eda9-4046-883c-992275b097e4@github.com>

On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Hi @PaulSandoz @jatin-bhateja @sviswa7, could you please help to check this PR? Any feedback is welcome! Thanks a lot!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From smarks at openjdk.java.net  Wed Apr  6 02:41:35 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 6 Apr 2022 02:41:35 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
Message-ID: <d74jPhzt5cW3XPu8nPZKbDOPg9m_2j9zlDddNTsHQ14=.f3454f35-6764-416c-8b2d-9bead998d9ed@github.com>

On Sat, 2 Apr 2022 22:46:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in jdk.compile

src/java.base/share/classes/java/util/HashMap.java line 2556:

> 2554:      */
> 2555:     static int calculateHashMapCapacity(int numMappings) {
> 2556:         return (int) Math.ceil(numMappings / 0.75);

Please use `(double) DEFAULT_LOAD_FACTOR` instead of `0.75`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 06:02:07 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 6 Apr 2022 06:02:07 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v9]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <TSbU3-ay83Uu5C3UggmVkJr6sMHiFOiRlyMz53yONQg=.ccdb9b4b-e4cc-4d1a-ad29-ca40e98eed85@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'openjdk:master' into udivmod
 - add error msg for jtreg test
 - update jtreg test to run on x86_64
 - add bmi1 support check and jtreg tests
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod
 - fix 32bit build issues
 - Fix line at end of file
 - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes
 - fix trailing white space errors
 - fix whitespaces
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/741be461...acba7c19

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7572/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=08
  Stats: 1007 lines in 20 files changed: 1005 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From jbhateja at openjdk.java.net  Wed Apr  6 06:27:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 6 Apr 2022 06:27:43 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v9]
In-Reply-To: <TSbU3-ay83Uu5C3UggmVkJr6sMHiFOiRlyMz53yONQg=.ccdb9b4b-e4cc-4d1a-ad29-ca40e98eed85@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <TSbU3-ay83Uu5C3UggmVkJr6sMHiFOiRlyMz53yONQg=.ccdb9b4b-e4cc-4d1a-ad29-ca40e98eed85@github.com>
Message-ID: <4VLY-BlfRmTaHHkrfFcRe1xAHtoAlzHIpziHGSq0Bes=.85eb4200-63eb-48c0-993c-4b4ddd1c9bf2@github.com>

On Wed, 6 Apr 2022 06:02:07 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into udivmod
>  - add error msg for jtreg test
>  - update jtreg test to run on x86_64
>  - add bmi1 support check and jtreg tests
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod
>  - fix 32bit build issues
>  - Fix line at end of file
>  - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes
>  - fix trailing white space errors
>  - fix whitespaces
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/741be461...acba7c19

Marked as reviewed by jbhateja (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From jbhateja at openjdk.java.net  Wed Apr  6 06:27:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 6 Apr 2022 06:27:43 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <Aqn9vzq3crvrIexXTI4xPgdkIkiZXNLJDPXw5CSVZfs=.1e038b20-5521-43fa-8127-4f675476ecf2@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
 <zjtH8PTx3JPqjwMf0xaI-Xa6OnmUCxe30uD3CpFo2oY=.4e111bb3-8e8d-44c1-aa1f-5392bed41339@github.com>
 <Aqn9vzq3crvrIexXTI4xPgdkIkiZXNLJDPXw5CSVZfs=.1e038b20-5521-43fa-8127-4f675476ecf2@github.com>
Message-ID: <hE4CeY2zJ_iT8qv8hHv6YrtHeFOQRJTvfpp7ggvArr8=.b0b2b22a-e44f-4559-bdc7-81f15531a5ff@github.com>

On Mon, 4 Apr 2022 07:24:12 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Also need a jtreg test for this.
>
>> Also need a jtreg test for this.
> 
> Thanks Sandhya for the review. Made the suggested changes and added jtreg tests as well.

Hi @vamsi-parasa , thanks for addressing my comments, looks good to me otherwise apart from the outstanding comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From shade at openjdk.java.net  Wed Apr  6 07:51:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 6 Apr 2022 07:51:40 GMT
Subject: RFR: 8283994: Make Xerces DatatypeException stackless [v2]
In-Reply-To: <wqXOrg59fuul9RmX-pqMljVO3BhV08Nl6clMSC5sCik=.e91b5bbf-4d78-43c2-b9dd-d59b99c77731@github.com>
References: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
 <YFmihRUp8vvh2c0__gk2F_cLQv9LTUrK28igWxczCaw=.06e1d18f-b0d8-4cfc-8783-50b0ddff8fa6@github.com>
 <wqXOrg59fuul9RmX-pqMljVO3BhV08Nl6clMSC5sCik=.e91b5bbf-4d78-43c2-b9dd-d59b99c77731@github.com>
Message-ID: <k2WBknIQLg1Hsn99pqFwZLePPkzALUWwu5a0MQkqrn8=.96caf879-7cd9-412c-bf95-b0d74707c383@github.com>

On Fri, 1 Apr 2022 08:10:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update LastModified
>
> Any other reviews? I would like someone else to confirm my investigation that we don't use the stack traces out of these exceptions too...

> Hello @shipilev, do you think this stackless nature of this specific `DatatypeException` type should be noted in its javadoc, just to avoid any surprises when someone in future ends up using this exception type as the "cause" of some other exception?

I don't think so. It seems to me the intent for these exceptions is to carry error information without any stack trace info.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8036

From shade at openjdk.java.net  Wed Apr  6 08:01:43 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 6 Apr 2022 08:01:43 GMT
Subject: RFR: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
Message-ID: <yJB96tFnUfA9L9sxlCGVELwD5zetKfvWB0EIKck5enI=.e01306a8-9812-4b4d-970f-e9971ff18b40@github.com>

On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> As an alternative to #7667 I took a look at injecting an empty class array from the VM. Turns out we already do this for exception types - see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 - and we can do similarly for the parameter types array. We still need to parse the signature for the return type, though.
> 
> I've verified by dumping and inspecting heaps that this means we are not allocating extra `Class<?>[]` on `Method` reflection.

Looks fine. I would have thought to put `assert(parameter_count > 0)` near `mirrors->obj_at_put(index++, mirror);`, but I think it is fine as it is, since `obj_at_put` does its own bounds checking.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8089

From dongbohe at openjdk.java.net  Wed Apr  6 08:41:43 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 6 Apr 2022 08:41:43 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v3]
In-Reply-To: <wjp9BbCcRJJ9H0TKtsuwsVwaENYHN_HEB0WcdSpkWns=.d56a552a-7cad-4043-a90e-83997de9d2e8@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <55kL-Nlz4WxBPchyPK-3ADg1ISK4VVwRRXFxSOvFjD8=.3b29dc38-18e2-4358-8f7a-077930f6db78@github.com>
 <wjp9BbCcRJJ9H0TKtsuwsVwaENYHN_HEB0WcdSpkWns=.d56a552a-7cad-4043-a90e-83997de9d2e8@github.com>
Message-ID: <4NAhjRIyx_dMjiKh7p2ZGLH0lTLwdcWEiaRhm6gWnPs=.c9a8f52a-22d9-4753-8460-1e5033db8ec1@github.com>

On Fri, 25 Mar 2022 11:54:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get date by 'date +%Y-%m-%dT%H:%M:%S%:z'
>
> The existing tests for the jmod tool are in test/jdk/tools/jmod. HashesTest.java might provide inspiration to avoid introducing a shell test.

@AlanBateman Could you please take another look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From redestad at openjdk.java.net  Wed Apr  6 09:45:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 6 Apr 2022 09:45:47 GMT
Subject: RFR: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <yJB96tFnUfA9L9sxlCGVELwD5zetKfvWB0EIKck5enI=.e01306a8-9812-4b4d-970f-e9971ff18b40@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
 <yJB96tFnUfA9L9sxlCGVELwD5zetKfvWB0EIKck5enI=.e01306a8-9812-4b4d-970f-e9971ff18b40@github.com>
Message-ID: <bQRZuZkaKtjv_O7D70F7UoJbQto0rQ03Wo0HJYQb2-M=.7ca9055b-c8d5-4f5b-b284-3d46505a0e87@github.com>

On Wed, 6 Apr 2022 07:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As an alternative to #7667 I took a look at injecting an empty class array from the VM. Turns out we already do this for exception types - see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 - and we can do similarly for the parameter types array. We still need to parse the signature for the return type, though.
>> 
>> I've verified by dumping and inspecting heaps that this means we are not allocating extra `Class<?>[]` on `Method` reflection.
>
> Looks fine. I would have thought to put `assert(parameter_count > 0)` near `mirrors->obj_at_put(index++, mirror);`, but I think it is fine as it is, since `obj_at_put` does its own bounds checking.

Thanks for reviewing! As @shipilev point out `obj_at_put` would assert if we tried to put anything into an empty array, so it seems redundant to add more checks here. Perhaps a comment to point that out since it was brought up here.

Do I need a second reviewer for the hotspot changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8089

From kevinw at openjdk.java.net  Wed Apr  6 09:53:41 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 6 Apr 2022 09:53:41 GMT
Subject: RFR: 8284331: Add sanity check for signal handler modification
 warning.
In-Reply-To: <qUPYOWeuJ0QOdJYo2eaPNOgFmb2jmMKKGMVY4ibfJuQ=.bcd4d636-533c-4cad-acab-88b6624964a7@github.com>
References: <qUPYOWeuJ0QOdJYo2eaPNOgFmb2jmMKKGMVY4ibfJuQ=.bcd4d636-533c-4cad-acab-88b6624964a7@github.com>
Message-ID: <U_oaFYkrR_SJf12ETWYshAfjkGCkvrEo0HNbsp68ET4=.aeb1d5ad-4a1a-417a-80c5-db19325c0333@github.com>

On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test.

(adding a note to trigger email notification, as that appears lost...)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8106

From shade at openjdk.java.net  Wed Apr  6 11:47:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 6 Apr 2022 11:47:38 GMT
Subject: RFR: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <bQRZuZkaKtjv_O7D70F7UoJbQto0rQ03Wo0HJYQb2-M=.7ca9055b-c8d5-4f5b-b284-3d46505a0e87@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
 <yJB96tFnUfA9L9sxlCGVELwD5zetKfvWB0EIKck5enI=.e01306a8-9812-4b4d-970f-e9971ff18b40@github.com>
 <bQRZuZkaKtjv_O7D70F7UoJbQto0rQ03Wo0HJYQb2-M=.7ca9055b-c8d5-4f5b-b284-3d46505a0e87@github.com>
Message-ID: <unDLFTIUqtAWZa7Gh9kDA50pqyctvcNK3YVp7oCZDVQ=.aa0cb957-b48f-4960-b740-cf1d94663020@github.com>

On Wed, 6 Apr 2022 09:42:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Do I need a second reviewer for the hotspot changes?

FWIW, I think hotspot changes are quite simple, so maybe no need for second reviewer?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8089

From asemenyuk at openjdk.java.net  Wed Apr  6 11:53:41 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 6 Apr 2022 11:53:41 GMT
Subject: Integrated: 8284067: jpackage'd launcher reports non-zero exit codes
 with error prompt
In-Reply-To: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
References: <_tEiRju7zyPKG84aPAiS8kG1tAOp6XCUPDolYXOQ4_c=.5531041f-35c3-480d-8516-01892f28d60a@github.com>
Message-ID: <ImYJBhPiE_40G1JnGIJ_mtz6uNBCTxDy028tD-ew_U4=.f54b9453-ef56-49a1-a1d5-f1dfb69c860d@github.com>

On Thu, 31 Mar 2022 20:08:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing `exit(exitCode)` call.
> Add relevant unit test.

This pull request has now been integrated.

Changeset: b9cc3bc1
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b9cc3bc1bf61572f2813f057eea7326fd0c2bd14
Stats:     26 lines in 4 files changed: 17 ins; 4 del; 5 mod

8284067: jpackage'd launcher reports non-zero exit codes with error prompt

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8064

From djelinski at openjdk.java.net  Wed Apr  6 12:14:11 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 12:14:11 GMT
Subject: RFR: 8284444: Sting typo
Message-ID: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>

This patch adds missing `r` in `string`s

-------------

Commit messages:
 - Fix sting typo

Changes: https://git.openjdk.java.net/jdk/pull/8125/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284444
  Stats: 25 lines in 8 files changed: 0 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8125.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125

PR: https://git.openjdk.java.net/jdk/pull/8125

From kcr at openjdk.java.net  Wed Apr  6 12:26:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 12:26:40 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <ATUf-x5e0Zgta3UWTO3VSkrxzr172v0Z-tPAfcP2KNY=.5cb73b01-bbcd-4ab0-a28b-53aad2fb12c1@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

This PR cuts across many areas, so will need multiple reviewers. Regarding the LCMS file, we typically don't make these kind of changes in third-party code, since it will cause our code to diverge from the upstream code, which can lead to merge conflicts down the road. @prrace will need to approve this or else you will need to revert that file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From coleenp at openjdk.java.net  Wed Apr  6 12:43:46 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 6 Apr 2022 12:43:46 GMT
Subject: RFR: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
Message-ID: <_FMGzc30Q77S5PleO5uo3AisufkI2jOwhEn69VPc_so=.d61c5129-f0f3-4fcc-a5f8-831850f7031b@github.com>

On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> As an alternative to #7667 I took a look at injecting an empty class array from the VM. Turns out we already do this for exception types - see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 - and we can do similarly for the parameter types array. We still need to parse the signature for the return type, though.
> 
> I've verified by dumping and inspecting heaps that this means we are not allocating extra `Class<?>[]` on `Method` reflection.

Looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8089

From aivanov at openjdk.java.net  Wed Apr  6 13:42:41 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 13:42:41 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

src/java.desktop/share/native/liblcms/cmstypes.c line 3668:

> 3666: // Auxiliary, read an string specified as count + string
> 3667: static
> 3668: cmsBool  ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section)

As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:

> 61: message.creating-association-with-null-extension=Creating association with null extension.
> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .

I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From djelinski at openjdk.java.net  Wed Apr  6 14:08:39 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:08:39 GMT
Subject: RFR: 8284444: Sting typo
In-Reply-To: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
Message-ID: <yFmkSoJ470Lz1n84rWjS-EplRmZeYoZmlLWhJ9dP-E8=.7515de3b-2959-4707-8bfa-6b69976ba51a@github.com>

On Wed, 6 Apr 2022 13:38:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> src/java.desktop/share/native/liblcms/cmstypes.c line 3668:
> 
>> 3666: // Auxiliary, read an string specified as count + string
>> 3667: static
>> 3668: cmsBool  ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section)
> 
> As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream.

Filed https://github.com/mm2/Little-CMS/pull/313 for this

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From djelinski at openjdk.java.net  Wed Apr  6 14:12:17 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:12:17 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>

> This patch adds missing `r` in `string`s

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Revert liblcms changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8125/files
  - new: https://git.openjdk.java.net/jdk/pull/8125/files/755c7084..68ce6ebd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8125.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125

PR: https://git.openjdk.java.net/jdk/pull/8125

From djelinski at openjdk.java.net  Wed Apr  6 14:15:36 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 14:15:36 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
Message-ID: <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>

On Wed, 6 Apr 2022 13:36:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert liblcms changes
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:
> 
>> 61: message.creating-association-with-null-extension=Creating association with null extension.
>> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
>> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .
> 
> I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.

right; without the space the period would appear to be part of the version pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From redestad at openjdk.java.net  Wed Apr  6 14:29:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 6 Apr 2022 14:29:47 GMT
Subject: RFR: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
Message-ID: <o2atfEW2zB1ScXstFvcwuMHyv0XScoRyAjX5BsUWJSw=.8ccdee7e-d579-4ca0-a9d2-8149a2007c56@github.com>

On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> As an alternative to #7667 I took a look at injecting an empty class array from the VM. Turns out we already do this for exception types - see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 - and we can do similarly for the parameter types array. We still need to parse the signature for the return type, though.
> 
> I've verified by dumping and inspecting heaps that this means we are not allocating extra `Class<?>[]` on `Method` reflection.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8089

From redestad at openjdk.java.net  Wed Apr  6 14:29:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 6 Apr 2022 14:29:47 GMT
Subject: Integrated: 8177107: Reduce memory footprint of
 java.lang.reflect.Constructor/Method
In-Reply-To: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
References: <0Uw7ddGIARtxIoL_aIOdOQI54Q92BBjKtUVxyQaCKLA=.d03a8f6c-40b0-440a-9447-8f1205c6c94e@github.com>
Message-ID: <sgyZBn-k2KYon0tGa5gj6nFBwPTGchh_is6rzPiuC2c=.4bab230d-c15f-45d0-a75a-4cfff373b723@github.com>

On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> As an alternative to #7667 I took a look at injecting an empty class array from the VM. Turns out we already do this for exception types - see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 - and we can do similarly for the parameter types array. We still need to parse the signature for the return type, though.
> 
> I've verified by dumping and inspecting heaps that this means we are not allocating extra `Class<?>[]` on `Method` reflection.

This pull request has now been integrated.

Changeset: a3851423
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a385142398eee102ff1a53d848230dc95c4ebd37
Stats:     22 lines in 4 files changed: 14 ins; 0 del; 8 mod

8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method

Reviewed-by: darcy, shade, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/8089

From alanb at openjdk.java.net  Wed Apr  6 14:30:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 6 Apr 2022 14:30:45 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
Message-ID: <AAsvs-UcEUVuWsBP8wEYXMi1xF619zuneZuFdLRSFbY=.878f3d7b-2839-48dc-a416-d18342c22f22@github.com>

On Sat, 2 Apr 2022 22:46:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in jdk.compile

The current patch touches usages all over the JDK. Is that for illustration purposes or are you planning to include them with the methods?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From alanb at openjdk.java.net  Wed Apr  6 15:01:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 6 Apr 2022 15:01:32 GMT
Subject: RFR: 8283892: Compress and expand bits
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <nz4ekV2Ah9WShcL3R4pfGDaUapKQXhQMeAC281sZZjY=.e2cafa41-1840-401b-a4c1-7d9be76931e9@github.com>

On Tue, 5 Apr 2022 22:05:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

src/java.base/share/classes/java/lang/Integer.java line 1775:

> 1773:      * the specified bit mask.
> 1774:      * <p>
> 1775:      * For each one-bit value of the mask, {@code mb} say, from least

A minor comments is that "For each one-bit value of the mask mb ...." might be a bit better, otherwise I think these methods and their javadoc looks good. If it comes up then these methods could include an example in the javadoc as they aren't hard once you see an example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From ceki at qos.ch  Wed Apr  6 15:30:51 2022
From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=)
Date: Wed, 6 Apr 2022 17:30:51 +0200
Subject: fast way to infer caller
Message-ID: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>


Hello,

As you are probably aware, one of the important primitives used in
logging libraries is inferring the caller of a given logging statement.
The current common practice is to create a throwable and process its
stack trace. This is rather wasteful and rather slow. As an alternative,
I have tried using the StackWalker API to infer the caller but was
unsatisfied with the performance.

MethodHandles.lookup().lookupClass() looks very promising except that
there is no way to specify the depth.

I am looking for a method to obtain the Nth caller at a cost of around
100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
for this use case?

-- 
Ceki G?lc?

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

From forax at univ-mlv.fr  Wed Apr  6 15:52:01 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 6 Apr 2022 17:52:01 +0200 (CEST)
Subject: fast way to infer caller
In-Reply-To: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
Message-ID: <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Ceki G?lc?" <ceki at qos.ch>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, April 6, 2022 5:30:51 PM
> Subject: fast way to infer caller

> Hello,

Hello,

> 
> As you are probably aware, one of the important primitives used in
> logging libraries is inferring the caller of a given logging statement.
> The current common practice is to create a throwable and process its
> stack trace. This is rather wasteful and rather slow. As an alternative,
> I have tried using the StackWalker API to infer the caller but was
> unsatisfied with the performance.
> 
> MethodHandles.lookup().lookupClass() looks very promising except that
> there is no way to specify the depth.
> 
> I am looking for a method to obtain the Nth caller at a cost of around
> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
> for this use case?

We have designed the StackWalker with that in mind
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html

see the discussion on StackWalker.getCallerClass()
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()

> 
> --
> Ceki G?lc?
> 
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

regards,
R?mi

From naoto at openjdk.java.net  Wed Apr  6 15:52:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 15:52:37 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
Message-ID: <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>

On Wed, 6 Apr 2022 14:12:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert liblcms changes

src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:

> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
> 62:  * StringPrep prepares Unicode strings for use in network protocols.
> 63:  * Profiles of StringPrep are set of rules and data according to which the

These also come from the upstream ICU4J project and should be corrected there.
https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From duke at openjdk.java.net  Wed Apr  6 15:55:11 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 15:55:11 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v11]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <LX9K5l9gwd38Flc7PM2cx7vMG0e58_MEsxq1NABindM=.b90217f5-00df-4c6c-ad7d-2e3e6566ee94@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - drop CalculateHashMapCapacityTestJMH
 - refine javadoc for LinkedHashMap#newLinkedHashMap

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/796975b0..4769b87b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=09-10

  Stats: 116 lines in 2 files changed: 0 ins; 115 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 15:55:11 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 15:55:11 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <AAsvs-UcEUVuWsBP8wEYXMi1xF619zuneZuFdLRSFbY=.878f3d7b-2839-48dc-a416-d18342c22f22@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <AAsvs-UcEUVuWsBP8wEYXMi1xF619zuneZuFdLRSFbY=.878f3d7b-2839-48dc-a416-d18342c22f22@github.com>
Message-ID: <_vaFxdj81NJrqwTWk-cdhnw7YCx5d8W9_qk7OZd1hlY=.bd614ebe-6d48-4901-a3b7-e390fcc0659a@github.com>

On Wed, 6 Apr 2022 14:27:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The current patch touches usages all over the JDK. Is that for illustration purposes or are you planning to include them with the methods?

@AlanBateman

I plan to include these changes to issue JDK-8186958, as I don't think it better to flood about 50 P5 issues and do them seperately in every places.

That would be a nightmare for reviewers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 15:55:15 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 15:55:15 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <9q4guk-29iN4X-EYQDJ1DIXhmOK-48HIjCoKdm9jEu4=.50c37a5f-069d-48e2-823d-b25053c44165@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <9q4guk-29iN4X-EYQDJ1DIXhmOK-48HIjCoKdm9jEu4=.50c37a5f-069d-48e2-823d-b25053c44165@github.com>
Message-ID: <pqSY-RNielMEmtMV3mRwrDH_4vhnIPY5bbocqxGaqmU=.f2d2efbd-ff5b-4d3d-b8c1-5360ce1a6845@github.com>

On Wed, 6 Apr 2022 00:54:41 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in jdk.compile
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 792:
> 
>> 790: 
>> 791:     /**
>> 792:      * Creates a new, empty LinkedHashMap suitable for the expected number of mappings.
> 
> Adjust wording here to read,
> 
>     Creates a new, empty, insertion-ordered LinkedHashMap suitable...
> 
> I've used this wording in the CSR.

@stuart-marks done.

> I don't think we need this benchmark in this PR.

@stuart-marks OK, that benchmark removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From naoto at openjdk.java.net  Wed Apr  6 15:57:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 15:57:41 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes [v2]
In-Reply-To: <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
 <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>
Message-ID: <e247Gc24_e0oCqEACs5VQMZZyILvT5GbCuZdoEXzrQc=.8eb2dbb8-b755-4bc7-8a8f-068715308e3b@github.com>

On Wed, 6 Apr 2022 01:23:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.
>> 
>> Test: existing tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace with instanceof

Looks good to me. This would have been a premiere example for switch pattern match, but hey.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8116

From alanb at openjdk.java.net  Wed Apr  6 16:02:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 6 Apr 2022 16:02:32 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <_vaFxdj81NJrqwTWk-cdhnw7YCx5d8W9_qk7OZd1hlY=.bd614ebe-6d48-4901-a3b7-e390fcc0659a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <AAsvs-UcEUVuWsBP8wEYXMi1xF619zuneZuFdLRSFbY=.878f3d7b-2839-48dc-a416-d18342c22f22@github.com>
 <_vaFxdj81NJrqwTWk-cdhnw7YCx5d8W9_qk7OZd1hlY=.bd614ebe-6d48-4901-a3b7-e390fcc0659a@github.com>
Message-ID: <G9kQhJHRpULG7EQHFNGh_Zdil6hKleyn3a-kQLXVLcE=.46c8b846-335e-4996-b2f9-52dbfe198728@github.com>

On Wed, 6 Apr 2022 15:47:50 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> I plan to include these changes to issue JDK-8186958, as I don't think it better to flood about 50 P5 issues and do them seperately in every places.
> 
> That would be a nightmare for reviewers.

I didn't ask for 50 PRs, I just asked if you plan to separate the usages into a separate PR. As it stands, most of the areas that you've touched are not notified by this PR. I suspect the core-libs label was added when you created it but you've expanded it greatly since.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 16:02:31 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 16:02:31 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  use (double) DEFAULT_LOAD_FACTOR instead of 0.75

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/4769b87b..b973ee51

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 16:02:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 16:02:33 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <d74jPhzt5cW3XPu8nPZKbDOPg9m_2j9zlDddNTsHQ14=.f3454f35-6764-416c-8b2d-9bead998d9ed@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <d74jPhzt5cW3XPu8nPZKbDOPg9m_2j9zlDddNTsHQ14=.f3454f35-6764-416c-8b2d-9bead998d9ed@github.com>
Message-ID: <9tLa5ePfLJ7Lc7_DAVaCrN1IZmck7J1azovXT9tyekU=.9f2bf4a6-770c-4cd4-8f9c-ef80497d1a39@github.com>

On Wed, 6 Apr 2022 02:38:17 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in jdk.compile
>
> src/java.base/share/classes/java/util/HashMap.java line 2556:
> 
>> 2554:      */
>> 2555:     static int calculateHashMapCapacity(int numMappings) {
>> 2556:         return (int) Math.ceil(numMappings / 0.75);
> 
> Please use `(double) DEFAULT_LOAD_FACTOR` instead of `0.75`.

@stuart-marks done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 16:05:42 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 16:05:42 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v11]
In-Reply-To: <LX9K5l9gwd38Flc7PM2cx7vMG0e58_MEsxq1NABindM=.b90217f5-00df-4c6c-ad7d-2e3e6566ee94@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <LX9K5l9gwd38Flc7PM2cx7vMG0e58_MEsxq1NABindM=.b90217f5-00df-4c6c-ad7d-2e3e6566ee94@github.com>
Message-ID: <tH94QT0Qz0Z0NbSP12-4wCwClghHsrxAB8O-RPGgwUc=.e441e04d-c1ae-4438-bad8-ac6cd24cd7ff@github.com>

On Wed, 6 Apr 2022 15:55:11 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - drop CalculateHashMapCapacityTestJMH
>  - refine javadoc for LinkedHashMap#newLinkedHashMap

> If you plan to separate the usages into a separate PR

@AlanBateman No, my original plan is to make them all in this PR.

However if there be reviewer with permission who stronglly opposed to this plan, I can accept making another seperate pr for the changes of usages.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr  6 16:05:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 16:05:43 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v10]
In-Reply-To: <G9kQhJHRpULG7EQHFNGh_Zdil6hKleyn3a-kQLXVLcE=.46c8b846-335e-4996-b2f9-52dbfe198728@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <42-zCBNe3-rY2k_AMY82O72g2BNXDRLZlCYKMX7Rth0=.4eab1c8e-2819-412e-b97a-68e95daa81e8@github.com>
 <AAsvs-UcEUVuWsBP8wEYXMi1xF619zuneZuFdLRSFbY=.878f3d7b-2839-48dc-a416-d18342c22f22@github.com>
 <_vaFxdj81NJrqwTWk-cdhnw7YCx5d8W9_qk7OZd1hlY=.bd614ebe-6d48-4901-a3b7-e390fcc0659a@github.com>
 <G9kQhJHRpULG7EQHFNGh_Zdil6hKleyn3a-kQLXVLcE=.46c8b846-335e-4996-b2f9-52dbfe198728@github.com>
Message-ID: <kIavBXbzAXMX-U7RaJd14mprHxlbHTi8b7C76Qqj8sA=.fb253271-da8a-40e3-b2b8-f206e37e50f1@github.com>

On Wed, 6 Apr 2022 15:57:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I suspect the core-libs label was added when you created it but you've expanded it greatly since.

Is there a way for making the bot re-calculate the labels?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From lancea at openjdk.java.net  Wed Apr  6 16:20:37 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 6 Apr 2022 16:20:37 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes [v2]
In-Reply-To: <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
 <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>
Message-ID: <Ch9aqkM_W3twaftMZLC3mthFPv2tRnFPRP0ceP8DDck=.59c1deb5-f0b5-432d-81ec-81d3a8db67f5@github.com>

On Wed, 6 Apr 2022 01:23:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.
>> 
>> Test: existing tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace with instanceof

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8116

From duke at openjdk.java.net  Wed Apr  6 16:21:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 6 Apr 2022 16:21:43 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
Message-ID: <xZ59WmCO-MAzOY4UjDllocujInjM2k-rXVgUhb4tRKU=.0a28f80b-1cdf-4087-a1f2-2c5f66b6ee10@github.com>

On Wed, 6 Apr 2022 16:02:31 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use (double) DEFAULT_LOAD_FACTOR instead of 0.75

There be another question:
Should we add `@ForceInline` annotation to the new added functions? as they be static short functions, thus seems maybe benificial to inline them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From simonis at openjdk.java.net  Wed Apr  6 16:28:21 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 6 Apr 2022 16:28:21 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/62a46591..7c671aa5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=02-03

  Stats: 28 lines in 4 files changed: 19 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Wed Apr  6 16:28:22 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 6 Apr 2022 16:28:22 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v3]
In-Reply-To: <hle3CzoC0pII6-hQjg-WpRXGY-vAk4m5iw3Oo7BlEsA=.82c931d4-a2e6-4ce1-9451-94ebba2a1927@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <hle3CzoC0pII6-hQjg-WpRXGY-vAk4m5iw3Oo7BlEsA=.82c931d4-a2e6-4ce1-9451-94ebba2a1927@github.com>
Message-ID: <fCzjeZ3gN1B4lrI-N9buBpJvjUrtuYThtn8jcru5iwM=.f77225a6-e180-4124-9949-a0c1bf4da89c@github.com>

On Tue, 29 Mar 2022 12:43:25 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extended API-doc based on reviewer feedback

Hi,

I've pushed a new version which:
- improves the wording as suggested
- adds the API amendments from `InflaterInputStream::read()` to `GZIPInputStream::read()`/`ZipInputStream::read()` as well be cause they both inherit from `InflaterInputStream`. Unfortunately it's not possible to simply inherit the API doc because of different parameter naming.
- added an `@implNote` to `ZipFile::getInputStream()` to make it clear that this implementation really returns an `InflaterInputStream`.

Please let me know what you think?
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From joehw at openjdk.java.net  Wed Apr  6 16:41:29 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 6 Apr 2022 16:41:29 GMT
Subject: RFR: 8279876: Clean up: isAssignableFrom usages in xpath and jdk
 internal classes [v2]
In-Reply-To: <e247Gc24_e0oCqEACs5VQMZZyILvT5GbCuZdoEXzrQc=.8eb2dbb8-b755-4bc7-8a8f-068715308e3b@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
 <6m_sUr8RXrIiFna89pcb1TNwi-6MqnwAj9XyZft0gRg=.d6c0c05c-0633-43db-9523-d27e5bc0ff87@github.com>
 <e247Gc24_e0oCqEACs5VQMZZyILvT5GbCuZdoEXzrQc=.8eb2dbb8-b755-4bc7-8a8f-068715308e3b@github.com>
Message-ID: <O-8Qlfa6hHW2WVX6298MmcICa9qUcoxw4HhixsEWa8g=.bb0b5e50-ada0-45a7-acd8-65f705eb168d@github.com>

On Wed, 6 Apr 2022 15:54:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good to me. This would have been a premiere example for switch pattern match, but hey.

Yeah, totally understand the urge to use new features.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8116

From djelinski at openjdk.java.net  Wed Apr  6 16:47:17 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 16:47:17 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>

> This patch adds missing `r` in `string`s

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - revert xalan changes
 - revert icu changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8125/files
  - new: https://git.openjdk.java.net/jdk/pull/8125/files/68ce6ebd..1ec0314e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8125.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125

PR: https://git.openjdk.java.net/jdk/pull/8125

From djelinski at openjdk.java.net  Wed Apr  6 16:51:43 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Apr 2022 16:51:43 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
 <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
Message-ID: <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>

On Wed, 6 Apr 2022 15:49:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert liblcms changes
>
> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:
> 
>> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
>> 62:  * StringPrep prepares Unicode strings for use in network protocols.
>> 63:  * Profiles of StringPrep are set of rules and data according to which the
> 
> These also come from the upstream ICU4J project and should be corrected there.
> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27

Thanks, reverted. Also reverted Xalan changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From naoto at openjdk.java.net  Wed Apr  6 16:55:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 16:55:35 GMT
Subject: RFR: 8284444: Sting typo [v2]
In-Reply-To: <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <J0QE92iWWFtqKNwRTUDsGrrsHbNFuPlrxx6sPlocVzk=.72a2acc8-02c6-4b0f-b15b-5faf35b904a5@github.com>
 <rWGMDXuXoinhsJTtNT4cXHGxF0fFsxv7KotnVSN0C8g=.3ec7fb35-1b67-4131-8f03-bb89c94a9bfb@github.com>
 <To4hp-0Cdlgrk2nc06w2mJbYJiV1wZZmvEEA-upixTs=.a559e0eb-f487-442c-a82b-80c43f481a2b@github.com>
Message-ID: <GNiL7wT_8egSbprPKOkslemEty8HyQP0xthAyCfzRcU=.03f97c53-9fb3-4fa3-9bb2-4ffaec95ad83@github.com>

On Wed, 6 Apr 2022 16:48:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:
>> 
>>> 61:  * <a href="http://www.ietf.org/rfc/rfc3454.txt">RFC 3454</a>.
>>> 62:  * StringPrep prepares Unicode strings for use in network protocols.
>>> 63:  * Profiles of StringPrep are set of rules and data according to which the
>> 
>> These also come from the upstream ICU4J project and should be corrected there.
>> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27
>
> Thanks, reverted. Also reverted Xalan changes.

Good. Thanks for reverting it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From luhenry at openjdk.java.net  Wed Apr  6 17:11:40 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Wed, 6 Apr 2022 17:11:40 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v8]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <eCEsgmx8t3LejJNRAtzBymtBPX99omL-8owvzrjEVJE=.16e65379-8793-4bcd-b23d-6a309b25abfb@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Disable Arrays.hashCode intrinsic by default for CI
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
 - {wip} Generalize string hashcode to Arrays.hashCode
 - Use intrinsic for StringUTF16
 - Reduce code duplication
 - Improve performance of short strings
 - Reduce overhead of method handle
 - Leave Java method unchanged
 - Add first pass at vectorized intrinsic for StringLatin1.hashCode
   
   Next is to generalize it for Arrays.hashCode and StringUTF16.hashCode and make it cheap on shorter strings
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/19d2873b...1935cf31

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7700/files
  - new: https://git.openjdk.java.net/jdk/pull/7700/files/026e9713..1935cf31

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=06-07

  Stats: 167227 lines in 2772 files changed: 121940 ins; 33585 del; 11702 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From luhenry at openjdk.java.net  Wed Apr  6 17:11:41 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Wed, 6 Apr 2022 17:11:41 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v7]
In-Reply-To: <Xq0JO5f0GThO4RyOgyo4yVLNYR6CVh997JYSPQNwEHo=.0b5b79f1-588a-4f0f-9889-d6b32ef86855@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <Xq0JO5f0GThO4RyOgyo4yVLNYR6CVh997JYSPQNwEHo=.0b5b79f1-588a-4f0f-9889-d6b32ef86855@github.com>
Message-ID: <ppbDDvqv_7vmMzmomFzWIW1GxEOjawKOcx_diLT4pUI=.3f9a9d56-fe2f-4f79-824a-3ebc4ef33541@github.com>

On Tue, 5 Apr 2022 15:40:29 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use intrinsic for StringUTF16
>  - Reduce code duplication

EOD day update: I'm trying to generalise the approach to Arrays.hashCode for some of the types (int, short, char, byte, float). However, I'm running into the following assertion and I haven't figured it out just yet.


#  Internal Error (/home/ludovic/git/jdk/src/hotspot/share/opto/machnode.cpp:210), pid=1071828, tid=1071841
#  assert(opcnt < numopnds) failed: Accessing non-existent operand


Any pointers would be greatly appreciated, I'll keep digging in the meantime.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700

From duke at openjdk.java.net  Wed Apr  6 17:30:40 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 6 Apr 2022 17:30:40 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
 <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
Message-ID: <taAjrvybOeEsoQkZ2G3pIYn8TDxU_FvxR4ET6Mqx4kc=.724b9dbd-a869-46f4-9bbd-432a8dc9adcf@github.com>

On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I have few comments.

Thank you Vladimir (@vnkozlov) for suggesting the changes! Will incorporate the suggestions and push an update in few hours.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From psandoz at openjdk.java.net  Wed Apr  6 17:47:40 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 6 Apr 2022 17:47:40 GMT
Subject: RFR: 8283892: Compress and expand bits
In-Reply-To: <nz4ekV2Ah9WShcL3R4pfGDaUapKQXhQMeAC281sZZjY=.e2cafa41-1840-401b-a4c1-7d9be76931e9@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <nz4ekV2Ah9WShcL3R4pfGDaUapKQXhQMeAC281sZZjY=.e2cafa41-1840-401b-a4c1-7d9be76931e9@github.com>
Message-ID: <RaPXgofLB3AeJcTDtuAASYnKaGUdyA7gT4c8GGAfQ4s=.ecc9c3ee-d97b-4be4-8f97-1449f6b5a6fb@github.com>

On Wed, 6 Apr 2022 14:58:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
>> 
>> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
>> 
>> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
>> 
>> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
>> 
>> Testing-wise the approach take is three fold:
>> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
>> 2. Tests composed of compress and expand and vice versa.
>> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.
>
> src/java.base/share/classes/java/lang/Integer.java line 1775:
> 
>> 1773:      * the specified bit mask.
>> 1774:      * <p>
>> 1775:      * For each one-bit value of the mask, {@code mb} say, from least
> 
> A minor comments is that "For each one-bit value of the mask mb ...." might be a bit better, otherwise I think these methods and their javadoc looks good. If it comes up then these methods could include an example in the javadoc as they aren't hard once you see an example.

I can change to "For each one-bit value {@code mb} of the mask ..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From naoto at openjdk.java.net  Wed Apr  6 17:52:08 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Apr 2022 17:52:08 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
Message-ID: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>

This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

-------------

Commit messages:
 - 8283698: Refactor Locale constructors used in src/test

Changes: https://git.openjdk.java.net/jdk/pull/8130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283698
  Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130

PR: https://git.openjdk.java.net/jdk/pull/8130

From kcr at openjdk.java.net  Wed Apr  6 17:56:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 17:56:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <XTfw5IxI7gZ_idvpU_JUUjBvNOgzCnCkSZ6vpIvzdu4=.3a718107-69db-4221-9284-e46196268599@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

The `jpackage` part of the fix looks good.  Btw, there are translated files for 3 other languages (German, Japanese, Simplified Chinese), so I double-checked the translation for each, and they already say "string" (I guess whoever translated it just assumed it was meant to be "string" when they took the English phrase).

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/8125

From kcr at openjdk.java.net  Wed Apr  6 17:56:40 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 6 Apr 2022 17:56:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <Ho9UNSLp0gPu5BLKn83SNpGxcoN_MzElX1QabMbNr2o=.e30cd1d0-3cef-438e-87b0-c112956715f6@github.com>
 <u0NwJ909A2q1TQ2iLb_AsdhkHxEhjloPlxzgywlSV-Y=.b80b77b7-37a8-491a-83b7-7cc85c683f83@github.com>
Message-ID: <fFvzPNxrHfSm81K92eb6oiGMeOIM3Avzc5tJiQlatd4=.fe9ce9a8-2591-42dd-ba40-657e36635f2d@github.com>

On Wed, 6 Apr 2022 14:12:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63:
>> 
>>> 61: message.creating-association-with-null-extension=Creating association with null extension.
>>> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required.
>>> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build .
>> 
>> I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence.
>
> right; without the space the period would appear to be part of the version pattern.

Yes, I believe this is why it was done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From aivanov at openjdk.java.net  Wed Apr  6 18:10:40 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 6 Apr 2022 18:10:40 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <LRbz8zj9WLGW6iNa-3G2yJpwPlioeVypcdNtbOfD8ow=.48a92624-29ec-4f29-94c9-2688a3c53ce1@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

The changes look fine to me now.  
Yet there are no changes in the client area any more. So you'll have to get additional approvals.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8125

From jrose at openjdk.java.net  Wed Apr  6 18:43:42 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 6 Apr 2022 18:43:42 GMT
Subject: RFR: 8283892: Compress and expand bits
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>

On Tue, 5 Apr 2022 22:05:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Changes requested by jrose (Reviewer).

src/java.base/share/classes/java/lang/Integer.java line 1781:

> 1779:      * All the upper remaining bits of the compressed value are set
> 1780:      * to zero.
> 1781:      *

Following Alan's comment, I suggest the following examples:


  compress(0x9ABCDEF, 0x0F0F0FF) == 0xACEF
  compress(x, 1<<n) == (x>>n & 1)
  compress(x, -1<<n) == x >>> n
  compress(m, m) == (m==-1||m==0)? m : (1<<bitCount(m))-1
  compress(x, m) == compress(x & m, m)
  compress(expand(x, m), m) == x & compress(m, m)
  (compress(x, m) >>> n) & 1 == /*the bit of x corresponding to the nth set bit in m*/


?In two places.  Similarly, examples for expand:


  expand(0x9ABCDEF, 0x0F0F0FF) == 0xC0D0EF
  expand(x, 1<<n) == (x&1) << n
  expand(x, -1<<n) == x << n
  expand(-1, m) == m
  expand(x, m) == expand(x, m) & m
  expand(compress(x, m), m) == x & m
  expand(1<<n, m) == /*the nth set bit in m, as a mask in place; cf. highest/lowestOneBit*/


(Please double check these examples!)

test/jdk/java/lang/AbstractCompressExpandTest.java line 104:

> 102:     abstract long expectedExpand(long i, long mask);
> 103: 
> 104:     static int SIZE = 1024;

It feels like `SIZE` should be a constructor parameter, to make it easier to run ad hoc stress tests.

test/jdk/java/lang/AbstractCompressExpandTest.java line 145:

> 143: 
> 144:         int i = 0;
> 145:         for (int len = 0; len < 32; len++) {

Lengths should be `len = 1; len <= 32; len++`, generating fewer redundant zero-length masks and a full-length -1 mask.  The pos should be `pos = 0; pos <= 32 - len; pos++`, generating fully left-justified masks of the form `-1<<pos`.

Also, you should generate a zero-mask, just once.  I think initializing `int i = 1` will do that trick.

(Same comment in two places.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From iris at openjdk.java.net  Wed Apr  6 19:36:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 6 Apr 2022 19:36:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r5RSuZEt-YT0EOWQmAH1kV7c1apKvBn-ss866xTyF5E=.903a7419-865c-472e-9e20-632d882293e7@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From mgronlun at openjdk.java.net  Wed Apr  6 20:49:48 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 6 Apr 2022 20:49:48 GMT
Subject: RFR: 8284444: Sting typo [v3]
In-Reply-To: <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
 <mfXduGQhYNQiQcPkmH3RPK-LCdooqDqxFhmrpCRkpOk=.85876ee8-4321-4b69-9aa0-43375541466c@github.com>
Message-ID: <ladM4OI12K08dMW-meDSPHtyYvpTYyqPG5utW4SW2Cs=.0e568ec8-2b7a-4d26-af34-7baa0808c1f4@github.com>

On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch adds missing `r` in `string`s
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert xalan changes
>  - revert icu changes

JFR changes look fine, thank you.

-------------

Marked as reviewed by mgronlun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8125

From ceki at qos.ch  Wed Apr  6 21:26:39 2022
From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=)
Date: Wed, 6 Apr 2022 23:26:39 +0200
Subject: fast way to infer caller
In-Reply-To: <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
Message-ID: <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>


Hi R?mi,

Thank you for your answer.

According to some benchmarks on a i7-8565U Intel CPU (quite average
CPU), here are the costs of computing the caller class via different
methods:

using new Throwable().getStackTrace: 11 microseconds per call
using StackWalker API: 1.8 microseconds per call
using SecurityManager: 0.9 microseconds per call

While a six fold improvement (StackWalker compared to new Thorowable) is
nothing to sneeze at, the performance of StackWalker is not as good as
with a custom SecurityManager.

I have not said so explicitly but the aim here is to allow the user to
obtain a new logger by calling LoggerFactory.getLogger() with no
arguments with the returned logger named after the caller class.

Spending 1 or 2 microseconds for this call is OK if the logger is a
static field. However, if the logger is an instance field, then spending
2 microseconds per host object instance just to obtain a logger might
have a noticeable impact on performance. It follows that the performance
of LoggerFactory.getLogger() must be exceptionally good, assuming we
wish to avoid having the user accidentally shooting herself on the foot,
ergo the 100 nanosecond performance per call requirement.

Noting that invoking MethodHandles.lookup().lookupClass() seems very
fast (about 2 nanoseconds), I would be very interested if  new
lookup(int index) method were added to java.lang.invoke.MethodHandles
class, with index designating the desired index on the call stack.

Does the above make sense? How difficult would it be to add such a method?

-- 
Ceki G?lc?


On 4/6/2022 5:52 PM, Remi Forax wrote:
> ----- Original Message -----
>> From: "Ceki G?lc?" <ceki at qos.ch>
>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>> Subject: fast way to infer caller
> 
>> Hello,
> 
> Hello,
> 
>>
>> As you are probably aware, one of the important primitives used in
>> logging libraries is inferring the caller of a given logging statement.
>> The current common practice is to create a throwable and process its
>> stack trace. This is rather wasteful and rather slow. As an alternative,
>> I have tried using the StackWalker API to infer the caller but was
>> unsatisfied with the performance.
>>
>> MethodHandles.lookup().lookupClass() looks very promising except that
>> there is no way to specify the depth.
>>
>> I am looking for a method to obtain the Nth caller at a cost of around
>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>> for this use case?
> 
> We have designed the StackWalker with that in mind
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
> 
> see the discussion on StackWalker.getCallerClass()
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
> 


From psandoz at openjdk.java.net  Wed Apr  6 21:57:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 6 Apr 2022 21:57:44 GMT
Subject: RFR: 8283892: Compress and expand bits [v2]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <RVo_i9zZ8W85PS19LPswsEtT6MGwbR6PPySKGXDMBnE=.2d07a620-6386-4d23-9908-74def1bb10af@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Doc and test updates.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/9516ecca..8c536de6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=00-01

  Stats: 33 lines in 3 files changed: 17 ins; 2 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From psandoz at openjdk.java.net  Wed Apr  6 22:19:39 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 6 Apr 2022 22:19:39 GMT
Subject: RFR: 8283892: Compress and expand bits [v2]
In-Reply-To: <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
Message-ID: <GoOc_F9OYpQXR3xpjiT3KvJNltDoc5nwx9eV98iulIk=.579a9fe8-e893-421f-9380-f66fe2b4e160@github.com>

On Wed, 6 Apr 2022 17:43:34 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 104:
> 
>> 102:     abstract long expectedExpand(long i, long mask);
>> 103: 
>> 104:     static int SIZE = 1024;
> 
> It feels like `SIZE` should be a constructor parameter, to make it easier to run ad hoc stress tests.

That's tricky because the test is TestNG based, launched via jtreg, it would need to be a system property.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From jason_mehrens at hotmail.com  Wed Apr  6 22:27:46 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 6 Apr 2022 22:27:46 +0000
Subject: fast way to infer caller
In-Reply-To: <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
 <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
Message-ID: <SN7PR18MB4016588AB8701811FF721B7983E79@SN7PR18MB4016.namprd18.prod.outlook.com>

Ceki,

Looks like the benchmark code is from https://github.com/qos-ch/slf4j/pull/271

Looks like the benchmark code is doing a collection so perhaps that is some of the performance hit?
Have you benchmarked java.util.LogRecord.getSourceClassName() to compare with your StackWalker benchmark?

https://github.com/openjdk/jdk/blob/master/src/java.logging/share/classes/java/util/logging/LogRecord.java#L754

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Ceki G?lc? <ceki at qos.ch>
Sent: Wednesday, April 6, 2022 4:26 PM
To: core-libs-dev
Subject: Re: fast way to infer caller


Hi R?mi,

Thank you for your answer.

According to some benchmarks on a i7-8565U Intel CPU (quite average
CPU), here are the costs of computing the caller class via different
methods:

using new Throwable().getStackTrace: 11 microseconds per call
using StackWalker API: 1.8 microseconds per call
using SecurityManager: 0.9 microseconds per call

While a six fold improvement (StackWalker compared to new Thorowable) is
nothing to sneeze at, the performance of StackWalker is not as good as
with a custom SecurityManager.

I have not said so explicitly but the aim here is to allow the user to
obtain a new logger by calling LoggerFactory.getLogger() with no
arguments with the returned logger named after the caller class.

Spending 1 or 2 microseconds for this call is OK if the logger is a
static field. However, if the logger is an instance field, then spending
2 microseconds per host object instance just to obtain a logger might
have a noticeable impact on performance. It follows that the performance
of LoggerFactory.getLogger() must be exceptionally good, assuming we
wish to avoid having the user accidentally shooting herself on the foot,
ergo the 100 nanosecond performance per call requirement.

Noting that invoking MethodHandles.lookup().lookupClass() seems very
fast (about 2 nanoseconds), I would be very interested if  new
lookup(int index) method were added to java.lang.invoke.MethodHandles
class, with index designating the desired index on the call stack.

Does the above make sense? How difficult would it be to add such a method?

--
Ceki G?lc?


On 4/6/2022 5:52 PM, Remi Forax wrote:
> ----- Original Message -----
>> From: "Ceki G?lc?" <ceki at qos.ch>
>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>> Subject: fast way to infer caller
>
>> Hello,
>
> Hello,
>
>>
>> As you are probably aware, one of the important primitives used in
>> logging libraries is inferring the caller of a given logging statement.
>> The current common practice is to create a throwable and process its
>> stack trace. This is rather wasteful and rather slow. As an alternative,
>> I have tried using the StackWalker API to infer the caller but was
>> unsatisfied with the performance.
>>
>> MethodHandles.lookup().lookupClass() looks very promising except that
>> there is no way to specify the depth.
>>
>> I am looking for a method to obtain the Nth caller at a cost of around
>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>> for this use case?
>
> We have designed the StackWalker with that in mind
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>
> see the discussion on StackWalker.getCallerClass()
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
>


From duke at openjdk.java.net  Wed Apr  6 22:40:06 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Wed, 6 Apr 2022 22:40:06 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v10]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <hnP5BP8W5_NEVf2iwSbk0AtcQzNzTXBhWlEpne2xMvk=.f5c26a95-312d-4f0d-a798-162c7f767f7a@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - use appropriate style changes
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod
 - Merge branch 'openjdk:master' into udivmod
 - add error msg for jtreg test
 - update jtreg test to run on x86_64
 - add bmi1 support check and jtreg tests
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod
 - fix 32bit build issues
 - Fix line at end of file
 - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/4451257b...9949047c

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7572/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=09
  Stats: 1011 lines in 20 files changed: 1009 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From forax at univ-mlv.fr  Wed Apr  6 22:54:06 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Apr 2022 00:54:06 +0200 (CEST)
Subject: fast way to infer caller
In-Reply-To: <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
 <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
Message-ID: <2059020576.8120488.1649285646731.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Ceki G?lc?" <ceki at qos.ch>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, April 6, 2022 11:26:39 PM
> Subject: Re: fast way to infer caller

> Hi R?mi,
> 
> Thank you for your answer.
> 
> According to some benchmarks on a i7-8565U Intel CPU (quite average
> CPU), here are the costs of computing the caller class via different
> methods:
> 
> using new Throwable().getStackTrace: 11 microseconds per call
> using StackWalker API: 1.8 microseconds per call
> using SecurityManager: 0.9 microseconds per call
> 
> While a six fold improvement (StackWalker compared to new Throwable) is
> nothing to sneeze at, the performance of StackWalker is not as good as
> with a custom SecurityManager.
> 
> I have not said so explicitly but the aim here is to allow the user to
> obtain a new logger by calling LoggerFactory.getLogger() with no
> arguments with the returned logger named after the caller class.
> 
> Spending 1 or 2 microseconds for this call is OK if the logger is a
> static field. However, if the logger is an instance field, then spending
> 2 microseconds per host object instance just to obtain a logger might
> have a noticeable impact on performance. It follows that the performance
> of LoggerFactory.getLogger() must be exceptionally good, assuming we
> wish to avoid having the user accidentally shooting herself on the foot,
> ergo the 100 nanosecond performance per call requirement.
> 
> Noting that invoking MethodHandles.lookup().lookupClass() seems very
> fast (about 2 nanoseconds), I would be very interested if  new
> lookup(int index) method were added to java.lang.invoke.MethodHandles
> class, with index designating the desired index on the call stack.
> 
> Does the above make sense? How difficult would it be to add such a method ?

I think that for MethodHandles.lookup() and all other caller sensitive methods, the VM uses a trick, it inlines the call into the caller method, once this is done, the caller class is know statically and can be replaced by a constant. In order to use the same trick, you need a way to force the inlining through getLogger(), the is something the JDK can do but that is not available to user code.

And you do not want lookup(-1) because getLogger() can be called by reflection, java.lang.invoke or a lambda, in all these cases you have "hidden" stack frames in between the user code code and LoggerFactory.getLogger(), you need to skip those stack frames, this is what the StackWalker does.

Now, i don't think there is a real solution to you issue, worst i will try to convince you that this is not a real problem :)
You are offering convenience using magic to your user, this has a cost.

For me this is very similar to the trade off you have by offering to change the logger configuration at runtime.
This is convenient but it requires a volatile read (even when the logger is de-activated) which destroy performance in tight loop (you loose hoisting).
I believe that if your users are fine with that, they are also fine with a call to LoggerFactory.getLogger() being a little slow.

> 
> --
> Ceki G?lc?

R?mi

> 
> 
> On 4/6/2022 5:52 PM, Remi Forax wrote:
>> ----- Original Message -----
>>> From: "Ceki G?lc?" <ceki at qos.ch>
>>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>>> Subject: fast way to infer caller
>> 
>>> Hello,
>> 
>> Hello,
>> 
>>>
>>> As you are probably aware, one of the important primitives used in
>>> logging libraries is inferring the caller of a given logging statement.
>>> The current common practice is to create a throwable and process its
>>> stack trace. This is rather wasteful and rather slow. As an alternative,
>>> I have tried using the StackWalker API to infer the caller but was
>>> unsatisfied with the performance.
>>>
>>> MethodHandles.lookup().lookupClass() looks very promising except that
>>> there is no way to specify the depth.
>>>
>>> I am looking for a method to obtain the Nth caller at a cost of around
>>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>>> for this use case?
>> 
>> We have designed the StackWalker with that in mind
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>> 
>> see the discussion on StackWalker.getCallerClass()
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()

From ceki at qos.ch  Wed Apr  6 23:04:11 2022
From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=)
Date: Thu, 7 Apr 2022 01:04:11 +0200
Subject: fast way to infer caller
In-Reply-To: <SN7PR18MB4016588AB8701811FF721B7983E79@SN7PR18MB4016.namprd18.prod.outlook.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
 <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
 <SN7PR18MB4016588AB8701811FF721B7983E79@SN7PR18MB4016.namprd18.prod.outlook.com>
Message-ID: <ec8b2966-99e6-af1e-6a20-c34b50b38395@qos.ch>



Hi Jason,

Yes, the code was mentioned in SLF4J PR 271.

The benchmark can be found at

https://github.com/ceki/logback-perf/tree/master/src/main/java/ch/qos/logback/perf/caller

Here is the gist of the StackWalker variant:

public class CallerCompute {

    static private StackWalker WALKER = StackWalker.getInstance();

    static public String getCallerClass(int depth) {

        List<StackFrame> frames = WALKER.walk(s -> s.limit(4).toList());
        .... process the returned frames
    }
}

The above executes at around 1.8 microseconds per call whereas the code
in LogRecord.getSourceClassName() executes at 5 microseconds per call.
The cost of LogRecord constructor is negligible at around 25 nanoseconds.

Anyway, thank you for the suggestion.

--
Ceki


On 4/7/2022 12:27 AM, Jason Mehrens wrote:
> Ceki,
> 
> Looks like the benchmark code is from https://github.com/qos-ch/slf4j/pull/271
> 
> Looks like the benchmark code is doing a collection so perhaps that is some of the performance hit?
> Have you benchmarked java.util.LogRecord.getSourceClassName() to compare with your StackWalker benchmark?
> 
> https://github.com/openjdk/jdk/blob/master/src/java.logging/share/classes/java/util/logging/LogRecord.java#L754
> 
> Jason
> 
> ________________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Ceki G?lc? <ceki at qos.ch>
> Sent: Wednesday, April 6, 2022 4:26 PM
> To: core-libs-dev
> Subject: Re: fast way to infer caller
> 
> 
> Hi R?mi,
> 
> Thank you for your answer.
> 
> According to some benchmarks on a i7-8565U Intel CPU (quite average
> CPU), here are the costs of computing the caller class via different
> methods:
> 
> using new Throwable().getStackTrace: 11 microseconds per call
> using StackWalker API: 1.8 microseconds per call
> using SecurityManager: 0.9 microseconds per call
> 
> While a six fold improvement (StackWalker compared to new Thorowable) is
> nothing to sneeze at, the performance of StackWalker is not as good as
> with a custom SecurityManager.
> 
> I have not said so explicitly but the aim here is to allow the user to
> obtain a new logger by calling LoggerFactory.getLogger() with no
> arguments with the returned logger named after the caller class.
> 
> Spending 1 or 2 microseconds for this call is OK if the logger is a
> static field. However, if the logger is an instance field, then spending
> 2 microseconds per host object instance just to obtain a logger might
> have a noticeable impact on performance. It follows that the performance
> of LoggerFactory.getLogger() must be exceptionally good, assuming we
> wish to avoid having the user accidentally shooting herself on the foot,
> ergo the 100 nanosecond performance per call requirement.
> 
> Noting that invoking MethodHandles.lookup().lookupClass() seems very
> fast (about 2 nanoseconds), I would be very interested if  new
> lookup(int index) method were added to java.lang.invoke.MethodHandles
> class, with index designating the desired index on the call stack.
> 
> Does the above make sense? How difficult would it be to add such a method?
> 
> --
> Ceki G?lc?
> 
> 
> On 4/6/2022 5:52 PM, Remi Forax wrote:
>> ----- Original Message -----
>>> From: "Ceki G?lc?" <ceki at qos.ch>
>>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>>> Subject: fast way to infer caller
>>
>>> Hello,
>>
>> Hello,
>>
>>>
>>> As you are probably aware, one of the important primitives used in
>>> logging libraries is inferring the caller of a given logging statement.
>>> The current common practice is to create a throwable and process its
>>> stack trace. This is rather wasteful and rather slow. As an alternative,
>>> I have tried using the StackWalker API to infer the caller but was
>>> unsatisfied with the performance.
>>>
>>> MethodHandles.lookup().lookupClass() looks very promising except that
>>> there is no way to specify the depth.
>>>
>>> I am looking for a method to obtain the Nth caller at a cost of around
>>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>>> for this use case?
>>
>> We have designed the StackWalker with that in mind
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>>
>> see the discussion on StackWalker.getCallerClass()
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
>>
> 


From stevenschlansker at gmail.com  Wed Apr  6 23:08:20 2022
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 6 Apr 2022 16:08:20 -0700
Subject: fast way to infer caller
In-Reply-To: <2059020576.8120488.1649285646731.JavaMail.zimbra@u-pem.fr>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
 <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
 <2059020576.8120488.1649285646731.JavaMail.zimbra@u-pem.fr>
Message-ID: <EEA83829-ACA8-40A0-8823-07231FE458E2@gmail.com>



> On Apr 6, 2022, at 3:54 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Original Message -----
>> From: "Ceki G?lc?" <ceki at qos.ch>
>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Wednesday, April 6, 2022 11:26:39 PM
>> Subject: Re: fast way to infer caller
> 
>> Hi R?mi,
>> 
> 
> Now, i don't think there is a real solution to you issue, worst i will try to convince you that this is not a real problem :)
> You are offering convenience using magic to your user, this has a cost.
> 
> For me this is very similar to the trade off you have by offering to change the logger configuration at runtime.
> This is convenient but it requires a volatile read (even when the logger is de-activated) which destroy performance in tight loop (you loose hoisting).
> I believe that if your users are fine with that, they are also fine with a call to LoggerFactory.getLogger() being a little slow.
> 

We're only one user, but we use Logback and always assumed getLogger was reasonably expensive, and that the most effort went into optimizing the actual logging itself.
So we always store it in a static (preferred) or at least instance field, and if we ever dynamically look it up we assume that's more expensive.

To us, the convenience of calling getLogger() over getLogger(MyClass.class) is a nice win, and even 10x the execution speed of calling getLogger doesn't matter at all.
If the performance cost was documented we would still use it without hesitation.

Just my 2?,
Steven


> 
> 
>> 
>> 
>> On 4/6/2022 5:52 PM, Remi Forax wrote:
>>> ----- Original Message -----
>>>> From: "Ceki G?lc?" <ceki at qos.ch>
>>>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>>>> Subject: fast way to infer caller
>>> 
>>>> Hello,
>>> 
>>> Hello,
>>> 
>>>> 
>>>> As you are probably aware, one of the important primitives used in
>>>> logging libraries is inferring the caller of a given logging statement.
>>>> The current common practice is to create a throwable and process its
>>>> stack trace. This is rather wasteful and rather slow. As an alternative,
>>>> I have tried using the StackWalker API to infer the caller but was
>>>> unsatisfied with the performance.
>>>> 
>>>> MethodHandles.lookup().lookupClass() looks very promising except that
>>>> there is no way to specify the depth.
>>>> 
>>>> I am looking for a method to obtain the Nth caller at a cost of around
>>>> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>>>> for this use case?
>>> 
>>> We have designed the StackWalker with that in mind
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>>> 
>>> see the discussion on StackWalker.getCallerClass()
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()


From forax at univ-mlv.fr  Wed Apr  6 23:19:49 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Apr 2022 01:19:49 +0200 (CEST)
Subject: fast way to infer caller
In-Reply-To: <ec8b2966-99e6-af1e-6a20-c34b50b38395@qos.ch>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <1502648518.8024274.1649260321527.JavaMail.zimbra@u-pem.fr>
 <41969cca-5247-d8cb-92c5-16e54b10f137@qos.ch>
 <SN7PR18MB4016588AB8701811FF721B7983E79@SN7PR18MB4016.namprd18.prod.outlook.com>
 <ec8b2966-99e6-af1e-6a20-c34b50b38395@qos.ch>
Message-ID: <1516969429.8122634.1649287189841.JavaMail.zimbra@u-pem.fr>



----- Original Message -----
> From: "Ceki G?lc?" <ceki at qos.ch>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, April 7, 2022 1:04:11 AM
> Subject: Re: fast way to infer caller

> Hi Jason,
> 
> Yes, the code was mentioned in SLF4J PR 271.
> 
> The benchmark can be found at
> 
> https://github.com/ceki/logback-perf/tree/master/src/main/java/ch/qos/logback/perf/caller
> 
> Here is the gist of the StackWalker variant:
> 
> public class CallerCompute {
> 
>    static private StackWalker WALKER = StackWalker.getInstance();
> 
>    static public String getCallerClass(int depth) {
> 
>        List<StackFrame> frames = WALKER.walk(s -> s.limit(4).toList());
>        .... process the returned frames
>    }
> }
> 
> The above executes at around 1.8 microseconds per call whereas the code
> in LogRecord.getSourceClassName() executes at 5 microseconds per call.
> The cost of LogRecord constructor is negligible at around 25 nanoseconds.
> 
> Anyway, thank you for the suggestion.

You can declare WALKER "final", it should help. This is also better to call getCallerClass ASAP and then pass the class to the other stack frames instead of having to skip those stack frames when calling getCallerClass. You may also try able to improve the speed by doing a == before calling equals(String) if you call String.intern() on THIS_CLASS_NAME.

> 
> --
> Ceki

R?mi

> 
> 
> On 4/7/2022 12:27 AM, Jason Mehrens wrote:
>> Ceki,
>> 
>> Looks like the benchmark code is from https://github.com/qos-ch/slf4j/pull/271
>> 
>> Looks like the benchmark code is doing a collection so perhaps that is some of
>> the performance hit?
>> Have you benchmarked java.util.LogRecord.getSourceClassName() to compare with
>> your StackWalker benchmark?
>> 
>> https://github.com/openjdk/jdk/blob/master/src/java.logging/share/classes/java/util/logging/LogRecord.java#L754
>> 
>> Jason
>> 
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Ceki
>> G?lc? <ceki at qos.ch>
>> Sent: Wednesday, April 6, 2022 4:26 PM
>> To: core-libs-dev
>> Subject: Re: fast way to infer caller
>> 
>> 
>> Hi R?mi,
>> 
>> Thank you for your answer.
>> 
>> According to some benchmarks on a i7-8565U Intel CPU (quite average
>> CPU), here are the costs of computing the caller class via different
>> methods:
>> 
>> using new Throwable().getStackTrace: 11 microseconds per call
>> using StackWalker API: 1.8 microseconds per call
>> using SecurityManager: 0.9 microseconds per call
>> 
>> While a six fold improvement (StackWalker compared to new Thorowable) is
>> nothing to sneeze at, the performance of StackWalker is not as good as
>> with a custom SecurityManager.
>> 
>> I have not said so explicitly but the aim here is to allow the user to
>> obtain a new logger by calling LoggerFactory.getLogger() with no
>> arguments with the returned logger named after the caller class.
>> 
>> Spending 1 or 2 microseconds for this call is OK if the logger is a
>> static field. However, if the logger is an instance field, then spending
>> 2 microseconds per host object instance just to obtain a logger might
>> have a noticeable impact on performance. It follows that the performance
>> of LoggerFactory.getLogger() must be exceptionally good, assuming we
>> wish to avoid having the user accidentally shooting herself on the foot,
>> ergo the 100 nanosecond performance per call requirement.
>> 
>> Noting that invoking MethodHandles.lookup().lookupClass() seems very
>> fast (about 2 nanoseconds), I would be very interested if  new
>> lookup(int index) method were added to java.lang.invoke.MethodHandles
>> class, with index designating the desired index on the call stack.
>> 
>> Does the above make sense? How difficult would it be to add such a method?
>> 
>> --
>> Ceki G?lc?
>> 
>> 
>> On 4/6/2022 5:52 PM, Remi Forax wrote:
>>> ----- Original Message -----
>>>> From: "Ceki G?lc?" <ceki at qos.ch>
>>>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>>>> Subject: fast way to infer caller
>>>
>>>> Hello,
>>>
>>> Hello,
>>>
>>>>
>>>> As you are probably aware, one of the important primitives used in
>>>> logging libraries is inferring the caller of a given logging statement.
>>>> The current common practice is to create a throwable and process its
>>>> stack trace. This is rather wasteful and rather slow. As an alternative,
>>>> I have tried using the StackWalker API to infer the caller but was
>>>> unsatisfied with the performance.
>>>>
>>>> MethodHandles.lookup().lookupClass() looks very promising except that
>>>> there is no way to specify the depth.
>>>>
>>>> I am looking for a method to obtain the Nth caller at a cost of around
>>>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>>>> for this use case?
>>>
>>> We have designed the StackWalker with that in mind
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>>>
>>> see the discussion on StackWalker.getCallerClass()
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
>>>

From joehw at openjdk.java.net  Thu Apr  7 00:13:45 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:13:45 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:

> 79: 
> 80:     /**
> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");

Locale.France?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:20:31 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:20:31 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <oWowG5ZF6uQhqEOWoDSp17TbGHZqZjmcaxL_5_yGxuU=.b7e9daaf-b3eb-4620-a0a6-01635f37e8ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:

> 129: 
> 130:         // Tests with the Japanese imperial calendar
> 131:         Locale calendarLocale = Locale.of("ja", "JP", "JP");

Locale.JAPAN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 00:31:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 00:31:55 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <UYhQLIeSUDpGNeR1pFuD9ll9SIPZFAnzvRiX-rft8f8=.bdb3a956-ca7a-4523-87d6-71e9a12e5a76@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:

> 61:             Locale.of("it", "IT", "EURO"),
> 62:             Locale.forLanguageTag("de-AT"),
> 63:             Locale.forLanguageTag("fr-CH"),

Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

test/jdk/java/text/Format/common/Bug6215962.java line 58:

> 56:         check(mf1, mf2, false);
> 57: 
> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));

Locale.JAPAN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From duke at openjdk.java.net  Thu Apr  7 00:46:14 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 7 Apr 2022 00:46:14 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null
Message-ID: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>

Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.

At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.

At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:

Class c = open.OpenResources.fetchClass();
InputStream in = c.getResourceAsStream("test.txt");
assert(in != null); in.close();

Module n = c.getModule();
in = n.getResourceAsStream("open/test.txt");
assert(in != null); in.close();

Class closed = closed.ClosedResources.fetchClass();
assert(closedsStream("test.txt") == null);
assert(n.getResourceAsStream("closed/test.txt") == null);

The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

-------------

Commit messages:
 - JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null

Changes: https://git.openjdk.java.net/jdk/pull/8134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281006
  Stats: 397 lines in 7 files changed: 391 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134

From duke at openjdk.java.net  Thu Apr  7 00:56:42 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 7 Apr 2022 00:56:42 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v2]
In-Reply-To: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
Message-ID: <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>

> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
> 
> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
> 
> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  update copyright date

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/b702cae4..4b344e4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134

From naoto at openjdk.java.net  Thu Apr  7 01:19:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Apr 2022 01:19:35 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
Message-ID: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>

On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 
>> 79: 
>> 80:     /**
>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
> 
> Locale.France?

The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 
>> 61:             Locale.of("it", "IT", "EURO"),
>> 62:             Locale.forLanguageTag("de-AT"),
>> 63:             Locale.forLanguageTag("fr-CH"),
> 
> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.

`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

> test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 
>> 56:         check(mf1, mf2, false);
>> 57: 
>> 58:         mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
> 
> Locale.JAPAN?

The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From smarks at openjdk.java.net  Thu Apr  7 01:21:34 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 7 Apr 2022 01:21:34 GMT
Subject: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed
 hierarchy
In-Reply-To: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
References: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
Message-ID: <wl6wUiq-UlkrXIGdtZRZ_qYzP5lARQCaQQ2v3onkQ7s=.72c8b526-38b3-496a-970b-c6e3667e99ed@github.com>

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which now marks `CollectionView` as a `sealed` class with only `EntrySetView`, `KeySetView` and  `ValuesView` as the sub-classes? This change corresponds to https://bugs.openjdk.java.net/browse/JDK-8284036.
> 
> A CSR has also been drafted for this change https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, marking this class as `sealed` and marking `KeySetView` as `final` shouldn't have any impact in general and also in context of serialization/de-serialization.
> 
> tier1, tier2, tier3 tests have been run successfully with this change.

Making KeySetView final (CollectionView a sealed hierarchy) expresses design intent more explicitly than having only private constructors. It also prevents the JVM from loading subclasses that somebody might contrive despite the inability to instantiate them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8085

From vromero at openjdk.java.net  Thu Apr  7 03:38:59 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 7 Apr 2022 03:38:59 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
Message-ID: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>

We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.

Thanks in advance for the reviews,
Vicente

-------------

Commit messages:
 - updating test ValidateJarWithSealedAndRecord
 - adaptations after automatic conversion
 - 8284361: Updating ASM to 9.3 for JDK 19

Changes: https://git.openjdk.java.net/jdk/pull/8135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284361
  Stats: 438 lines in 57 files changed: 73 ins; 70 del; 295 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8135/head:pull/8135

PR: https://git.openjdk.java.net/jdk/pull/8135

From joehw at openjdk.java.net  Thu Apr  7 04:51:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:51:38 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com>

On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>> 
>>> 79: 
>>> 80:     /**
>>> 81:      * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>> 
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here.

I see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:40 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:40 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
 <O1Wg_OPzPP2kpIzubVLsSjItgPu8tCWg-MuTq4xE_lI=.3b70f0c7-9ba4-4994-9c49-7b45dd8552bf@github.com>
 <aku2mIBBVnzFO3xr6BEuEc0Q1_Ad1X2sM3-vTOb0xbI=.4ea9ba22-e75d-4bcb-8942-96767c384f9f@github.com>
Message-ID: <VhDD3losQJHv-SpTfyDeEG5Jb3lX9kYSQ9CoOMD2YIU=.47de2cb7-1289-4f2d-8648-c75320e44ac9@github.com>

On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>> 
>>> 61:             Locale.of("it", "IT", "EURO"),
>>> 62:             Locale.forLanguageTag("de-AT"),
>>> 63:             Locale.forLanguageTag("fr-CH"),
>> 
>> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors.

Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From joehw at openjdk.java.net  Thu Apr  7 04:59:39 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 04:59:39 GMT
Subject: RFR: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <c7WnJL_FTC92jBi5LhA8s1EA-5LMgBW7ucldQb0GQVk=.aa5aa4d7-07a4-4f44-ab61-e89f54adb1ec@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From thartmann at openjdk.java.net  Thu Apr  7 05:41:48 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 7 Apr 2022 05:41:48 GMT
Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog,dlog10,dexp
 iff 2.29 or greater on AArch64.
In-Reply-To: <b3MWQVXYtpJjJQtvz-REaORQjj_5kAiI1KkQFZxTjko=.0ed7381f-693b-4be8-acbe-c65d2fe7dbf3@github.com>
References: <haqvCOdQRYfH7GQWy1m354ckUEChIVOxx1wwbBpnAAc=.10834866-998c-4672-b607-0c58a18974c8@github.com>
 <Pq_6f6mFN959cViwaJJ9qh4rNa2iFbPyI_-4HTwRD1A=.fd8742f3-59b8-411d-a410-02a5e2f5fa8a@github.com>
 <b3MWQVXYtpJjJQtvz-REaORQjj_5kAiI1KkQFZxTjko=.0ed7381f-693b-4be8-acbe-c65d2fe7dbf3@github.com>
Message-ID: <QaIZSNegOezpCsPytLUru378jzFyoWCM1KKWQf-NcvM=.406307a0-f5bf-4981-859a-94ed6e1b2326@github.com>

On Fri, 1 Apr 2022 15:38:36 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects. If this patch is integrated will there be an easy way to get (e.g. from `System.getProperty`) what implementation of exp is in use by the current JVM? Otherwise I won't be able to notify users that the model may not reproduce if they rerun the same computation on different versions of Linux with the same JVM & architecture.
>
>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects.
> 
> Exactly so, and that is why this patch was never integrated. This was only ever going to be about `java.lang.Math`, but we foundered on the rock of monotonicity. Here's the spec:
> 
> "most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements."
> 
> We couldn't guarantee we'd meet the monotonicity requirements if we used glibc libm, so this patch was, with some regret, abandoned.

@theRealAph Thanks for the summary. I closed the JBS issue as Won't Fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510

From alanb at openjdk.java.net  Thu Apr  7 05:55:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 7 Apr 2022 05:55:46 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v2]
In-Reply-To: <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>
Message-ID: <qjQ7uD-8uWie3YBx6Uw2AdfeOtVbtDRHQLiiebILNT8=.3ababa2f-2af3-4699-9352-07e60ddced60@github.com>

On Thu, 7 Apr 2022 00:56:42 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright date

Tim - this creates a conflict between the spec and implementation, the changes to the 2-arg isOpen method need to be dropped so that it continues to throw NPE if module is null.

-------------

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8134

From hiran.chaudhuri at gmx.net  Thu Apr  7 06:57:35 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Thu, 07 Apr 2022 08:57:35 +0200
Subject: jpackage usage problems
In-Reply-To: <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
Message-ID: <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>

Hi there.

I have another case where running jpackage emits

Bundler DEB Bundle failed because of java.lang.NullPointerException:
Cannot invoke "java.lang.CharSequence.length()" because "this.text" is
null

I have never experienced NullPointerExceptions in other JDK tools.
Seems to me JPackage is a new kid on the block. In this case, JPackage
is invoked to finish from an existing appimage to the final package.
the failure is caused because some important files are missing in
appimage.

The previous run is even more puzzling for me. It is supposed to create
the appimage directory. And while it emits no error message, on my
development machine it runs reliably while on the Github Runner it just
does not create all files - no error message, no exit code - nothing.

Any idea what I could be looking at?

Hiran



On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote:
> Hello Alex,
>
> I tried running the same command with the jdk19 you pointed at. As a
> first, I get this output:
>
> $JAVA_HOME/bin/jpackage --version
> 19-ea
>
> With that, I invoked the command as before, and i fairly got the same
> output. So the behaviour in the latest version has not changed.
>
> Two things I'd like to point out:
> - there is no JPackage version in the output itself so both you and
> me
> have to trust the correct one was called
> - I found out the mistake: I should have used
>   --app-image build/app-image/SettlersRemake
>   but JPackage gave a warning in the beginning and processed all the
>   rest
>
> Hiran
>
>
> $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest
> build
> [08:41:58.675] Warning: app-image dir not generated by jpackage.
> [08:41:58.688] Running dpkg
> [08:41:58.696] Command [PID: 21712]:
>     dpkg --print-architecture
> [08:41:58.696] Output:
>     amd64
> [08:41:58.698] Returned: 0
>
> [08:41:58.702] Running dpkg
> [08:41:58.719] Command [PID: 21714]:
>     dpkg -s coreutils
> [08:41:58.719] Output:
>     Package: coreutils
>     Essential: yes
>     Status: install ok installed
>     Priority: required
>     Section: utils
>     Installed-Size: 7196
>     Maintainer: Ubuntu Developers <
> ubuntu-devel-discuss at lists.ubuntu.com>
>     Architecture: amd64
>     Multi-Arch: foreign
>     Version: 8.30-3ubuntu2
>     Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6
> (>=
> 2.28), libselinux1 (>= 2.1.13)
>     Description: GNU core utilities
>      This package contains the basic file, shell and text
> manipulation
>      utilities which are expected to exist on every operating system.
>      .
>      Specifically, this package includes:
>      arch base64 basename cat chcon chgrp chmod chown chroot cksum
> comm
> cp
>      csplit cut date dd df dir dircolors dirname du echo env expand
> expr
>      factor false flock fmt fold groups head hostid id install join
> link ln
>      logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup
> nproc
> numfmt
>      od paste pathchk pinky pr printenv printf ptx pwd readlink
> realpath rm
>      rmdir runcon sha*sum seq shred sleep sort split stat stty sum
> sync
> tac
>      tail tee test timeout touch tr true truncate tsort tty uname
> unexpand
>      uniq unlink users vdir wc who whoami yes
>     Homepage: http://gnu.org/software/coreutils
>     Original-Maintainer: Michael Stone <mstone at debian.org>
> [08:41:58.719] Returned: 0
>
> [08:41:58.720] Running dpkg-deb
> [08:41:58.722] Warning: app-image dir not generated by jpackage.
> [08:41:58.723] Warning: app-image dir not generated by jpackage.
> [08:41:58.723] java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>         at
> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>         at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>         at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>         at
> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>         at
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li
> nu
> xDebBundler.java:84)
>         at
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux
> Pa
> ckageBundler.java:72)
>         at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
> .j
> ava:688)
>         at
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen
> ts
> .java:561)
>         at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>         at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB
> Bundle failed because of java.lang.NullPointerException: Cannot
> invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>         at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
> .j
> ava:710)
>         at
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen
> ts
> .java:561)
>         at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>         at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "this.text" is null
>         at
> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>         at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>         at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>         at
> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>         at
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li
> nu
> xDebBundler.java:84)
>         at
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux
> Pa
> ckageBundler.java:72)
>         at
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
> .j
> ava:688)
>         ... 3 more
>
>
> On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote:
> > Hi Hiran,
> >
> > Looks like jpackage fails because of missing package name on the
> > command
> > line.
> > I agree that the error message is not helpful. Can you try one of
> > jdk19
> > EA builds [1] to see if the problem is reproducible?
> >
> > [1] https://jdk.java.net/19/
> >
> > - Alexey
> >
> > On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
> > > Hello there.
> > >
> > > While I am trying to package my project using jpackage 16.0.1 on
> > > Ubuntu
> > > 20 LTS I have difficulty in assembling the correct commands.
> > >
> > > The documentation covers a lot but not everything. For example,
> > > it
> > > is
> > > not clear to me when I have to provide an option - especially
> > > since
> > > I
> > > meanwhile take a two step approach of building the appimage, then
> > > tweaking something (that could have done by JPackage directly)
> > > and
> > > finally building the DEB package.
> > >
> > > While I believe the documentation is good enough, the error
> > > messages
> > > presented by JPackage are not. Here is one example. Hopefully you
> > > agree
> > > that the NullPointerException does not at all tell me what is
> > > wrong
> > > and
> > > what I could improve on.
> > >
> > > My feeling is that JPackage should do some better error handling
> > > and
> > > come up with improved messages.
> > >
> > > Hiran
> > >
> > >
> > > $ jpackage --app-image build/app-image --verbose --dest build
> > > [10:34:45.915] Warning: app-image dir not generated by jpackage.
> > > [10:34:45.930] Running dpkg
> > > [10:34:45.937] Command:
> > >      dpkg --print-architecture
> > > [10:34:45.937] Output:
> > >      amd64
> > > [10:34:45.939] Returned: 0
> > >
> > > [10:34:45.944] Running dpkg
> > > [10:34:45.961] Command:
> > >      dpkg -s coreutils
> > > [10:34:45.962] Output:
> > >      Package: coreutils
> > >      Essential: yes
> > >      Status: install ok installed
> > >      Priority: required
> > >      Section: utils
> > >      Installed-Size: 7196
> > >      Maintainer: Ubuntu Developers <
> > > ubuntu-devel-discuss at lists.ubuntu.com>
> > >      Architecture: amd64
> > >      Multi-Arch: foreign
> > >      Version: 8.30-3ubuntu2
> > >      Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44),
> > > libc6 (>=
> > > 2.28), libselinux1 (>= 2.1.13)
> > >      Description: GNU core utilities
> > >       This package contains the basic file, shell and text
> > > manipulation
> > >       utilities which are expected to exist on every operating
> > > system.
> > >       .
> > >       Specifically, this package includes:
> > >       arch base64 basename cat chcon chgrp chmod chown chroot
> > > cksum
> > > comm
> > > cp
> > >       csplit cut date dd df dir dircolors dirname du echo env
> > > expand
> > > expr
> > >       factor false flock fmt fold groups head hostid id install
> > > join
> > > link ln
> > >       logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
> > > nohup
> > > nproc
> > > numfmt
> > >       od paste pathchk pinky pr printenv printf ptx pwd readlink
> > > realpath rm
> > >       rmdir runcon sha*sum seq shred sleep sort split stat stty
> > > sum
> > > sync
> > > tac
> > >       tail tee test timeout touch tr true truncate tsort tty
> > > uname
> > > unexpand
> > >       uniq unlink users vdir wc who whoami yes
> > >      Homepage: http://gnu.org/software/coreutils
> > >      Original-Maintainer: Michael Stone <mstone at debian.org>
> > > [10:34:45.962] Returned: 0
> > >
> > > [10:34:45.963] Running dpkg-deb
> > > [10:34:45.965] Warning: app-image dir not generated by jpackage.
> > > [10:34:45.967] Warning: app-image dir not generated by jpackage.
> > > [10:34:45.967] java.lang.NullPointerException: Cannot invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
> > > )
> > >          at
> > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > >          at
> > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > >          at
> > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
> > > 1(
> > > Linu
> > > xDebBundler.java:83)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
> > > in
> > > uxPa
> > > ckageBundler.java:72)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > en
> > > ts.j
> > > ava:663)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
> > > um
> > > ents
> > > .java:538)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > [10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler
> > > DEB
> > > Bundle failed because of java.lang.NullPointerException: Cannot
> > > invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > en
> > > ts.j
> > > ava:685)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
> > > um
> > > ents
> > > .java:538)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > Caused by: java.lang.NullPointerException: Cannot invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
> > > )
> > >          at
> > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > >          at
> > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > >          at
> > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
> > > 1(
> > > Linu
> > > xDebBundler.java:83)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
> > > in
> > > uxPa
> > > ckageBundler.java:72)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > en
> > > ts.j
> > > ava:663)
> > >          ... 3 more
> > >
> > > $
> > >
> > >


From luhenry at openjdk.java.net  Thu Apr  7 07:01:23 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 7 Apr 2022 07:01:23 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v9]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <E-61wcoVVCPU3QGDpmw0zr_ceOW-iNtzeR-z3r2HhtE=.0cf457a0-61db-43f0-9a45-1de26ef8ee07@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:

  Fix some merge conflicts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7700/files
  - new: https://git.openjdk.java.net/jdk/pull/7700/files/1935cf31..a6f75c2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=07-08

  Stats: 11 lines in 1 file changed: 0 ins; 9 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From dl at openjdk.java.net  Thu Apr  7 11:37:39 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Thu, 7 Apr 2022 11:37:39 GMT
Subject: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed
 hierarchy
In-Reply-To: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
References: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
Message-ID: <qiOgqHOgjulBaeq5LCqGSyysnX16gYkhJSvzLDZMjok=.52810520-1974-4541-bad2-5317ff7831ab@github.com>

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which now marks `CollectionView` as a `sealed` class with only `EntrySetView`, `KeySetView` and  `ValuesView` as the sub-classes? This change corresponds to https://bugs.openjdk.java.net/browse/JDK-8284036.
> 
> A CSR has also been drafted for this change https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, marking this class as `sealed` and marking `KeySetView` as `final` shouldn't have any impact in general and also in context of serialization/de-serialization.
> 
> tier1, tier2, tier3 tests have been run successfully with this change.

OK. I don't have any objections to doing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8085

From kasperni at gmail.com  Thu Apr  7 11:53:33 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Thu, 7 Apr 2022 12:53:33 +0100
Subject: fast way to infer caller
In-Reply-To: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
Message-ID: <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>

>
> MethodHandles.lookup().lookupClass() looks very promising except that
> there is no way to specify the depth.
>
> I am looking for a method to obtain the Nth caller at a cost of around
> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
> for this use case?
>

Hi Ceki,

I don't think you will find the numbers you are looking for with
StackWalker.
Compared to something like Reflection.getCallerClass() which
MethodHandles.lookup() uses.
There is still a very large (>100x) performance gap between the two.

public class StackWalkerPerf {

    static final StackWalker sw =
StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);

    @Benchmark
    public Class<?> stackWalkerCallerClass() {
        return sw.getCallerClass();
    }

    @Benchmark
    public Class<?> reflectionCallerClass() {
        return MethodHandles.lookup().lookupClass();
    }
}

Benchmark                               Mode  Cnt     Score    Error  Units
StackWalkerPerf.reflectionCallerClass   avgt   10    2,927 ? 0,012  ns/op
StackWalkerPerf.stackWalkerCallerClass  avgt   10  915,287 ? 9,565  ns/op

/Kasper

From forax at univ-mlv.fr  Thu Apr  7 12:32:39 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Apr 2022 14:32:39 +0200 (CEST)
Subject: fast way to infer caller
In-Reply-To: <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
Message-ID: <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Kasper Nielsen" <kasperni at gmail.com>
> To: "Ceki G?lc?" <ceki at qos.ch>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, April 7, 2022 1:53:33 PM
> Subject: Re: fast way to infer caller

>>
>> MethodHandles.lookup().lookupClass() looks very promising except that
>> there is no way to specify the depth.
>>
>> I am looking for a method to obtain the Nth caller at a cost of around
>> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
>> for this use case?
>>
> 
> Hi Ceki,
> 
> I don't think you will find the numbers you are looking for with
> StackWalker.
> Compared to something like Reflection.getCallerClass() which
> MethodHandles.lookup() uses.
> There is still a very large (>100x) performance gap between the two.
> 
> public class StackWalkerPerf {
> 
>    static final StackWalker sw =
> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
> 
>    @Benchmark
>    public Class<?> stackWalkerCallerClass() {
>        return sw.getCallerClass();
>    }
> 
>    @Benchmark
>    public Class<?> reflectionCallerClass() {
>        return MethodHandles.lookup().lookupClass();
>    }
> }
> 
> Benchmark                               Mode  Cnt     Score    Error  Units
> StackWalkerPerf.reflectionCallerClass   avgt   10    2,927 ? 0,012  ns/op
> StackWalkerPerf.stackWalkerCallerClass  avgt   10  915,287 ? 9,565  ns/op

The resulting class is not the same, so comparing the performance of two codes that does not do the same thing is dubious, no ?

> 
> /Kasper

R?mi

From kasperni at gmail.com  Thu Apr  7 12:42:46 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Thu, 7 Apr 2022 13:42:46 +0100
Subject: fast way to infer caller
In-Reply-To: <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>

On Thu, 7 Apr 2022 at 13:33, Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Kasper Nielsen" <kasperni at gmail.com>
> > To: "Ceki G?lc?" <ceki at qos.ch>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Sent: Thursday, April 7, 2022 1:53:33 PM
> > Subject: Re: fast way to infer caller
>
> >>
> >> MethodHandles.lookup().lookupClass() looks very promising except that
> >> there is no way to specify the depth.
> >>
> >> I am looking for a method to obtain the Nth caller at a cost of around
> >> 100 to 200 nanoseconds of CPU time.  Do you think the JDK could cater
> >> for this use case?
> >>
> >
> > Hi Ceki,
> >
> > I don't think you will find the numbers you are looking for with
> > StackWalker.
> > Compared to something like Reflection.getCallerClass() which
> > MethodHandles.lookup() uses.
> > There is still a very large (>100x) performance gap between the two.
> >
> > public class StackWalkerPerf {
> >
> >    static final StackWalker sw =
> > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
> >
> >    @Benchmark
> >    public Class<?> stackWalkerCallerClass() {
> >        return sw.getCallerClass();
> >    }
> >
> >    @Benchmark
> >    public Class<?> reflectionCallerClass() {
> >        return MethodHandles.lookup().lookupClass();
> >    }
> > }
> >
> > Benchmark                               Mode  Cnt     Score    Error
> Units
> > StackWalkerPerf.reflectionCallerClass   avgt   10    2,927 ? 0,012  ns/op
> > StackWalkerPerf.stackWalkerCallerClass  avgt   10  915,287 ? 9,565  ns/op
>
> > The resulting class is not the same, so comparing the performance of two
> codes that does not do the same thing is dubious, no ?


I think it is a fair test. MethodHandles.lookup() is basically just
wrapping Reflection.getCallerClass(). So if anything
calling Reflection.getCallerClass() directly would be even faster than
calling MethodHandles.lookup().lookupClass();

/Kasper

From erikj at openjdk.java.net  Thu Apr  7 13:00:41 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 7 Apr 2022 13:00:41 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v2]
In-Reply-To: <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>
Message-ID: <ILByXnJ3BK8ze8rFjtqzfpf42wviLO1QL4CVqq-iXgI=.be179ddc-0563-49cc-8d5c-a787537bcbbb@github.com>

On Thu, 7 Apr 2022 00:56:42 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright date

Build change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8134

From forax at univ-mlv.fr  Thu Apr  7 13:37:22 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 7 Apr 2022 15:37:22 +0200 (CEST)
Subject: fast way to infer caller
In-Reply-To: <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
Message-ID: <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>

> From: "Kasper Nielsen" <kasperni at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Ceki G?lc?" <ceki at qos.ch>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, April 7, 2022 2:42:46 PM
> Subject: Re: fast way to infer caller

> On Thu, 7 Apr 2022 at 13:33, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "Kasper Nielsen" < [ mailto:kasperni at gmail.com | kasperni at gmail.com ] >
>> > To: "Ceki G?lc?" < [ mailto:ceki at qos.ch | ceki at qos.ch ] >
>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>> > core-libs-dev at openjdk.java.net ] >
>> > Sent: Thursday, April 7, 2022 1:53:33 PM
>> > Subject: Re: fast way to infer caller


>> >> MethodHandles.lookup().lookupClass() looks very promising except that
>> >> there is no way to specify the depth.

>> >> I am looking for a method to obtain the Nth caller at a cost of around
>> >> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>> >> for this use case?


>> > Hi Ceki,

>> > I don't think you will find the numbers you are looking for with
>> > StackWalker.
>> > Compared to something like Reflection.getCallerClass() which
>> > MethodHandles.lookup() uses.
>> > There is still a very large (>100x) performance gap between the two.

>> > public class StackWalkerPerf {

>> > static final StackWalker sw =
>> > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);

>> > @Benchmark
>> > public Class<?> stackWalkerCallerClass() {
>> > return sw.getCallerClass();
>> > }

>> > @Benchmark
>> > public Class<?> reflectionCallerClass() {
>> > return MethodHandles.lookup().lookupClass();
>> > }
>> > }

>> > Benchmark Mode Cnt Score Error Units
>> > StackWalkerPerf.reflectionCallerClass avgt 10 2,927 ? 0,012 ns/op
>> > StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ? 9,565 ns/op

>>> The resulting class is not the same, so comparing the performance of two codes
>> > that does not do the same thing is dubious, no ?
> I think it is a fair test. MethodHandles.lookup() is basically just wrapping
> Reflection.getCallerClass(). So if anything
> calling Reflection.getCallerClass() directly would be even faster than calling
> MethodHandles.lookup().lookupClass();

nope, see my previous mail to Ceki, the VM is cheating here if it can inline the call to MethodHandles.lookup(). 

> /Kasper

R?mi 

From ceki at qos.ch  Thu Apr  7 13:38:25 2022
From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=)
Date: Thu, 7 Apr 2022 15:38:25 +0200
Subject: fast way to infer caller
In-Reply-To: <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
Message-ID: <cf737f3c-9902-1247-df03-2a3b3a127166@qos.ch>


R?mi, Jason, Steven, Kasper,

Thank you all for your thoughtful feedback.

I forgot to mention that in addition to obtaining the appropriate logger
by inferring caller class, the caller class may also be a data point
written with each logging event, aka LogRecord.

If the cost of writing a log event to file is 500 nanoseconds (without
caller data), spending additional 1800 nanoseconds to obtain caller data
via StackWalker reduces throughput by a factor of 4.8. Mind you, this is
still much better than obtaining caller data via "new
Throwable().getStackTrace();" which costs about 11'000 nanoseconds,
reducing throughput by a factor of 24.

While logging 2'000'000 messages per second is not a goal, reducing the
cost of logging as much as possible, is a worthwhile goal. At present
time, retrieving caller data still has a significant effect on logging
performance.



-- 
Ceki G?lc?

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

From redestad at openjdk.java.net  Thu Apr  7 14:03:58 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 7 Apr 2022 14:03:58 GMT
Subject: RFR: 8283892: Compress and expand bits [v2]
In-Reply-To: <RVo_i9zZ8W85PS19LPswsEtT6MGwbR6PPySKGXDMBnE=.2d07a620-6386-4d23-9908-74def1bb10af@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <RVo_i9zZ8W85PS19LPswsEtT6MGwbR6PPySKGXDMBnE=.2d07a620-6386-4d23-9908-74def1bb10af@github.com>
Message-ID: <dHVGU2rCwb_VZf2wVPHHy47sQ5OpxXZuSAzaP47ib5k=.669f44bd-f0fe-4143-802d-8401cebb4b10@github.com>

On Wed, 6 Apr 2022 21:57:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
>> 
>> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
>> 
>> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
>> 
>> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
>> 
>> Testing-wise the approach take is three fold:
>> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
>> 2. Tests composed of compress and expand and vice versa.
>> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc and test updates.

I experimented with this and drafted a few microbenchmarks along and a micro-optimization to the expand methods (see #8146). Up to you, but I think it makes sense to consider such optimizations to the plain java implementation given that 1) not all platforms have specialized instructions where an intrinsic will make sense and 2) it appears to be a boost to warmup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From jnimeh at openjdk.java.net  Thu Apr  7 14:45:44 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 7 Apr 2022 14:45:44 GMT
Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias
 warning if an intermediate cert is in this keystore
In-Reply-To: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
References: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
Message-ID: <gc0TJ3FpV20Bwi_BYvNFCX1bcfHyyuf1xpVHO0P0sUo=.1ddb8696-5553-4ad8-a5d6-571f55dea37c@github.com>

On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8234128
> 
> My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message.

test/jdk/sun/security/tools/jarsigner/warnings/AliasNotInStoreTest2.java line 50:

> 48: 
> 49:         createAlias(CA_KEY_ALIAS, "-ext", "bc");
> 50:         createAlias(FIRST_KEY_ALIAS);

Is this creating a 3-cert chain (signer -> intermediate -> trust anchor) or just a 2-cert chain (signer -> trust anchor)?  I ask because the bug description specifies that it requires a missing signer alias but an intermediate CA being present (and I assume the TA as well).  This looks like it's creating a 2-cert chain.  From looking at the loop in intKeyStoreForOneSigner perhaps it doesn't matter and a 2-cert is just as good as a 3-cert chain.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7751

From psandoz at openjdk.java.net  Thu Apr  7 14:53:53 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 14:53:53 GMT
Subject: RFR: 8283892: Compress and expand bits [v2]
In-Reply-To: <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
Message-ID: <fqH7TAumkeRIS_p0pw6c4PupM4aq0qgqz3_gTqtQw9w=.e8e51997-5f53-48f0-9cd5-f0fd52d8da75@github.com>

On Wed, 6 Apr 2022 17:39:48 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 145:
> 
>> 143: 
>> 144:         int i = 0;
>> 145:         for (int len = 0; len < 32; len++) {
> 
> Lengths should be `len = 1; len <= 32; len++`, generating fewer redundant zero-length masks and a full-length -1 mask.  The pos should be `pos = 0; pos <= 32 - len; pos++`, generating fully left-justified masks of the form `-1<<pos`.
> 
> Also, you should generate a zero-mask, just once.  I think initializing `int i = 1` will do that trick.
> 
> (Same comment in two places.)

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From psandoz at openjdk.java.net  Thu Apr  7 14:57:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 14:57:44 GMT
Subject: RFR: 8283892: Compress and expand bits [v2]
In-Reply-To: <dHVGU2rCwb_VZf2wVPHHy47sQ5OpxXZuSAzaP47ib5k=.669f44bd-f0fe-4143-802d-8401cebb4b10@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <RVo_i9zZ8W85PS19LPswsEtT6MGwbR6PPySKGXDMBnE=.2d07a620-6386-4d23-9908-74def1bb10af@github.com>
 <dHVGU2rCwb_VZf2wVPHHy47sQ5OpxXZuSAzaP47ib5k=.669f44bd-f0fe-4143-802d-8401cebb4b10@github.com>
Message-ID: <m_HNjsc7uWBU9TGG-S4ZG3wjxrgomoxkhiwFnEqXd0M=.a4ed81f4-434b-4453-af69-50a3a27158b5@github.com>

On Thu, 7 Apr 2022 14:01:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc and test updates.
>
> I experimented with this and drafted a few microbenchmarks along and a micro-optimization to the expand methods (see #8146). Up to you, but I think it makes sense to consider such optimizations to the plain java implementation given that 1) not all platforms have specialized instructions where an intrinsic will make sense and 2) it appears to be a boost to warmup.

@cl4es thanks, your changes to `expand` looks reasonable, given the array allocation cost.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From djelinski at openjdk.java.net  Thu Apr  7 14:58:43 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Apr 2022 14:58:43 GMT
Subject: Integrated: 8284444: Sting typo
In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com>
Message-ID: <DLTDZ2b9bR7P6zsb0sW9B66BYoCBNu2PLj9iQ7k9Igc=.ec1a801a-c6f8-44f4-9706-44954c74e0fa@github.com>

On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch adds missing `r` in `string`s

This pull request has now been integrated.

Changeset: 5bafcfdc
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5bafcfdc171b5a514ecf620703e77fa2f4a49c58
Stats:     10 lines in 5 files changed: 0 ins; 0 del; 10 mod

8284444: Sting typo

Reviewed-by: kcr, aivanov, mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/8125

From duke at openjdk.java.net  Thu Apr  7 15:09:42 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Thu, 7 Apr 2022 15:09:42 GMT
Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias
 warning if an intermediate cert is in this keystore
In-Reply-To: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
References: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
Message-ID: <J-H6bwrYgcjUgCrMSEEDIlwBOCcjAONiWDa0pKMFXpY=.66151851-1b7d-4525-905f-0f07f36916b8@github.com>

On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8234128
> 
> My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message.

I recall that Max said the intermediate was not necessary. Maybe he can chime in.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7751

From jnimeh at openjdk.java.net  Thu Apr  7 15:14:37 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Thu, 7 Apr 2022 15:14:37 GMT
Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias
 warning if an intermediate cert is in this keystore
In-Reply-To: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
References: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
Message-ID: <zBx9DspBEx9nA7kup9D3Nh1HtKXh9_OTQzA5EmDqNk8=.7bb92d0b-a331-4ef0-ae14-732b7b984006@github.com>

On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8234128
> 
> My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message.

Looks good to me.

Yeah, the loop seems like it would behave the same way with or without the intermediate CA cert for the purposes of the warning message.  I'm good with it.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7751

From duke at openjdk.java.net  Thu Apr  7 15:21:42 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 7 Apr 2022 15:21:42 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v2]
In-Reply-To: <qjQ7uD-8uWie3YBx6Uw2AdfeOtVbtDRHQLiiebILNT8=.3ababa2f-2af3-4699-9352-07e60ddced60@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <ezZZPCHO1YPBl6OrX6pyGVxG5S8eECRM2lseTUU8Pp0=.f35c3458-8fec-4082-8e13-f1e39ba1a1cd@github.com>
 <qjQ7uD-8uWie3YBx6Uw2AdfeOtVbtDRHQLiiebILNT8=.3ababa2f-2af3-4699-9352-07e60ddced60@github.com>
Message-ID: <lSjhhQwk-uTNTk1xHw3NeyO-Lzfu4CSxj7dkTjjBugw=.f77a885b-defb-42b9-b4bf-8e4def85702b@github.com>

On Thu, 7 Apr 2022 05:52:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Tim - this creates a conflict between the spec and implementation, the changes to the 2-arg isOpen method need to be dropped so that it continues to throw NPE if module is null.

okay

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From duke at openjdk.java.net  Thu Apr  7 15:57:43 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Thu, 7 Apr 2022 15:57:43 GMT
Subject: Integrated: JDK-8234128 jarsigner will not show not-signed-by-alias
 warning if an intermediate cert is in this keystore
In-Reply-To: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
References: <jNqtN0MgQV5oGSz7zM9EZ585efxIObXB6l14gmg_Zbc=.0a1083ff-c4df-41d8-8a2c-7469e1470ea5@github.com>
Message-ID: <VCaMFK_TWsEBZZ9gmrgkhnvNpRnYRVe_venztESjYIs=.1522a476-193e-4a28-be50-876fa885b09a@github.com>

On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8234128
> 
> My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message.

This pull request has now been integrated.

Changeset: d6f01e9d
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6f01e9d6f35fb235d9b9fb674867c9760b1c1d1
Stats:     101 lines in 2 files changed: 99 ins; 0 del; 2 mod

8234128: jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore

Reviewed-by: jnimeh

-------------

PR: https://git.openjdk.java.net/jdk/pull/7751

From psandoz at openjdk.java.net  Thu Apr  7 16:12:21 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 16:12:21 GMT
Subject: RFR: 8283892: Compress and expand bits [v3]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <3wESORtuM1TQ2M-a_WKptt5q78UeVpThJ4_Q1aYYRYQ=.d6aac400-e67f-4eb2-b7ed-901dab110d7e@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with five additional commits since the last revision:

 - Merge remote-tracking branch 'cl4es/expand_a_bit_more' into compress-expand-bits
 - Rename partx -> maskPrefixx, add ForceInline
 - Fix copy-paste error in Long.expand
 - Add microbenchmarks and manually unroll expand implementations
 - Consistent bounds.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/8c536de6..da49874b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=01-02

  Stats: 163 lines in 5 files changed: 107 ins; 11 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From kasperni at gmail.com  Thu Apr  7 17:27:52 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Thu, 7 Apr 2022 18:27:52 +0100
Subject: fast way to infer caller
In-Reply-To: <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>

>
> nope, see my previous mail to Ceki, the VM is cheating here if it can
> inline the call to MethodHandles.lookup()
>

Does how the VM cheats really matter? The fact is that the code in the JDK
can
get the calling class and implement something like MethodHandles.lookup() so
it takes ~3 ns. If you implemented something like a lookup class as a normal
user your best bet would be StackWalker.GetCallingClass() and you would end
up with something that is at least 2 magnitudes slower. That is probably not
an issue for most use cases. But for some, it might be a bit of a steep
cost.

/Kasper

From jdk at fiolino.de  Thu Apr  7 17:55:16 2022
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Thu, 7 Apr 2022 19:55:16 +0200
Subject: fast way to infer caller
In-Reply-To: <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
Message-ID: <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>



On 4/7/22 19:27, Kasper Nielsen wrote:
>>
>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>> inline the call to MethodHandles.lookup()
>>
> 
> Does how the VM cheats really matter? The fact is that the code in the JDK
> can
> get the calling class and implement something like MethodHandles.lookup() so
> it takes ~3 ns. If you implemented something like a lookup class as a normal
> user your best bet would be StackWalker.GetCallingClass() and you would end
> up with something that is at least 2 magnitudes slower. That is probably not
> an issue for most use cases. But for some, it might be a bit of a steep
> cost.
> 
> /Kasper

Hi Kasper,

sorry to jump in here as an uninvolved onlooker, but I can't resist.
I really don't see why this should matter. Getting the caller class is a 
rare edge case that you just do in exceptional situations; most often 
it's more for debugging or something.

What users really are interested in is high performance for standard 
cases. Implementing a specific optimization into Hotspot to gain few 
milliseconds is the least thing I expect from the JVM developers.

I also don't understand why someone should instantiate a logger during 
performance critical procedures. In more than 20 years of Java 
development, I've never seen the need to create a logger on the fly. 
They are *always* assigned to final static variables, or at least to 
predefined pools. Everything else would be just wrong: To instantiate a 
logger, you have to fetch at least the log level definition from some 
configuration source, and this can never be fast. At least not that 
we're talking about nanoseconds here.

All logging implementations I know of (and all that make sense) are 
highly optimized on log throughput; this can only be achieved by 
preprocessing during initialization, why this is slow. But that doesn't 
matter, because, as said, you should anyway create logger instances 
beforehand.

Sorry for the rant, but I really don't see the use case here.

From ecki at zusammenkunft.net  Thu Apr  7 18:02:07 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 7 Apr 2022 18:02:07 +0000
Subject: fast way to infer caller
In-Reply-To: <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
Message-ID: <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated).

 for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops.

But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well.

--
https://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Michael Kuhlmann <jdk at fiolino.de>
Sent: Thursday, April 7, 2022 7:55:16 PM
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: Re: fast way to infer caller



On 4/7/22 19:27, Kasper Nielsen wrote:
>>
>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>> inline the call to MethodHandles.lookup()
>>
>
> Does how the VM cheats really matter? The fact is that the code in the JDK
> can
> get the calling class and implement something like MethodHandles.lookup() so
> it takes ~3 ns. If you implemented something like a lookup class as a normal
> user your best bet would be StackWalker.GetCallingClass() and you would end
> up with something that is at least 2 magnitudes slower. That is probably not
> an issue for most use cases. But for some, it might be a bit of a steep
> cost.
>
> /Kasper

Hi Kasper,

sorry to jump in here as an uninvolved onlooker, but I can't resist.
I really don't see why this should matter. Getting the caller class is a
rare edge case that you just do in exceptional situations; most often
it's more for debugging or something.

What users really are interested in is high performance for standard
cases. Implementing a specific optimization into Hotspot to gain few
milliseconds is the least thing I expect from the JVM developers.

I also don't understand why someone should instantiate a logger during
performance critical procedures. In more than 20 years of Java
development, I've never seen the need to create a logger on the fly.
They are *always* assigned to final static variables, or at least to
predefined pools. Everything else would be just wrong: To instantiate a
logger, you have to fetch at least the log level definition from some
configuration source, and this can never be fast. At least not that
we're talking about nanoseconds here.

All logging implementations I know of (and all that make sense) are
highly optimized on log throughput; this can only be achieved by
preprocessing during initialization, why this is slow. But that doesn't
matter, because, as said, you should anyway create logger instances
beforehand.

Sorry for the rant, but I really don't see the use case here.

From alexey.semenyuk at oracle.com  Thu Apr  7 18:16:14 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 7 Apr 2022 14:16:14 -0400
Subject: jpackage usage problems
In-Reply-To: <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
Message-ID: <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>

Hi Hiran,

My apologies for not replying to your previous email. In that particular 
case the problem seems to be in missing "--name" cli option on the 
second jpackage command line ($JAVA_HOME/bin/jpackage --app-image 
build/app-image --verbose --dest build) that is supposed to build .deb 
package from the app image.
Could you please confirm this is the case so I can file more specific 
description in a CR tracking this issue.

Do you have a stack trace for the second NPE? It would help to 
understand what went wrong.

Issue with the Github Runner looks similar to this one [1]

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-March/086656.html

- Alexey

On 4/7/2022 2:57 AM, Hiran Chaudhuri wrote:
> Hi there.
>
> I have another case where running jpackage emits
>
> Bundler DEB Bundle failed because of java.lang.NullPointerException:
> Cannot invoke "java.lang.CharSequence.length()" because "this.text" is
> null
>
> I have never experienced NullPointerExceptions in other JDK tools.
> Seems to me JPackage is a new kid on the block. In this case, JPackage
> is invoked to finish from an existing appimage to the final package.
> the failure is caused because some important files are missing in
> appimage.
>
> The previous run is even more puzzling for me. It is supposed to create
> the appimage directory. And while it emits no error message, on my
> development machine it runs reliably while on the Github Runner it just
> does not create all files - no error message, no exit code - nothing.
>
> Any idea what I could be looking at?
>
> Hiran
>
>
>
> On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote:
>> Hello Alex,
>>
>> I tried running the same command with the jdk19 you pointed at. As a
>> first, I get this output:
>>
>> $JAVA_HOME/bin/jpackage --version
>> 19-ea
>>
>> With that, I invoked the command as before, and i fairly got the same
>> output. So the behaviour in the latest version has not changed.
>>
>> Two things I'd like to point out:
>> - there is no JPackage version in the output itself so both you and
>> me
>> have to trust the correct one was called
>> - I found out the mistake: I should have used
>>    --app-image build/app-image/SettlersRemake
>>    but JPackage gave a warning in the beginning and processed all the
>>    rest
>>
>> Hiran
>>
>>
>> $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest
>> build
>> [08:41:58.675] Warning: app-image dir not generated by jpackage.
>> [08:41:58.688] Running dpkg
>> [08:41:58.696] Command [PID: 21712]:
>>      dpkg --print-architecture
>> [08:41:58.696] Output:
>>      amd64
>> [08:41:58.698] Returned: 0
>>
>> [08:41:58.702] Running dpkg
>> [08:41:58.719] Command [PID: 21714]:
>>      dpkg -s coreutils
>> [08:41:58.719] Output:
>>      Package: coreutils
>>      Essential: yes
>>      Status: install ok installed
>>      Priority: required
>>      Section: utils
>>      Installed-Size: 7196
>>      Maintainer: Ubuntu Developers <
>> ubuntu-devel-discuss at lists.ubuntu.com>
>>      Architecture: amd64
>>      Multi-Arch: foreign
>>      Version: 8.30-3ubuntu2
>>      Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6
>> (>=
>> 2.28), libselinux1 (>= 2.1.13)
>>      Description: GNU core utilities
>>       This package contains the basic file, shell and text
>> manipulation
>>       utilities which are expected to exist on every operating system.
>>       .
>>       Specifically, this package includes:
>>       arch base64 basename cat chcon chgrp chmod chown chroot cksum
>> comm
>> cp
>>       csplit cut date dd df dir dircolors dirname du echo env expand
>> expr
>>       factor false flock fmt fold groups head hostid id install join
>> link ln
>>       logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup
>> nproc
>> numfmt
>>       od paste pathchk pinky pr printenv printf ptx pwd readlink
>> realpath rm
>>       rmdir runcon sha*sum seq shred sleep sort split stat stty sum
>> sync
>> tac
>>       tail tee test timeout touch tr true truncate tsort tty uname
>> unexpand
>>       uniq unlink users vdir wc who whoami yes
>>      Homepage: http://gnu.org/software/coreutils
>>      Original-Maintainer: Michael Stone <mstone at debian.org>
>> [08:41:58.719] Returned: 0
>>
>> [08:41:58.720] Running dpkg-deb
>> [08:41:58.722] Warning: app-image dir not generated by jpackage.
>> [08:41:58.723] Warning: app-image dir not generated by jpackage.
>> [08:41:58.723] java.lang.NullPointerException: Cannot invoke
>> "java.lang.CharSequence.length()" because "this.text" is null
>>          at
>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>>          at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>          at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>          at
>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li
>> nu
>> xDebBundler.java:84)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux
>> Pa
>> ckageBundler.java:72)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
>> .j
>> ava:688)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen
>> ts
>> .java:561)
>>          at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>>          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>> [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB
>> Bundle failed because of java.lang.NullPointerException: Cannot
>> invoke
>> "java.lang.CharSequence.length()" because "this.text" is null
>>          at
>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
>> .j
>> ava:710)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen
>> ts
>> .java:561)
>>          at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>>          at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>> Caused by: java.lang.NullPointerException: Cannot invoke
>> "java.lang.CharSequence.length()" because "this.text" is null
>>          at
>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769)
>>          at java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>          at java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>          at
>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li
>> nu
>> xDebBundler.java:84)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux
>> Pa
>> ckageBundler.java:72)
>>          at
>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments
>> .j
>> ava:688)
>>          ... 3 more
>>
>>
>> On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote:
>>> Hi Hiran,
>>>
>>> Looks like jpackage fails because of missing package name on the
>>> command
>>> line.
>>> I agree that the error message is not helpful. Can you try one of
>>> jdk19
>>> EA builds [1] to see if the problem is reproducible?
>>>
>>> [1] https://jdk.java.net/19/
>>>
>>> - Alexey
>>>
>>> On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
>>>> Hello there.
>>>>
>>>> While I am trying to package my project using jpackage 16.0.1 on
>>>> Ubuntu
>>>> 20 LTS I have difficulty in assembling the correct commands.
>>>>
>>>> The documentation covers a lot but not everything. For example,
>>>> it
>>>> is
>>>> not clear to me when I have to provide an option - especially
>>>> since
>>>> I
>>>> meanwhile take a two step approach of building the appimage, then
>>>> tweaking something (that could have done by JPackage directly)
>>>> and
>>>> finally building the DEB package.
>>>>
>>>> While I believe the documentation is good enough, the error
>>>> messages
>>>> presented by JPackage are not. Here is one example. Hopefully you
>>>> agree
>>>> that the NullPointerException does not at all tell me what is
>>>> wrong
>>>> and
>>>> what I could improve on.
>>>>
>>>> My feeling is that JPackage should do some better error handling
>>>> and
>>>> come up with improved messages.
>>>>
>>>> Hiran
>>>>
>>>>
>>>> $ jpackage --app-image build/app-image --verbose --dest build
>>>> [10:34:45.915] Warning: app-image dir not generated by jpackage.
>>>> [10:34:45.930] Running dpkg
>>>> [10:34:45.937] Command:
>>>>       dpkg --print-architecture
>>>> [10:34:45.937] Output:
>>>>       amd64
>>>> [10:34:45.939] Returned: 0
>>>>
>>>> [10:34:45.944] Running dpkg
>>>> [10:34:45.961] Command:
>>>>       dpkg -s coreutils
>>>> [10:34:45.962] Output:
>>>>       Package: coreutils
>>>>       Essential: yes
>>>>       Status: install ok installed
>>>>       Priority: required
>>>>       Section: utils
>>>>       Installed-Size: 7196
>>>>       Maintainer: Ubuntu Developers <
>>>> ubuntu-devel-discuss at lists.ubuntu.com>
>>>>       Architecture: amd64
>>>>       Multi-Arch: foreign
>>>>       Version: 8.30-3ubuntu2
>>>>       Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44),
>>>> libc6 (>=
>>>> 2.28), libselinux1 (>= 2.1.13)
>>>>       Description: GNU core utilities
>>>>        This package contains the basic file, shell and text
>>>> manipulation
>>>>        utilities which are expected to exist on every operating
>>>> system.
>>>>        .
>>>>        Specifically, this package includes:
>>>>        arch base64 basename cat chcon chgrp chmod chown chroot
>>>> cksum
>>>> comm
>>>> cp
>>>>        csplit cut date dd df dir dircolors dirname du echo env
>>>> expand
>>>> expr
>>>>        factor false flock fmt fold groups head hostid id install
>>>> join
>>>> link ln
>>>>        logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
>>>> nohup
>>>> nproc
>>>> numfmt
>>>>        od paste pathchk pinky pr printenv printf ptx pwd readlink
>>>> realpath rm
>>>>        rmdir runcon sha*sum seq shred sleep sort split stat stty
>>>> sum
>>>> sync
>>>> tac
>>>>        tail tee test timeout touch tr true truncate tsort tty
>>>> uname
>>>> unexpand
>>>>        uniq unlink users vdir wc who whoami yes
>>>>       Homepage: http://gnu.org/software/coreutils
>>>>       Original-Maintainer: Michael Stone <mstone at debian.org>
>>>> [10:34:45.962] Returned: 0
>>>>
>>>> [10:34:45.963] Running dpkg-deb
>>>> [10:34:45.965] Warning: app-image dir not generated by jpackage.
>>>> [10:34:45.967] Warning: app-image dir not generated by jpackage.
>>>> [10:34:45.967] java.lang.NullPointerException: Cannot invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
>>>> )
>>>>           at
>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>           at
>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>           at
>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
>>>> 1(
>>>> Linu
>>>> xDebBundler.java:83)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
>>>> in
>>>> uxPa
>>>> ckageBundler.java:72)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> en
>>>> ts.j
>>>> ava:663)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
>>>> um
>>>> ents
>>>> .java:538)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>> [10:34:45.969] jdk.jpackage.internal.PackagerException: Bundler
>>>> DEB
>>>> Bundle failed because of java.lang.NullPointerException: Cannot
>>>> invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> en
>>>> ts.j
>>>> ava:685)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
>>>> um
>>>> ents
>>>> .java:538)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>> Caused by: java.lang.NullPointerException: Cannot invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
>>>> )
>>>>           at
>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>           at
>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>           at
>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
>>>> 1(
>>>> Linu
>>>> xDebBundler.java:83)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
>>>> in
>>>> uxPa
>>>> ckageBundler.java:72)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> en
>>>> ts.j
>>>> ava:663)
>>>>           ... 3 more
>>>>
>>>> $
>>>>
>>>>


From psandoz at openjdk.java.net  Thu Apr  7 18:29:22 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 18:29:22 GMT
Subject: RFR: 8283892: Compress and expand bits [v4]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <ApKOKvCjSGHEVpX0tRrQd8_5XS-XLEl2R8kFu9aiBVI=.a5056526-01dd-45d6-a397-7c5a18cab311@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo.
 - Provide examples.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/da49874b..96d90e1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=02-03

  Stats: 186 lines in 2 files changed: 186 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From psandoz at openjdk.java.net  Thu Apr  7 18:29:23 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 18:29:23 GMT
Subject: RFR: 8283892: Compress and expand bits [v4]
In-Reply-To: <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
Message-ID: <KCcYrzu5quqATGDx_vkDUjltbAlo8Esj3BP4b0FdbXA=.65170fdb-020e-4725-87cd-dc4b32af5fc3@github.com>

On Wed, 6 Apr 2022 18:22:45 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix typo.
>>  - Provide examples.
>
> src/java.base/share/classes/java/lang/Integer.java line 1781:
> 
>> 1779:      * All the upper remaining bits of the compressed value are set
>> 1780:      * to zero.
>> 1781:      *
> 
> Following Alan's comment, I suggest the following examples:
> 
> 
>   compress(0x9ABCDEF, 0x0F0F0FF) == 0xACEF
>   compress(x, 1<<n) == (x>>n & 1)
>   compress(x, -1<<n) == x >>> n
>   compress(m, m) == (m==-1||m==0)? m : (1<<bitCount(m))-1
>   compress(x, m) == compress(x & m, m)
>   compress(expand(x, m), m) == x & compress(m, m)
>   (compress(x, m) >>> n) & 1 == /*the bit of x corresponding to the nth set bit in m*/
> 
> 
> ?In two places.  Similarly, examples for expand:
> 
> 
>   expand(0x9ABCDEF, 0x0F0F0FF) == 0xC0D0EF
>   expand(x, 1<<n) == (x&1) << n
>   expand(x, -1<<n) == x << n
>   expand(-1, m) == m
>   expand(x, m) == expand(x, m) & m
>   expand(compress(x, m), m) == x & m
>   expand(1<<n, m) == /*the nth set bit in m, as a mask in place; cf. highest/lowestOneBit*/
> 
> 
> (Please double check these examples!)

Examples added in latest commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From smarks at openjdk.java.net  Thu Apr  7 18:49:43 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 7 Apr 2022 18:49:43 GMT
Subject: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed
 hierarchy
In-Reply-To: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
References: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
Message-ID: <RCxZayj582-NZ-FXEhsl-ikCZcokU9hJv1qOm-AUS34=.52b4c7b4-b6d2-4c63-b08a-a21ce0dd2c29@github.com>

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which now marks `CollectionView` as a `sealed` class with only `EntrySetView`, `KeySetView` and  `ValuesView` as the sub-classes? This change corresponds to https://bugs.openjdk.java.net/browse/JDK-8284036.
> 
> A CSR has also been drafted for this change https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, marking this class as `sealed` and marking `KeySetView` as `final` shouldn't have any impact in general and also in context of serialization/de-serialization.
> 
> tier1, tier2, tier3 tests have been run successfully with this change.

LGTM

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8085

From ralph.goers at dslextreme.com  Thu Apr  7 19:01:44 2022
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Thu, 7 Apr 2022 12:01:44 -0700
Subject: fast way to infer caller
In-Reply-To: <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
 <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <17A8FC7A-D067-4282-AB8F-8EC5D1D2EBE8@dslextreme.com>

I mentioned this same concern back in 2017 when the Sun Reflection 
class was removed. 

In Log4j?s case there are two places that accessing the stack comes into play:
1. Obtaining a Logger .
2. Logging an event and including the caller?s location information.

To be honest, what sucks for Logging frameworks is that we really want 
access to the location information at compile time such that the overhead 
to include it would be zero. I?ve never understood why Java doesn?t include it. 
I wrote a Logging Framework for C back in the 1980?s that could include the 
Information so this isn?t a new concept.

Even if I could do 

logger.debug(System.location(), ?.)

Where System.location is replaced by the compiler with a constant object would be a huge win.

Ralph



> On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated).
> 
> for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops.
> 
> But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well.
> 
> --
> https://bernd.eckenfels.net
> ________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Michael Kuhlmann <jdk at fiolino.de>
> Sent: Thursday, April 7, 2022 7:55:16 PM
> To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
> Subject: Re: fast way to infer caller
> 
> 
> 
> On 4/7/22 19:27, Kasper Nielsen wrote:
>>> 
>>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>>> inline the call to MethodHandles.lookup()
>>> 
>> 
>> Does how the VM cheats really matter? The fact is that the code in the JDK
>> can
>> get the calling class and implement something like MethodHandles.lookup() so
>> it takes ~3 ns. If you implemented something like a lookup class as a normal
>> user your best bet would be StackWalker.GetCallingClass() and you would end
>> up with something that is at least 2 magnitudes slower. That is probably not
>> an issue for most use cases. But for some, it might be a bit of a steep
>> cost.
>> 
>> /Kasper
> 
> Hi Kasper,
> 
> sorry to jump in here as an uninvolved onlooker, but I can't resist.
> I really don't see why this should matter. Getting the caller class is a
> rare edge case that you just do in exceptional situations; most often
> it's more for debugging or something.
> 
> What users really are interested in is high performance for standard
> cases. Implementing a specific optimization into Hotspot to gain few
> milliseconds is the least thing I expect from the JVM developers.
> 
> I also don't understand why someone should instantiate a logger during
> performance critical procedures. In more than 20 years of Java
> development, I've never seen the need to create a logger on the fly.
> They are *always* assigned to final static variables, or at least to
> predefined pools. Everything else would be just wrong: To instantiate a
> logger, you have to fetch at least the log level definition from some
> configuration source, and this can never be fast. At least not that
> we're talking about nanoseconds here.
> 
> All logging implementations I know of (and all that make sense) are
> highly optimized on log throughput; this can only be achieved by
> preprocessing during initialization, why this is slow. But that doesn't
> matter, because, as said, you should anyway create logger instances
> beforehand.
> 
> Sorry for the rant, but I really don't see the use case here.


From hiran.chaudhuri at gmx.net  Thu Apr  7 19:38:07 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Thu, 07 Apr 2022 21:38:07 +0200
Subject: jpackage usage problems
In-Reply-To: <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
Message-ID: <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>

Hello Alex,

thank you for coming back. We now have four different cases just for
the second build step (appimage->deb). Let me first give you an
overview:


My Desktop (OpenJDK 16): My Command, Your command
Github     (OpenJDK 17): My command, Your command

On Github I started using OpenJDK11, then switched to 16 and finally to
17. In respect to my build they all seem to behave the same. So I will
give the status on all four of the combinations. And btw I use Gradle
to trigger command lines which impacts a bit the log output but
otherwise should not matter.

--My Desktop, my command:--

Starting process 'command 'jpackage''. Working directory:
/home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage
--app-image build/app-image/SettlersRemake --dest build/distributions
--resource-dir build/resources/jpackage
Successfully started process 'command 'jpackage''
:app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main])
completed. Took 12.313 secs.

This one runs reliably. I was a bit annoyed that the appdir directory
is one level more than for build step 1 (input->appimage) - but maybe
that is exactly because I did not specify --name.
After all I have a Debian package that I can verify and install.


--My Desktop, your command--

Starting process 'command 'jpackage''. Working directory:
/home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage
--app-image build/app-image/SettlersRemake --dest build/distributions
--resource-dir build/resources/jpackage
Successfully started process 'command 'jpackage''
:app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main])
completed. Took 12.313 secs.

I added --name as you suggested. It seems I still need to specify the
application name on the app-image parameter otherwise the build will
fail. A bit strange since build step 1 was run with --dest build/app-
image.
I have not yet tested the Debian package yet.


--Github, my command--

In build step 1 I am running jpackage like so:

Starting process 'command 'jpackage''. Working directory:
/home/runner/work/settlers-installer/settlers-installer/app Command:
jpackage --type app-image --dest build/app-image -i
build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-
SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake
--app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see
https://github.com/ --vendor Hiran --icon
build/resources/main/siedler3-helme-logo.png --resource-dir
build/resources/jpackage
Successfully started process 'command 'jpackage''
:app:jpackagePhase1 (Thread[Daemon worker,5,main]) completed. Took
12.919 secs.

There is no error or any suspect message in stdout- Yet I investigated
and found out that the app-image directory is almost empty. This is a
problem for the second build step. And it is annoying that Gradle
garbles the output with other stuff so I hope to have it separated
correctly.

:app:jpackagePhase2 (Thread[Daemon worker,5,main]) started.

Bundler DEB Bundle failed because of java.lang.NullPointerException:
Cannot invoke "java.lang.CharSequence.length()" because "this.text" is
null

> Task :app:jpackagePhase2 FAILED
* What went wrong:
Execution failed for task ':app:jpackagePhase2'.
> Process 'command 'jpackage'' finished with non-zero exit value 1

Since gradle is not logging the command it invoked I will give you that
line from the build file:

commandLine 'jpackage', '--app-image', 'build/app-
image/SettlersRemake', '--dest', 'build', '--resource-dir',
'build/resources/jpackage'


--Github, your command--

Since you suggested to add --name on the second step, the first step
runs as it was before. And again most files are missing in the output.

Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://github.com/ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage
Successfully started process 'command 'jpackage''
:app:jpackagePhase1 (Thread[Execution worker for ':',5,main]) completed. Took 12.672 secs.

To verify what files had been created I ran a 'find' afterwards. I had
expected the full application, and the JDK runtime. But I only see
these files for the appimage:

build/app-image
build/app-image/SettlersRemake
build/app-image/SettlersRemake/lib
build/app-image/SettlersRemake/bin
build/app-image/SettlersRemake/bin/SettlersRemake

With that, the second step is called and outputs this much:

Starting process 'command 'jpackage''. Working directory:
/home/runner/work/settlers-installer/settlers-installer/app Command:
jpackage --app-image build/app-image/SettlersRemake --name
SettlersRemake --dest build --resource-dir build/resources/jpackage
Successfully started process 'command 'jpackage''
Warning: app-image dir not generated by jpackage.
:app:jpackagePhase2 (Thread[Daemon worker,5,main]) completed. Took
8.099 secs.


I am surprised to see success, so my next step would be to evaluate the
content of the .deb file. I doubt jpackage would have created all what
was missing just now. However this evaluation will have to wait for a
week.


Hiran



On Thu, 2022-04-07 at 14:16 -0400, Alexey Semenyuk wrote:
> Hi Hiran,
>
> My apologies for not replying to your previous email. In that
> particular
> case the problem seems to be in missing "--name" cli option on the
> second jpackage command line ($JAVA_HOME/bin/jpackage --app-image
> build/app-image --verbose --dest build) that is supposed to build
> .deb
> package from the app image.
> Could you please confirm this is the case so I can file more
> specific
> description in a CR tracking this issue.
>
> Do you have a stack trace for the second NPE? It would help to
> understand what went wrong.
>
> Issue with the Github Runner looks similar to this one [1]
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-March/086656.html
>
> - Alexey
>
> On 4/7/2022 2:57 AM, Hiran Chaudhuri wrote:
> > Hi there.
> >
> > I have another case where running jpackage emits
> >
> > Bundler DEB Bundle failed because of
> > java.lang.NullPointerException:
> > Cannot invoke "java.lang.CharSequence.length()" because "this.text"
> > is
> > null
> >
> > I have never experienced NullPointerExceptions in other JDK tools.
> > Seems to me JPackage is a new kid on the block. In this case,
> > JPackage
> > is invoked to finish from an existing appimage to the final
> > package.
> > the failure is caused because some important files are missing in
> > appimage.
> >
> > The previous run is even more puzzling for me. It is supposed to
> > create
> > the appimage directory. And while it emits no error message, on my
> > development machine it runs reliably while on the Github Runner it
> > just
> > does not create all files - no error message, no exit code -
> > nothing.
> >
> > Any idea what I could be looking at?
> >
> > Hiran
> >
> >
> >
> > On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote:
> > > Hello Alex,
> > >
> > > I tried running the same command with the jdk19 you pointed at.
> > > As a
> > > first, I get this output:
> > >
> > > $JAVA_HOME/bin/jpackage --version
> > > 19-ea
> > >
> > > With that, I invoked the command as before, and i fairly got the
> > > same
> > > output. So the behaviour in the latest version has not changed.
> > >
> > > Two things I'd like to point out:
> > > - there is no JPackage version in the output itself so both you
> > > and
> > > me
> > > have to trust the correct one was called
> > > - I found out the mistake: I should have used
> > >    --app-image build/app-image/SettlersRemake
> > >    but JPackage gave a warning in the beginning and processed all
> > > the
> > >    rest
> > >
> > > Hiran
> > >
> > >
> > > $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --
> > > dest
> > > build
> > > [08:41:58.675] Warning: app-image dir not generated by jpackage.
> > > [08:41:58.688] Running dpkg
> > > [08:41:58.696] Command [PID: 21712]:
> > >      dpkg --print-architecture
> > > [08:41:58.696] Output:
> > >      amd64
> > > [08:41:58.698] Returned: 0
> > >
> > > [08:41:58.702] Running dpkg
> > > [08:41:58.719] Command [PID: 21714]:
> > >      dpkg -s coreutils
> > > [08:41:58.719] Output:
> > >      Package: coreutils
> > >      Essential: yes
> > >      Status: install ok installed
> > >      Priority: required
> > >      Section: utils
> > >      Installed-Size: 7196
> > >      Maintainer: Ubuntu Developers <
> > > ubuntu-devel-discuss at lists.ubuntu.com>
> > >      Architecture: amd64
> > >      Multi-Arch: foreign
> > >      Version: 8.30-3ubuntu2
> > >      Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44),
> > > libc6
> > > (>=
> > > 2.28), libselinux1 (>= 2.1.13)
> > >      Description: GNU core utilities
> > >       This package contains the basic file, shell and text
> > > manipulation
> > >       utilities which are expected to exist on every operating
> > > system.
> > >       .
> > >       Specifically, this package includes:
> > >       arch base64 basename cat chcon chgrp chmod chown chroot
> > > cksum
> > > comm
> > > cp
> > >       csplit cut date dd df dir dircolors dirname du echo env
> > > expand
> > > expr
> > >       factor false flock fmt fold groups head hostid id install
> > > join
> > > link ln
> > >       logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
> > > nohup
> > > nproc
> > > numfmt
> > >       od paste pathchk pinky pr printenv printf ptx pwd readlink
> > > realpath rm
> > >       rmdir runcon sha*sum seq shred sleep sort split stat stty
> > > sum
> > > sync
> > > tac
> > >       tail tee test timeout touch tr true truncate tsort tty
> > > uname
> > > unexpand
> > >       uniq unlink users vdir wc who whoami yes
> > >      Homepage: http://gnu.org/software/coreutils
> > >      Original-Maintainer: Michael Stone <mstone at debian.org>
> > > [08:41:58.719] Returned: 0
> > >
> > > [08:41:58.720] Running dpkg-deb
> > > [08:41:58.722] Warning: app-image dir not generated by jpackage.
> > > [08:41:58.723] Warning: app-image dir not generated by jpackage.
> > > [08:41:58.723] java.lang.NullPointerException: Cannot invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
> > > )
> > >          at
> > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > >          at
> > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > >          at
> > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
> > > 1(Li
> > > nu
> > > xDebBundler.java:84)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
> > > inux
> > > Pa
> > > ckageBundler.java:72)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > ents
> > > .j
> > > ava:688)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
> > > umen
> > > ts
> > > .java:561)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler
> > > DEB
> > > Bundle failed because of java.lang.NullPointerException: Cannot
> > > invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > ents
> > > .j
> > > ava:710)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
> > > umen
> > > ts
> > > .java:561)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
> > >          at
> > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > Caused by: java.lang.NullPointerException: Cannot invoke
> > > "java.lang.CharSequence.length()" because "this.text" is null
> > >          at
> > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
> > > )
> > >          at
> > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > >          at
> > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > >          at
> > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
> > > 1(Li
> > > nu
> > > xDebBundler.java:84)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
> > > inux
> > > Pa
> > > ckageBundler.java:72)
> > >          at
> > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
> > > ents
> > > .j
> > > ava:688)
> > >          ... 3 more
> > >
> > >
> > > On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote:
> > > > Hi Hiran,
> > > >
> > > > Looks like jpackage fails because of missing package name on
> > > > the
> > > > command
> > > > line.
> > > > I agree that the error message is not helpful. Can you try one
> > > > of
> > > > jdk19
> > > > EA builds [1] to see if the problem is reproducible?
> > > >
> > > > [1] https://jdk.java.net/19/
> > > >
> > > > - Alexey
> > > >
> > > > On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
> > > > > Hello there.
> > > > >
> > > > > While I am trying to package my project using jpackage 16.0.1
> > > > > on
> > > > > Ubuntu
> > > > > 20 LTS I have difficulty in assembling the correct commands.
> > > > >
> > > > > The documentation covers a lot but not everything. For
> > > > > example,
> > > > > it
> > > > > is
> > > > > not clear to me when I have to provide an option - especially
> > > > > since
> > > > > I
> > > > > meanwhile take a two step approach of building the appimage,
> > > > > then
> > > > > tweaking something (that could have done by JPackage
> > > > > directly)
> > > > > and
> > > > > finally building the DEB package.
> > > > >
> > > > > While I believe the documentation is good enough, the error
> > > > > messages
> > > > > presented by JPackage are not. Here is one example. Hopefully
> > > > > you
> > > > > agree
> > > > > that the NullPointerException does not at all tell me what is
> > > > > wrong
> > > > > and
> > > > > what I could improve on.
> > > > >
> > > > > My feeling is that JPackage should do some better error
> > > > > handling
> > > > > and
> > > > > come up with improved messages.
> > > > >
> > > > > Hiran
> > > > >
> > > > >
> > > > > $ jpackage --app-image build/app-image --verbose --dest build
> > > > > [10:34:45.915] Warning: app-image dir not generated by
> > > > > jpackage.
> > > > > [10:34:45.930] Running dpkg
> > > > > [10:34:45.937] Command:
> > > > >       dpkg --print-architecture
> > > > > [10:34:45.937] Output:
> > > > >       amd64
> > > > > [10:34:45.939] Returned: 0
> > > > >
> > > > > [10:34:45.944] Running dpkg
> > > > > [10:34:45.961] Command:
> > > > >       dpkg -s coreutils
> > > > > [10:34:45.962] Output:
> > > > >       Package: coreutils
> > > > >       Essential: yes
> > > > >       Status: install ok installed
> > > > >       Priority: required
> > > > >       Section: utils
> > > > >       Installed-Size: 7196
> > > > >       Maintainer: Ubuntu Developers <
> > > > > ubuntu-devel-discuss at lists.ubuntu.com>
> > > > >       Architecture: amd64
> > > > >       Multi-Arch: foreign
> > > > >       Version: 8.30-3ubuntu2
> > > > >       Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>=
> > > > > 1:2.4.44),
> > > > > libc6 (>=
> > > > > 2.28), libselinux1 (>= 2.1.13)
> > > > >       Description: GNU core utilities
> > > > >        This package contains the basic file, shell and text
> > > > > manipulation
> > > > >        utilities which are expected to exist on every
> > > > > operating
> > > > > system.
> > > > >        .
> > > > >        Specifically, this package includes:
> > > > >        arch base64 basename cat chcon chgrp chmod chown
> > > > > chroot
> > > > > cksum
> > > > > comm
> > > > > cp
> > > > >        csplit cut date dd df dir dircolors dirname du echo
> > > > > env
> > > > > expand
> > > > > expr
> > > > >        factor false flock fmt fold groups head hostid id
> > > > > install
> > > > > join
> > > > > link ln
> > > > >        logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
> > > > > nohup
> > > > > nproc
> > > > > numfmt
> > > > >        od paste pathchk pinky pr printenv printf ptx pwd
> > > > > readlink
> > > > > realpath rm
> > > > >        rmdir runcon sha*sum seq shred sleep sort split stat
> > > > > stty
> > > > > sum
> > > > > sync
> > > > > tac
> > > > >        tail tee test timeout touch tr true truncate tsort tty
> > > > > uname
> > > > > unexpand
> > > > >        uniq unlink users vdir wc who whoami yes
> > > > >       Homepage: http://gnu.org/software/coreutils
> > > > >       Original-Maintainer: Michael Stone <mstone at debian.org>
> > > > > [10:34:45.962] Returned: 0
> > > > >
> > > > > [10:34:45.963] Running dpkg-deb
> > > > > [10:34:45.965] Warning: app-image dir not generated by
> > > > > jpackage.
> > > > > [10:34:45.967] Warning: app-image dir not generated by
> > > > > jpackage.
> > > > > [10:34:45.967] java.lang.NullPointerException: Cannot invoke
> > > > > "java.lang.CharSequence.length()" because "this.text" is null
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:
> > > > > 1769
> > > > > )
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > > > >           at
> > > > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$sta
> > > > > tic$
> > > > > 1(
> > > > > Linu
> > > > > xDebBundler.java:83)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.valida
> > > > > te(L
> > > > > in
> > > > > uxPa
> > > > > ckageBundler.java:72)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
> > > > > rgum
> > > > > en
> > > > > ts.j
> > > > > ava:663)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments
> > > > > (Arg
> > > > > um
> > > > > ents
> > > > > .java:538)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > > > [10:34:45.969] jdk.jpackage.internal.PackagerException:
> > > > > Bundler
> > > > > DEB
> > > > > Bundle failed because of java.lang.NullPointerException:
> > > > > Cannot
> > > > > invoke
> > > > > "java.lang.CharSequence.length()" because "this.text" is null
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
> > > > > rgum
> > > > > en
> > > > > ts.j
> > > > > ava:685)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments
> > > > > (Arg
> > > > > um
> > > > > ents
> > > > > .java:538)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
> > > > > Caused by: java.lang.NullPointerException: Cannot invoke
> > > > > "java.lang.CharSequence.length()" because "this.text" is null
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:
> > > > > 1769
> > > > > )
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.reset(Matcher.java:415)
> > > > >           at
> > > > > java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
> > > > >           at
> > > > > java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$sta
> > > > > tic$
> > > > > 1(
> > > > > Linu
> > > > > xDebBundler.java:83)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.valida
> > > > > te(L
> > > > > in
> > > > > uxPa
> > > > > ckageBundler.java:72)
> > > > >           at
> > > > > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
> > > > > rgum
> > > > > en
> > > > > ts.j
> > > > > ava:663)
> > > > >           ... 3 more
> > > > >
> > > > > $
> > > > >
> > > > >


From alanb at openjdk.java.net  Thu Apr  7 20:06:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 7 Apr 2022 20:06:42 GMT
Subject: RFR: 8283892: Compress and expand bits [v4]
In-Reply-To: <KCcYrzu5quqATGDx_vkDUjltbAlo8Esj3BP4b0FdbXA=.65170fdb-020e-4725-87cd-dc4b32af5fc3@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
 <KCcYrzu5quqATGDx_vkDUjltbAlo8Esj3BP4b0FdbXA=.65170fdb-020e-4725-87cd-dc4b32af5fc3@github.com>
Message-ID: <Os5RXgqffc1mrb79sm_urHJraoZfpvPwqcQ1GyUyZaw=.b8fa6764-504f-49f1-895e-2945ba9336fe@github.com>

On Thu, 7 Apr 2022 18:23:50 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Integer.java line 1781:
>> 
>>> 1779:      * All the upper remaining bits of the compressed value are set
>>> 1780:      * to zero.
>>> 1781:      *
>> 
>> Following Alan's comment, I suggest the following examples:
>> 
>> 
>>   compress(0x9ABCDEF, 0x0F0F0FF) == 0xACEF
>>   compress(x, 1<<n) == (x>>n & 1)
>>   compress(x, -1<<n) == x >>> n
>>   compress(m, m) == (m==-1||m==0)? m : (1<<bitCount(m))-1
>>   compress(x, m) == compress(x & m, m)
>>   compress(expand(x, m), m) == x & compress(m, m)
>>   (compress(x, m) >>> n) & 1 == /*the bit of x corresponding to the nth set bit in m*/
>> 
>> 
>> ?In two places.  Similarly, examples for expand:
>> 
>> 
>>   expand(0x9ABCDEF, 0x0F0F0FF) == 0xC0D0EF
>>   expand(x, 1<<n) == (x&1) << n
>>   expand(x, -1<<n) == x << n
>>   expand(-1, m) == m
>>   expand(x, m) == expand(x, m) & m
>>   expand(compress(x, m), m) == x & m
>>   expand(1<<n, m) == /*the nth set bit in m, as a mask in place; cf. highest/lowestOneBit*/
>> 
>> 
>> (Please double check these examples!)
>
> Examples added in latest commit.

I see you've added a comment on each example too, I think this really helpers readers to see how they can be used.

The class description of both Integer and Long have an implementation note (they pre-date @implNote) referencing Hacker's Delight. We could potentially expand the list of methods mentioned but it's not strictly necessary are they are just examples.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From jason_mehrens at hotmail.com  Thu Apr  7 20:08:20 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 7 Apr 2022 20:08:20 +0000
Subject: fast way to infer caller
In-Reply-To: <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
 <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <SJ0PR18MB40095F7875C141ABD4C3DA5C83E69@SJ0PR18MB4009.namprd18.prod.outlook.com>

Perhaps https://bugs.openjdk.java.net/browse/JDK-4515935 for the MemoryHandler could be used to determine if StackWalker is fast enough for the lowest rung on the StackWalker performance ladder.   Currently the MemoryHandler doesn't not infer the caller and the target handler sees the callsite of the thread that triggers the push.  Most use cases of MemoryHandler are records that are loggable but, get discarded and never published to the target handler (never formatted nor sent to some data sink).  So this is a real world use case of only openjdk classes.
 
The Peabody fix I proposed in 2007 was to unconditionally force the caller to be computed prior to adding the LogRecord to the internal data structure.  Therefore all loggable records would pay the cost of inferring the caller.  Current code is fast and broken (assuming target formatter is showing callsite) and the correct code will be slower.  If I were to redo that patch from Peabody I would think that PR review would bring to light a consistent view that StackWalker is fast enough at least the openjdk logging.  Effectively defining the minimum performance standard.  However, if it raises performance regression concerns perhaps there is some more work to be done improving StackWalker? :)

Jason


________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Bernd Eckenfels <ecki at zusammenkunft.net>
Sent: Thursday, April 7, 2022 1:02 PM
To: core-libs-dev at openjdk.java.net
Subject: Re: fast way to infer caller

Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated).

 for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops.

But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well.

--
https://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Michael Kuhlmann <jdk at fiolino.de>
Sent: Thursday, April 7, 2022 7:55:16 PM
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: Re: fast way to infer caller



On 4/7/22 19:27, Kasper Nielsen wrote:
>>
>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>> inline the call to MethodHandles.lookup()
>>
>
> Does how the VM cheats really matter? The fact is that the code in the JDK
> can
> get the calling class and implement something like MethodHandles.lookup() so
> it takes ~3 ns. If you implemented something like a lookup class as a normal
> user your best bet would be StackWalker.GetCallingClass() and you would end
> up with something that is at least 2 magnitudes slower. That is probably not
> an issue for most use cases. But for some, it might be a bit of a steep
> cost.
>
> /Kasper

Hi Kasper,

sorry to jump in here as an uninvolved onlooker, but I can't resist.
I really don't see why this should matter. Getting the caller class is a
rare edge case that you just do in exceptional situations; most often
it's more for debugging or something.

What users really are interested in is high performance for standard
cases. Implementing a specific optimization into Hotspot to gain few
milliseconds is the least thing I expect from the JVM developers.

I also don't understand why someone should instantiate a logger during
performance critical procedures. In more than 20 years of Java
development, I've never seen the need to create a logger on the fly.
They are *always* assigned to final static variables, or at least to
predefined pools. Everything else would be just wrong: To instantiate a
logger, you have to fetch at least the log level definition from some
configuration source, and this can never be fast. At least not that
we're talking about nanoseconds here.

All logging implementations I know of (and all that make sense) are
highly optimized on log throughput; this can only be achieved by
preprocessing during initialization, why this is slow. But that doesn't
matter, because, as said, you should anyway create logger instances
beforehand.

Sorry for the rant, but I really don't see the use case here.

From duke at openjdk.java.net  Thu Apr  7 21:08:34 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 7 Apr 2022 21:08:34 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v3]
In-Reply-To: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
Message-ID: <jLHgNoNagUpcCG3HjnYvw2gHk6t8hV_M6tNRxK5SyAA=.cbc5923b-06f6-44ab-bd24-888fe7419620@github.com>

> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
> 
> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
> 
> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  revert Module::isOpen

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/4b344e4d..912896d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=01-02

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134

From ceki at qos.ch  Thu Apr  7 21:25:39 2022
From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=)
Date: Thu, 7 Apr 2022 23:25:39 +0200
Subject: fast way to infer caller
In-Reply-To: <17A8FC7A-D067-4282-AB8F-8EC5D1D2EBE8@dslextreme.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
 <AM9P193MB1142FA4B2F3135F61CE75D7EFFE69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <17A8FC7A-D067-4282-AB8F-8EC5D1D2EBE8@dslextreme.com>
Message-ID: <21324e45-cbc8-a47a-7b38-25e33347f21b@qos.ch>


C and C++ are harder to read as a side effect of pre-processor macros.
IMHO, Java's lack of pre-processor macros simplifies the language and
improves readability.

On 4/7/2022 9:01 PM, Ralph Goers wrote:
> I mentioned this same concern back in 2017 when the Sun Reflection 
> class was removed. 
> 
> In Log4j?s case there are two places that accessing the stack comes into play:
> 1. Obtaining a Logger .
> 2. Logging an event and including the caller?s location information.
> 
> To be honest, what sucks for Logging frameworks is that we really want 
> access to the location information at compile time such that the overhead 
> to include it would be zero. I?ve never understood why Java doesn?t include it. 
> I wrote a Logging Framework for C back in the 1980?s that could include the 
> Information so this isn?t a new concept.
> 
> Even if I could do 
> 
> logger.debug(System.location(), ?.)
> 
> Where System.location is replaced by the compiler with a constant object would be a huge win.
> 
> Ralph
> 
> 
> 
>> On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>>
>> Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated).
>>
>> for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops.
>>
>> But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well.
>>
>> --
>> https://bernd.eckenfels.net
>> ________________________________
>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Michael Kuhlmann <jdk at fiolino.de>
>> Sent: Thursday, April 7, 2022 7:55:16 PM
>> To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
>> Subject: Re: fast way to infer caller
>>
>>
>>
>> On 4/7/22 19:27, Kasper Nielsen wrote:
>>>>
>>>> nope, see my previous mail to Ceki, the VM is cheating here if it can
>>>> inline the call to MethodHandles.lookup()
>>>>
>>>
>>> Does how the VM cheats really matter? The fact is that the code in the JDK
>>> can
>>> get the calling class and implement something like MethodHandles.lookup() so
>>> it takes ~3 ns. If you implemented something like a lookup class as a normal
>>> user your best bet would be StackWalker.GetCallingClass() and you would end
>>> up with something that is at least 2 magnitudes slower. That is probably not
>>> an issue for most use cases. But for some, it might be a bit of a steep
>>> cost.
>>>
>>> /Kasper
>>
>> Hi Kasper,
>>
>> sorry to jump in here as an uninvolved onlooker, but I can't resist.
>> I really don't see why this should matter. Getting the caller class is a
>> rare edge case that you just do in exceptional situations; most often
>> it's more for debugging or something.
>>
>> What users really are interested in is high performance for standard
>> cases. Implementing a specific optimization into Hotspot to gain few
>> milliseconds is the least thing I expect from the JVM developers.
>>
>> I also don't understand why someone should instantiate a logger during
>> performance critical procedures. In more than 20 years of Java
>> development, I've never seen the need to create a logger on the fly.
>> They are *always* assigned to final static variables, or at least to
>> predefined pools. Everything else would be just wrong: To instantiate a
>> logger, you have to fetch at least the log level definition from some
>> configuration source, and this can never be fast. At least not that
>> we're talking about nanoseconds here.
>>
>> All logging implementations I know of (and all that make sense) are
>> highly optimized on log throughput; this can only be achieved by
>> preprocessing during initialization, why this is slow. But that doesn't
>> matter, because, as said, you should anyway create logger instances
>> beforehand.
>>
>> Sorry for the rant, but I really don't see the use case here.
> 

-- 
Ceki G?lc?

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

From naoto at openjdk.java.net  Thu Apr  7 21:27:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Apr 2022 21:27:37 GMT
Subject: RFR: 8265315: Support for CLDR version 41
Message-ID: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>

This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

-------------

Commit messages:
 - Merge branch 'master' into cldr+
 - CLDR v41 final
 - CLDR v41 beta2
 - Merge branch 'master' into cldr+
 - CLDR v41 alpha4
 - Merge branch 'master' into cldr+
 - Update copyright year to 2022
 - CLDR release v40
 - Merge branch 'master' into cldr
 - CLDR tip
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/526e7349...ee6985a4

Changes: https://git.openjdk.java.net/jdk/pull/8150/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8150&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265315
  Stats: 132401 lines in 859 files changed: 96406 ins; 4216 del; 31779 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8150.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8150/head:pull/8150

PR: https://git.openjdk.java.net/jdk/pull/8150

From kasperni at gmail.com  Thu Apr  7 21:59:07 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Thu, 7 Apr 2022 22:59:07 +0100
Subject: fast way to infer caller
In-Reply-To: <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
Message-ID: <CAPs61529Bgu7YX7CSO-UrtnsDxcg7fZudZAgQV7Kq0yO2a_Ewg@mail.gmail.com>

>
> Hi Kasper,
>
> sorry to jump in here as an uninvolved onlooker, but I can't resist.
> I really don't see why this should matter. Getting the caller class is a
> rare edge case that you just do in exceptional situations; most often
> it's more for debugging or something.
>
> What users really are interested in is high performance for standard
> cases. Implementing a specific optimization into Hotspot to gain few
> milliseconds is the least thing I expect from the JVM developers.
>
> I also don't understand why someone should instantiate a logger during
> performance critical procedures. In more than 20 years of Java
> development, I've never seen the need to create a logger on the fly.
> They are *always* assigned to final static variables, or at least to
> predefined pools. Everything else would be just wrong: To instantiate a
> logger, you have to fetch at least the log level definition from some
> configuration source, and this can never be fast. At least not that
> we're talking about nanoseconds here.
>
> All logging implementations I know of (and all that make sense) are
> highly optimized on log throughput; this can only be achieved by
> preprocessing during initialization, why this is slow. But that doesn't
> matter, because, as said, you should anyway create logger instances
> beforehand.
>
> Sorry for the rant, but I really don't see the use case here.
>

Hi Michael,

I don't really have an opinion on how you obtain a logger. But one
particular
use-case I've had was that I would like to perform some access checks based
on the module of the caller. Something similar to how Panama checks for
native access:

Reflection.ensureNativeAccess(Reflection.getCallerClass());

You can implement something similar with StackWalker but it just adds a bit
of
non-negligible overhead to every invocation of the method.

I'm pretty sure there must be other valid use cases out there
where performance
is important. After all, the StackWalker API was created because existing
solutions
such as Thread::getStackTrace weren't performant enough.

/Kasper

From darcy at openjdk.java.net  Thu Apr  7 22:17:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 7 Apr 2022 22:17:45 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
Message-ID: <VShvHuoE1dmV-OG0MKfhNdiH2e5JamHGDfkGMEJsC9M=.a3deada1-777e-48a1-9810-bd414eae352b@github.com>

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Typo fix; add implSpec to Executable.
>  - Appease jcheck.
>  - Fix some bugs found by inspection, docs cleanup.
>  - Merge branch 'master' into JDK-8266670
>  - Initial support for accessFlags methods
>  - Add mask to access flag functionality.
>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/f55e4cdc...14980605

Keep-alive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From joehw at openjdk.java.net  Thu Apr  7 22:35:43 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 7 Apr 2022 22:35:43 GMT
Subject: RFR: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <b2f9yAUB6GOh8wK40TpzOVSyYsprlLilegs7yWFl3fA=.b6730316-25a4-46fe-8103-e34f94b4e43b@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From psandoz at openjdk.java.net  Thu Apr  7 22:54:41 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 7 Apr 2022 22:54:41 GMT
Subject: RFR: 8283892: Compress and expand bits [v4]
In-Reply-To: <Os5RXgqffc1mrb79sm_urHJraoZfpvPwqcQ1GyUyZaw=.b8fa6764-504f-49f1-895e-2945ba9336fe@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <dAxxZfDMkTjHB9ijp6KPhIZWz6u-o11UI1YnOwhsLfc=.5b2db815-75aa-4201-88fa-c0626ade427a@github.com>
 <KCcYrzu5quqATGDx_vkDUjltbAlo8Esj3BP4b0FdbXA=.65170fdb-020e-4725-87cd-dc4b32af5fc3@github.com>
 <Os5RXgqffc1mrb79sm_urHJraoZfpvPwqcQ1GyUyZaw=.b8fa6764-504f-49f1-895e-2945ba9336fe@github.com>
Message-ID: <EoK-fkaEXBzPSWqXYTU1qKQEii3Uy9RMZY0FVUT5BhE=.2b202322-7002-4a77-b2a3-318d20269fe8@github.com>

On Thu, 7 Apr 2022 20:02:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Examples added in latest commit.
>
> I see you've added a comment on each example too, I think this really helpers readers to see how they can be used.
> 
> The class description of both Integer and Long have an implementation note (they pre-date @implNote) referencing Hacker's Delight. We could potentially expand the list of methods mentioned but it's not strictly necessary are they are just examples.

I also saw that on the class doc and considered the new methods fit neatly under the category of "bit twiddling" methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From iris at openjdk.java.net  Thu Apr  7 23:06:54 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 7 Apr 2022 23:06:54 GMT
Subject: RFR: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <4oGrtdxkJtlc3S_r5i21b3Hiw68LU9_fAdYTCyhf7o4=.0c48424f-143f-45a1-bff6-8a6207c50940@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From alexey.semenyuk at oracle.com  Thu Apr  7 23:53:30 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 7 Apr 2022 19:53:30 -0400
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
Message-ID: <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>

Hi Hiran,

Thank you for providing all the details!
I can see two separate issues with jpackage:
 ?1. jpackage reports NPE if it can't figure out the package name from 
the supplied application image. It should issue a helpful error message 
instead
 ?2. jpackage fails to populate application image with Java runtime and 
app specific files when executed in Github but exits with "0" status 
indicating no error

jpackage will successfully build platform-specific packages from any 
application image by design. It doesn't validate supplied application 
image to let users create platform specific packages from customized 
application images.

It is no surprise for me that after adding "--name" to jpackage command 
line it worked. This supplied jpackage a package name that it would 
normally get from non-empty application image.

The major problem in your use case is that jpackage doesn't create 
correct application image. Instead, it creates only a directory 
structure of application image, but no files and exits with a "success" 
status code. This is quite strange. Is there any chance Gradle ignores 
non-zero exit code from jpackage execution? Can you directly run 
jpackage command creating application image in the environment where it 
outputs "empty" application image and check its exit code (please add 
"--verbose" to jpackage command line to get debug output)?

- Alexey

On 4/7/2022 3:38 PM, Hiran Chaudhuri wrote:
> Hello Alex,
>
> thank you for coming back. We now have four different cases just for
> the second build step (appimage->deb). Let me first give you an
> overview:
>
>
> My Desktop (OpenJDK 16): My Command, Your command
> Github     (OpenJDK 17): My command, Your command
>
> On Github I started using OpenJDK11, then switched to 16 and finally to
> 17. In respect to my build they all seem to behave the same. So I will
> give the status on all four of the combinations. And btw I use Gradle
> to trigger command lines which impacts a bit the log output but
> otherwise should not matter.
>
> --My Desktop, my command:--
>
> Starting process 'command 'jpackage''. Working directory:
> /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage
> --app-image build/app-image/SettlersRemake --dest build/distributions
> --resource-dir build/resources/jpackage
> Successfully started process 'command 'jpackage''
> :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main])
> completed. Took 12.313 secs.
>
> This one runs reliably. I was a bit annoyed that the appdir directory
> is one level more than for build step 1 (input->appimage) - but maybe
> that is exactly because I did not specify --name.
> After all I have a Debian package that I can verify and install.
>
>
> --My Desktop, your command--
>
> Starting process 'command 'jpackage''. Working directory:
> /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage
> --app-image build/app-image/SettlersRemake --dest build/distributions
> --resource-dir build/resources/jpackage
> Successfully started process 'command 'jpackage''
> :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main])
> completed. Took 12.313 secs.
>
> I added --name as you suggested. It seems I still need to specify the
> application name on the app-image parameter otherwise the build will
> fail. A bit strange since build step 1 was run with --dest build/app-
> image.
> I have not yet tested the Debian package yet.
>
>
> --Github, my command--
>
> In build step 1 I am running jpackage like so:
>
> Starting process 'command 'jpackage''. Working directory:
> /home/runner/work/settlers-installer/settlers-installer/app Command:
> jpackage --type app-image --dest build/app-image -i
> build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-
> SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake
> --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see
> https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JKYyzRfj$  --vendor Hiran --icon
> build/resources/main/siedler3-helme-logo.png --resource-dir
> build/resources/jpackage
> Successfully started process 'command 'jpackage''
> :app:jpackagePhase1 (Thread[Daemon worker,5,main]) completed. Took
> 12.919 secs.
>
> There is no error or any suspect message in stdout- Yet I investigated
> and found out that the app-image directory is almost empty. This is a
> problem for the second build step. And it is annoying that Gradle
> garbles the output with other stuff so I hope to have it separated
> correctly.
>
> :app:jpackagePhase2 (Thread[Daemon worker,5,main]) started.
>
> Bundler DEB Bundle failed because of java.lang.NullPointerException:
> Cannot invoke "java.lang.CharSequence.length()" because "this.text" is
> null
>
>> Task :app:jpackagePhase2 FAILED
> * What went wrong:
> Execution failed for task ':app:jpackagePhase2'.
>> Process 'command 'jpackage'' finished with non-zero exit value 1
> Since gradle is not logging the command it invoked I will give you that
> line from the build file:
>
> commandLine 'jpackage', '--app-image', 'build/app-
> image/SettlersRemake', '--dest', 'build', '--resource-dir',
> 'build/resources/jpackage'
>
>
> --Github, your command--
>
> Since you suggested to add --name on the second step, the first step
> runs as it was before. And again most files are missing in the output.
>
> Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JKYyzRfj$  --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage
> Successfully started process 'command 'jpackage''
> :app:jpackagePhase1 (Thread[Execution worker for ':',5,main]) completed. Took 12.672 secs.
>
> To verify what files had been created I ran a 'find' afterwards. I had
> expected the full application, and the JDK runtime. But I only see
> these files for the appimage:
>
> build/app-image
> build/app-image/SettlersRemake
> build/app-image/SettlersRemake/lib
> build/app-image/SettlersRemake/bin
> build/app-image/SettlersRemake/bin/SettlersRemake
>
> With that, the second step is called and outputs this much:
>
> Starting process 'command 'jpackage''. Working directory:
> /home/runner/work/settlers-installer/settlers-installer/app Command:
> jpackage --app-image build/app-image/SettlersRemake --name
> SettlersRemake --dest build --resource-dir build/resources/jpackage
> Successfully started process 'command 'jpackage''
> Warning: app-image dir not generated by jpackage.
> :app:jpackagePhase2 (Thread[Daemon worker,5,main]) completed. Took
> 8.099 secs.
>
>
> I am surprised to see success, so my next step would be to evaluate the
> content of the .deb file. I doubt jpackage would have created all what
> was missing just now. However this evaluation will have to wait for a
> week.
>
>
> Hiran
>
>
>
> On Thu, 2022-04-07 at 14:16 -0400, Alexey Semenyuk wrote:
>> Hi Hiran,
>>
>> My apologies for not replying to your previous email. In that
>> particular
>> case the problem seems to be in missing "--name" cli option on the
>> second jpackage command line ($JAVA_HOME/bin/jpackage --app-image
>> build/app-image --verbose --dest build) that is supposed to build
>> .deb
>> package from the app image.
>> Could you please confirm this is the case so I can file more
>> specific
>> description in a CR tracking this issue.
>>
>> Do you have a stack trace for the second NPE? It would help to
>> understand what went wrong.
>>
>> Issue with the Github Runner looks similar to this one [1]
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-March/086656.html
>>
>> - Alexey
>>
>> On 4/7/2022 2:57 AM, Hiran Chaudhuri wrote:
>>> Hi there.
>>>
>>> I have another case where running jpackage emits
>>>
>>> Bundler DEB Bundle failed because of
>>> java.lang.NullPointerException:
>>> Cannot invoke "java.lang.CharSequence.length()" because "this.text"
>>> is
>>> null
>>>
>>> I have never experienced NullPointerExceptions in other JDK tools.
>>> Seems to me JPackage is a new kid on the block. In this case,
>>> JPackage
>>> is invoked to finish from an existing appimage to the final
>>> package.
>>> the failure is caused because some important files are missing in
>>> appimage.
>>>
>>> The previous run is even more puzzling for me. It is supposed to
>>> create
>>> the appimage directory. And while it emits no error message, on my
>>> development machine it runs reliably while on the Github Runner it
>>> just
>>> does not create all files - no error message, no exit code -
>>> nothing.
>>>
>>> Any idea what I could be looking at?
>>>
>>> Hiran
>>>
>>>
>>>
>>> On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote:
>>>> Hello Alex,
>>>>
>>>> I tried running the same command with the jdk19 you pointed at.
>>>> As a
>>>> first, I get this output:
>>>>
>>>> $JAVA_HOME/bin/jpackage --version
>>>> 19-ea
>>>>
>>>> With that, I invoked the command as before, and i fairly got the
>>>> same
>>>> output. So the behaviour in the latest version has not changed.
>>>>
>>>> Two things I'd like to point out:
>>>> - there is no JPackage version in the output itself so both you
>>>> and
>>>> me
>>>> have to trust the correct one was called
>>>> - I found out the mistake: I should have used
>>>>     --app-image build/app-image/SettlersRemake
>>>>     but JPackage gave a warning in the beginning and processed all
>>>> the
>>>>     rest
>>>>
>>>> Hiran
>>>>
>>>>
>>>> $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --
>>>> dest
>>>> build
>>>> [08:41:58.675] Warning: app-image dir not generated by jpackage.
>>>> [08:41:58.688] Running dpkg
>>>> [08:41:58.696] Command [PID: 21712]:
>>>>       dpkg --print-architecture
>>>> [08:41:58.696] Output:
>>>>       amd64
>>>> [08:41:58.698] Returned: 0
>>>>
>>>> [08:41:58.702] Running dpkg
>>>> [08:41:58.719] Command [PID: 21714]:
>>>>       dpkg -s coreutils
>>>> [08:41:58.719] Output:
>>>>       Package: coreutils
>>>>       Essential: yes
>>>>       Status: install ok installed
>>>>       Priority: required
>>>>       Section: utils
>>>>       Installed-Size: 7196
>>>>       Maintainer: Ubuntu Developers <
>>>> ubuntu-devel-discuss at lists.ubuntu.com>
>>>>       Architecture: amd64
>>>>       Multi-Arch: foreign
>>>>       Version: 8.30-3ubuntu2
>>>>       Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44),
>>>> libc6
>>>> (>=
>>>> 2.28), libselinux1 (>= 2.1.13)
>>>>       Description: GNU core utilities
>>>>        This package contains the basic file, shell and text
>>>> manipulation
>>>>        utilities which are expected to exist on every operating
>>>> system.
>>>>        .
>>>>        Specifically, this package includes:
>>>>        arch base64 basename cat chcon chgrp chmod chown chroot
>>>> cksum
>>>> comm
>>>> cp
>>>>        csplit cut date dd df dir dircolors dirname du echo env
>>>> expand
>>>> expr
>>>>        factor false flock fmt fold groups head hostid id install
>>>> join
>>>> link ln
>>>>        logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
>>>> nohup
>>>> nproc
>>>> numfmt
>>>>        od paste pathchk pinky pr printenv printf ptx pwd readlink
>>>> realpath rm
>>>>        rmdir runcon sha*sum seq shred sleep sort split stat stty
>>>> sum
>>>> sync
>>>> tac
>>>>        tail tee test timeout touch tr true truncate tsort tty
>>>> uname
>>>> unexpand
>>>>        uniq unlink users vdir wc who whoami yes
>>>>       Homepage: https://urldefense.com/v3/__http://gnu.org/software/coreutils__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JLa0gVuH$
>>>>       Original-Maintainer: Michael Stone <mstone at debian.org>
>>>> [08:41:58.719] Returned: 0
>>>>
>>>> [08:41:58.720] Running dpkg-deb
>>>> [08:41:58.722] Warning: app-image dir not generated by jpackage.
>>>> [08:41:58.723] Warning: app-image dir not generated by jpackage.
>>>> [08:41:58.723] java.lang.NullPointerException: Cannot invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
>>>> )
>>>>           at
>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>           at
>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>           at
>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
>>>> 1(Li
>>>> nu
>>>> xDebBundler.java:84)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
>>>> inux
>>>> Pa
>>>> ckageBundler.java:72)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> ents
>>>> .j
>>>> ava:688)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
>>>> umen
>>>> ts
>>>> .java:561)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>> [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler
>>>> DEB
>>>> Bundle failed because of java.lang.NullPointerException: Cannot
>>>> invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> ents
>>>> .j
>>>> ava:710)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arg
>>>> umen
>>>> ts
>>>> .java:561)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>> Caused by: java.lang.NullPointerException: Cannot invoke
>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>           at
>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769
>>>> )
>>>>           at
>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>           at
>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>           at
>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1144)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$
>>>> 1(Li
>>>> nu
>>>> xDebBundler.java:84)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(L
>>>> inux
>>>> Pa
>>>> ckageBundler.java:72)
>>>>           at
>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Argum
>>>> ents
>>>> .j
>>>> ava:688)
>>>>           ... 3 more
>>>>
>>>>
>>>> On Fri, 2022-04-01 at 12:37 -0400, Alexey Semenyuk wrote:
>>>>> Hi Hiran,
>>>>>
>>>>> Looks like jpackage fails because of missing package name on
>>>>> the
>>>>> command
>>>>> line.
>>>>> I agree that the error message is not helpful. Can you try one
>>>>> of
>>>>> jdk19
>>>>> EA builds [1] to see if the problem is reproducible?
>>>>>
>>>>> [1] https://urldefense.com/v3/__https://jdk.java.net/19/__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JNgMRY6P$
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 4/1/2022 5:58 AM, Hiran Chaudhuri wrote:
>>>>>> Hello there.
>>>>>>
>>>>>> While I am trying to package my project using jpackage 16.0.1
>>>>>> on
>>>>>> Ubuntu
>>>>>> 20 LTS I have difficulty in assembling the correct commands.
>>>>>>
>>>>>> The documentation covers a lot but not everything. For
>>>>>> example,
>>>>>> it
>>>>>> is
>>>>>> not clear to me when I have to provide an option - especially
>>>>>> since
>>>>>> I
>>>>>> meanwhile take a two step approach of building the appimage,
>>>>>> then
>>>>>> tweaking something (that could have done by JPackage
>>>>>> directly)
>>>>>> and
>>>>>> finally building the DEB package.
>>>>>>
>>>>>> While I believe the documentation is good enough, the error
>>>>>> messages
>>>>>> presented by JPackage are not. Here is one example. Hopefully
>>>>>> you
>>>>>> agree
>>>>>> that the NullPointerException does not at all tell me what is
>>>>>> wrong
>>>>>> and
>>>>>> what I could improve on.
>>>>>>
>>>>>> My feeling is that JPackage should do some better error
>>>>>> handling
>>>>>> and
>>>>>> come up with improved messages.
>>>>>>
>>>>>> Hiran
>>>>>>
>>>>>>
>>>>>> $ jpackage --app-image build/app-image --verbose --dest build
>>>>>> [10:34:45.915] Warning: app-image dir not generated by
>>>>>> jpackage.
>>>>>> [10:34:45.930] Running dpkg
>>>>>> [10:34:45.937] Command:
>>>>>>        dpkg --print-architecture
>>>>>> [10:34:45.937] Output:
>>>>>>        amd64
>>>>>> [10:34:45.939] Returned: 0
>>>>>>
>>>>>> [10:34:45.944] Running dpkg
>>>>>> [10:34:45.961] Command:
>>>>>>        dpkg -s coreutils
>>>>>> [10:34:45.962] Output:
>>>>>>        Package: coreutils
>>>>>>        Essential: yes
>>>>>>        Status: install ok installed
>>>>>>        Priority: required
>>>>>>        Section: utils
>>>>>>        Installed-Size: 7196
>>>>>>        Maintainer: Ubuntu Developers <
>>>>>> ubuntu-devel-discuss at lists.ubuntu.com>
>>>>>>        Architecture: amd64
>>>>>>        Multi-Arch: foreign
>>>>>>        Version: 8.30-3ubuntu2
>>>>>>        Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>=
>>>>>> 1:2.4.44),
>>>>>> libc6 (>=
>>>>>> 2.28), libselinux1 (>= 2.1.13)
>>>>>>        Description: GNU core utilities
>>>>>>         This package contains the basic file, shell and text
>>>>>> manipulation
>>>>>>         utilities which are expected to exist on every
>>>>>> operating
>>>>>> system.
>>>>>>         .
>>>>>>         Specifically, this package includes:
>>>>>>         arch base64 basename cat chcon chgrp chmod chown
>>>>>> chroot
>>>>>> cksum
>>>>>> comm
>>>>>> cp
>>>>>>         csplit cut date dd df dir dircolors dirname du echo
>>>>>> env
>>>>>> expand
>>>>>> expr
>>>>>>         factor false flock fmt fold groups head hostid id
>>>>>> install
>>>>>> join
>>>>>> link ln
>>>>>>         logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
>>>>>> nohup
>>>>>> nproc
>>>>>> numfmt
>>>>>>         od paste pathchk pinky pr printenv printf ptx pwd
>>>>>> readlink
>>>>>> realpath rm
>>>>>>         rmdir runcon sha*sum seq shred sleep sort split stat
>>>>>> stty
>>>>>> sum
>>>>>> sync
>>>>>> tac
>>>>>>         tail tee test timeout touch tr true truncate tsort tty
>>>>>> uname
>>>>>> unexpand
>>>>>>         uniq unlink users vdir wc who whoami yes
>>>>>>        Homepage: https://urldefense.com/v3/__http://gnu.org/software/coreutils__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JLa0gVuH$
>>>>>>        Original-Maintainer: Michael Stone <mstone at debian.org>
>>>>>> [10:34:45.962] Returned: 0
>>>>>>
>>>>>> [10:34:45.963] Running dpkg-deb
>>>>>> [10:34:45.965] Warning: app-image dir not generated by
>>>>>> jpackage.
>>>>>> [10:34:45.967] Warning: app-image dir not generated by
>>>>>> jpackage.
>>>>>> [10:34:45.967] java.lang.NullPointerException: Cannot invoke
>>>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:
>>>>>> 1769
>>>>>> )
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>>>            at
>>>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$sta
>>>>>> tic$
>>>>>> 1(
>>>>>> Linu
>>>>>> xDebBundler.java:83)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.valida
>>>>>> te(L
>>>>>> in
>>>>>> uxPa
>>>>>> ckageBundler.java:72)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
>>>>>> rgum
>>>>>> en
>>>>>> ts.j
>>>>>> ava:663)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments
>>>>>> (Arg
>>>>>> um
>>>>>> ents
>>>>>> .java:538)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>>>> [10:34:45.969] jdk.jpackage.internal.PackagerException:
>>>>>> Bundler
>>>>>> DEB
>>>>>> Bundle failed because of java.lang.NullPointerException:
>>>>>> Cannot
>>>>>> invoke
>>>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
>>>>>> rgum
>>>>>> en
>>>>>> ts.j
>>>>>> ava:685)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments
>>>>>> (Arg
>>>>>> um
>>>>>> ents
>>>>>> .java:538)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)
>>>>>> Caused by: java.lang.NullPointerException: Cannot invoke
>>>>>> "java.lang.CharSequence.length()" because "this.text" is null
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.getTextLength(Matcher.java:
>>>>>> 1769
>>>>>> )
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.reset(Matcher.java:415)
>>>>>>            at
>>>>>> java.base/java.util.regex.Matcher.<init>(Matcher.java:252)
>>>>>>            at
>>>>>> java.base/java.util.regex.Pattern.matcher(Pattern.java:1134)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$sta
>>>>>> tic$
>>>>>> 1(
>>>>>> Linu
>>>>>> xDebBundler.java:83)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.valida
>>>>>> te(L
>>>>>> in
>>>>>> uxPa
>>>>>> ckageBundler.java:72)
>>>>>>            at
>>>>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(A
>>>>>> rgum
>>>>>> en
>>>>>> ts.j
>>>>>> ava:663)
>>>>>>            ... 3 more
>>>>>>
>>>>>> $
>>>>>>
>>>>>>


From duke at openjdk.java.net  Fri Apr  8 00:59:36 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 00:59:36 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v11]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <MvVWqXbLCKstZ2uKF8jq_EbT6DGtT2sDOt-ecNgd4PI=.079db0a7-7f01-4dc8-b3b2-aa14980fe476@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Idead Ideal for udiv, umod nodes and update jtreg tests to use corner cases

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/9949047c..bfb6c02e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=09-10

  Stats: 701 lines in 7 files changed: 423 ins; 274 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 00:59:38 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 00:59:38 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
 <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
Message-ID: <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>

On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add error msg for jtreg test
>
> I have few comments.

Hi Vladimir (@vnkozlov),

Incorporated all the suggestions you made in the previous review and pushed a new commit.
Please let me know if anything else is needed.

Thanks,
Vamsi

> src/hotspot/cpu/x86/assembler_x86.cpp line 12375:
> 
>> 12373: }
>> 12374: #endif
>> 12375: 
> 
> Please, place it near `idivq()` so you would not need `#ifdef`.

Made the change as per your suggestion.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4568:
> 
>> 4566:   subl(rdx, divisor);
>> 4567:   if (VM_Version::supports_bmi1()) andnl(rax, rdx, rax);
>> 4568:   else {
> 
> Please, follow our coding stile here and in following methods:
> 
> if (VM_Version::supports_bmi1()) {
>   andnl(rax, rdx, rax);
> } else {

Pls see the new commit which fixed the coding style.

> src/hotspot/cpu/x86/x86_64.ad line 8701:
> 
>> 8699: %}
>> 8700: 
>> 8701: instruct udivI_rReg(rax_RegI rax, no_rax_rdx_RegI div, rFlagsReg cr, rdx_RegI rdx)
> 
> I suggest to follow the pattern in other `div/mod` instructions: `(rax_RegI rax, rdx_RegI rdx, no_rax_rdx_RegI div, rFlagsReg cr)`
> 
> Similar in following new instructions.

Pls see the new commit which fixed the pattern.

> test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 55:
> 
>> 53:             dividends[i] = rng.nextInt();
>> 54:             divisors[i] = rng.nextInt();
>> 55:         }
> 
> I don't trust RND to generate corner cases.
> Please, add cases here and in TestLongDivMod.java for MAX, MIN, 0.

You are right. Using an updated corner cases test revealed divide by zero crash which was fixed. Please see the updated jtreg tests inspired by unsigned divide/remainder tests in test/jdk/java/lang/Long/Unsigned.java and test/jdk/java/lang/Integer/Unsigned.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 00:59:38 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 00:59:38 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <EilN6a5RAdiHRMCwYraI3UOlaFXMc6ayUSUyLp686PU=.affe5bd9-b472-4c65-a12c-3f457f8ef3a0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
 <oCd9O4Ecr3MnFogrUlo-lMw-MUHNTfwJqdUIV2fxXNc=.e3ec0775-0264-4cea-b1a4-657be815b390@github.com>
 <fJGpa0iOx6AwnUsmoZA7pzw0B-PocgklwxSWzDqoRZQ=.b12fb49a-4b2e-4514-9b84-e093d2fbbb03@github.com>
 <EilN6a5RAdiHRMCwYraI3UOlaFXMc6ayUSUyLp686PU=.affe5bd9-b472-4c65-a12c-3f457f8ef3a0@github.com>
Message-ID: <h8xs5rnm8YeGsVE9fNeufvFOdaPvJ5RnQE9m9Lktols=.94c05842-2d9f-4d4a-a550-2d90319ff4c1@github.com>

On Wed, 6 Apr 2022 00:45:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365
>
> You do need `Ideal()` methods at least to check for dead code.

Added the Ideal() methods for checking dead code. Pls see the new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 01:05:33 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 01:05:33 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  uncomment zero in integer div, mod test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/bfb6c02e..3e3fc977

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From kvn at openjdk.java.net  Fri Apr  8 01:50:02 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 01:50:02 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
Message-ID: <f_vAWZDT8_JyIhCmlCcJUbcvYusQFWWtuv1YfpmXkH8=.a2241fd3-89ca-48de-91ac-98d757c33686@github.com>

On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncomment zero in integer div, mod test

Good. I forgot before to ask about how you handle devision by 0 and now you added check for it.

Let me run testing before approval.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 02:02:43 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 8 Apr 2022 02:02:43 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
Message-ID: <vTCHK2BpP5WUrHxFeq_bx0qGt5d6MXAUJ1Llt97kkfM=.b038dd46-164e-4122-b6e5-a4399c632d32@github.com>

On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncomment zero in integer div, mod test

Personally, I think the optimisation for `div < 0` should be handled by the mid-end optimiser, which will not only give us the advantages of dead code elimination, but also global code motion. I would suggest the backend only doing `xorl rdx, rdx; divl $div$$Register` and the optimisation for `div < 0` will be implemented as a part of JDK-8282365. What do you think?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From iklam at openjdk.java.net  Fri Apr  8 03:16:16 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 8 Apr 2022 03:16:16 GMT
Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived Reference
 object
Message-ID: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>

During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived.

The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app).

I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure.

Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces.

-------------

Commit messages:
 - 8284336: CDS SignedJar.java test fails due to archived Reference object

Changes: https://git.openjdk.java.net/jdk/pull/8151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284336
  Stats: 28 lines in 5 files changed: 25 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8151/head:pull/8151

PR: https://git.openjdk.java.net/jdk/pull/8151

From jdk at fiolino.de  Fri Apr  8 05:56:57 2022
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Fri, 8 Apr 2022 07:56:57 +0200
Subject: fast way to infer caller
In-Reply-To: <CAPs61529Bgu7YX7CSO-UrtnsDxcg7fZudZAgQV7Kq0yO2a_Ewg@mail.gmail.com>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
 <CAPs61529Bgu7YX7CSO-UrtnsDxcg7fZudZAgQV7Kq0yO2a_Ewg@mail.gmail.com>
Message-ID: <024f904f-53c1-2176-2e6c-f929d638ad1a@fiolino.de>

Good morning!

On 4/7/22 23:59, Kasper Nielsen wrote:
> Hi Michael,
> 
> I don't really have an opinion on how you obtain a logger. But one 
> particular
> use-case I've had was that I would like to perform some access checks based
> on the module of the caller. Something similar to how Panama checks for
> native access:
> 
> Reflection.ensureNativeAccess(Reflection.getCallerClass());

Hmh, but wouldn't it be sufficient to perform these checks at 
initialization time?

On 4/7/22 21:01, Ralph Goers wrote:
 > In Log4j?s case there are two places that accessing the stack comes 
into play:
 > 1. Obtaining a Logger .
 > 2. Logging an event and including the caller?s location information.
 >
 > To be honest, what sucks for Logging frameworks is that we really want
 > access to the location information at compile time such that the overhead
 > to include it would be zero. I?ve never understood why Java doesn?t 
include it.

That I totally agree! Having the exact line number in the log statement 
would be a huge win.

But to be honest, Reflection::getCallerClass wouldn't help either.

I agree that such an inlined statement would be a huge win.

But to also put this into relation: From my opinion, logging frameworks 
should be most performant in the cases where they are *not* logging. Or 
in those cases where you would log a lot even in production environment 
- like for financial calculations - the exact line number isn't that 
relevant any more.

But that's just my opinion.

-Michael

From aturbanov at openjdk.java.net  Fri Apr  8 06:17:12 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Apr 2022 06:17:12 GMT
Subject: RFR: 8284567: Collapse identical catch branches in java.base
Message-ID: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>

Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
It simplifies code. Reduces duplication.
Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into collapse_identical_catch_java.base
 - [PATCH] Collapse identical catch branches in java.base
 - [PATCH] Collapse identical catch branches in java.base

Changes: https://git.openjdk.java.net/jdk/pull/8081/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8081&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284567
  Stats: 106 lines in 17 files changed: 0 ins; 60 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8081.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8081/head:pull/8081

PR: https://git.openjdk.java.net/jdk/pull/8081

From turbanoff at gmail.com  Fri Apr  8 06:27:45 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Fri, 8 Apr 2022 09:27:45 +0300
Subject: Always false condition in 'java.nio.file.FileSystem#getPathMatcher
 implementations
Message-ID: <CAF+DQ5d0bURt0_QWc_=VYZst+mCodVMbzrEVPxHB4D68fuaWgQ@mail.gmail.com>

Hello.
I found suspicious check in all 4 JDK implementations of
java.nio.file.FileSystem#getPathMatcher

https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L178
https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java#L285
https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java#L264
https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L444

public PathMatcher getPathMatcher(String syntaxAndInput) {
    int pos = syntaxAndInput.indexOf(':');
    if (pos <= 0 || pos == syntaxAndInput.length()) {
        throw new IllegalArgumentException();
    }

Variable 'pos' is the result of the 'String.indexOf' method call. Then
variable 'pos' is compared with 'length()' of the string with ==.
But the maximum possible returned value of String.indexOf() is
'length()-1'. It means check 'pos == syntaxAndInput.length()' will
always be 'false'.


Andrey Turbanov

From Alan.Bateman at oracle.com  Fri Apr  8 07:07:29 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 8 Apr 2022 08:07:29 +0100
Subject: Always false condition in
 'java.nio.file.FileSystem#getPathMatcher implementations
In-Reply-To: <CAF+DQ5d0bURt0_QWc_=VYZst+mCodVMbzrEVPxHB4D68fuaWgQ@mail.gmail.com>
References: <CAF+DQ5d0bURt0_QWc_=VYZst+mCodVMbzrEVPxHB4D68fuaWgQ@mail.gmail.com>
Message-ID: <f9d41429-dc33-1651-4d85-e8c505ab20b0@oracle.com>

On 08/04/2022 07:27, Andrey Turbanov wrote:
> Hello.
> I found suspicious check in all 4 JDK implementations of
> java.nio.file.FileSystem#getPathMatcher
>
> https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L178
> https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java#L285
> https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java#L264
> https://github.com/openjdk/jdk/blob/8c1870521815a24fd12480e73450c2201542a442/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L444
>
> public PathMatcher getPathMatcher(String syntaxAndInput) {
>      int pos = syntaxAndInput.indexOf(':');
>      if (pos <= 0 || pos == syntaxAndInput.length()) {
>          throw new IllegalArgumentException();
>      }
>
> Variable 'pos' is the result of the 'String.indexOf' method call. Then
> variable 'pos' is compared with 'length()' of the string with ==.
> But the maximum possible returned value of String.indexOf() is
> 'length()-1'. It means check 'pos == syntaxAndInput.length()' will
> always be 'false'.
It's benign and can be removed, I assume it was copied to the zipfs and 
jrtfs providers when they were initially created and just wasn't noticed.

-Alan

From alanb at openjdk.java.net  Fri Apr  8 07:11:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 07:11:42 GMT
Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived
 Reference object
In-Reply-To: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
References: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
Message-ID: <RaQeKNkbg4KrfBv6ypXCy7BFsfL8M2wt69EvaTkGr2Q=.9a64c07b-3325-470e-9fad-33cfe63327c4@github.com>

On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived.
> 
> The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app).
> 
> I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure.
> 
> Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces.

The updates to resetArchivedStates look okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8151

From kasperni at gmail.com  Fri Apr  8 07:19:03 2022
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 8 Apr 2022 08:19:03 +0100
Subject: fast way to infer caller
In-Reply-To: <024f904f-53c1-2176-2e6c-f929d638ad1a@fiolino.de>
References: <5ee33bc6-80ae-f853-ef80-0131e3d706c9@qos.ch>
 <CAPs6151es+ZM25TVTYxVVtzU_OqhQiQ9Ysjvujg7OD-Oo28nmA@mail.gmail.com>
 <1190634493.8596218.1649334759533.JavaMail.zimbra@u-pem.fr>
 <CAPs6152LEqNo4Grv_xWxc0WqcWwv_Y40X4KT7wC3H-k0928nsA@mail.gmail.com>
 <1076370173.8652451.1649338642856.JavaMail.zimbra@u-pem.fr>
 <CAPs6150aFJ01jPonJwRDNuPhtYsoowGcmPXTxMpG=xNq-KX9Vw@mail.gmail.com>
 <166ee6cd-dd5b-2e0e-e733-6599441a8254@fiolino.de>
 <CAPs61529Bgu7YX7CSO-UrtnsDxcg7fZudZAgQV7Kq0yO2a_Ewg@mail.gmail.com>
 <024f904f-53c1-2176-2e6c-f929d638ad1a@fiolino.de>
Message-ID: <CAPs6151HhTs+g+Q=iB9uLpLkTWD6ZG2KGKq1bE8c_LN+7T0-DA@mail.gmail.com>

On Fri, 8 Apr 2022 at 06:57, Michael Kuhlmann <jdk at fiolino.de> wrote:

> Good morning!
>
> On 4/7/22 23:59, Kasper Nielsen wrote:
> > Hi Michael,
> >
> > I don't really have an opinion on how you obtain a logger. But one
> > particular
> > use-case I've had was that I would like to perform some access checks
> based
> > on the module of the caller. Something similar to how Panama checks for
> > native access:
> >
> > Reflection.ensureNativeAccess(Reflection.getCallerClass());
>
> Hmh, but wouldn't it be sufficient to perform these checks at
> initialization time?
>

There might not be an initialization time. Take, for example, this
piece of code from jdk.incubator.foreign.CLinker:

static void freeMemory(MemoryAddress addr) {
        Reflection.ensureNativeAccess(Reflection.getCallerClass());
        SharedUtils.checkAddress(addr);
        SharedUtils.freeMemoryInternal(addr);
 }


> That I totally agree! Having the exact line number in the log statement
> would be a huge win.
>
> But to be honest, Reflection::getCallerClass wouldn't help either.
>

Getting the caller class is the fastest operation of StackWalker.
Getting something like line numbers from the top stack frame is
somewhat slower.

Again for many use cases, the performance of StackWalker is fine.
But if you like Ceki is looking for information about stack frames
and only have 100 ns to spend then there aren't really any APIs
you can use.

/Kasper

From tschatzl at openjdk.java.net  Fri Apr  8 08:20:58 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 8 Apr 2022 08:20:58 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap
 areas
Message-ID: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>

Hi all,

  can I have reviews for this change that adds dedicated filler objects to the VM?

Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.

This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.

This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.

With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.

This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.

This has the following benefits:

- keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)

- this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.

This causes some minor changes to external behavior:

- logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.

- if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.

The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.


Testing: tier1-8

There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.

Thanks go to @iklam for helping out with the change.

Thanks,
  Thomas

-------------

Commit messages:
 - First stab at new filler - sjohanss

Changes: https://git.openjdk.java.net/jdk/pull/8156/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284435
  Stats: 33 lines in 7 files changed: 27 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8156.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156

PR: https://git.openjdk.java.net/jdk/pull/8156

From ihse at openjdk.java.net  Fri Apr  8 08:52:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 08:52:59 GMT
Subject: RFR: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <tc9JTeyFT98SDZ2QEHFW-CilU3W6p38sqP1WD233t9E=.f64160c5-83f1-40e9-9caa-f70b063884d4@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Have you checked if this update has any impact on the runtime of the CLDRConverter tool?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From alanb at openjdk.java.net  Fri Apr  8 09:29:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 09:29:43 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v5]
In-Reply-To: <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
Message-ID: <7olsoDYnJL8n81CoWHgd-dVXRWHiWX0zkUAhb2R-sB4=.45e87bc7-905b-4917-b411-1210a36c5723@github.com>

On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked 
>> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766)
>> 
>> We found the issue can be produced stably with at least 64 modules.
>> Note that we need to add the --date jmod option to avoid the timestamp issue.
>> 
>> Testing:
>> Added test case fails without fix for JDK-8240734, and passes otherwise.
>> Tested with tier2 on linux x86.
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8240903
>  - Delete extra blank links
>  - Change shell test io java test
>  - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z'
>  - Update Copyright
>  - 8240903: Add a regression test for JDK-8240734

I think this looks okay. Can you say how long the test runs for you? It creates 130 JMOD files and I'm just wondering if the default timeout is enough when running with debug builds.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From dongbohe at openjdk.java.net  Fri Apr  8 10:14:41 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 8 Apr 2022 10:14:41 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v5]
In-Reply-To: <7olsoDYnJL8n81CoWHgd-dVXRWHiWX0zkUAhb2R-sB4=.45e87bc7-905b-4917-b411-1210a36c5723@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
 <7olsoDYnJL8n81CoWHgd-dVXRWHiWX0zkUAhb2R-sB4=.45e87bc7-905b-4917-b411-1210a36c5723@github.com>
Message-ID: <kfOWyCgU8lUZgxf3_QTPhIm-lpVDuwelBL2G36plP2Q=.6ed1c628-448d-41e4-bde1-d98f0797991b@github.com>

On Fri, 8 Apr 2022 09:26:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this looks okay. Can you say how long the test runs for you? It creates 130 JMOD files and I'm just wondering if the default timeout is enough when running with debug builds.

The following is the test result on linux x86 with 128 cores, it looks ok.

time make CONF=release run-test TEST=test/jdk/tools/jmod/hashes/HashesOrderTest.java
Finished building target 'run-test' in configuration 'linux-x86_64-server-release'

real	0m24.235s
user	0m52.196s
sys	0m7.170s

time make CONF=slowdebug run-test TEST=test/jdk/tools/jmod/hashes/HashesOrderTest.java
real	2m2.877s
user	5m58.887s
sys	0m10.474s

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From redestad at openjdk.java.net  Fri Apr  8 11:54:06 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Apr 2022 11:54:06 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter
Message-ID: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>

A few additional enhancements aiming to improve VH performance in the interpreter:

- Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
- Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.

Baseline

Benchmark                                 Mode  Cnt    Score   Error  Units
VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op


Patched

Benchmark                                 Mode  Cnt    Score   Error  Units
VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op

-------------

Commit messages:
 - Various improvements to VarHandle startup

Changes: https://git.openjdk.java.net/jdk/pull/8160/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284579
  Stats: 232 lines in 4 files changed: 18 ins; 23 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8160.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8160/head:pull/8160

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Fri Apr  8 12:20:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Apr 2022 12:20:32 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
Message-ID: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>

> A few additional enhancements aiming to improve VH performance in the interpreter:
> 
> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
> 
> Baseline, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
> 
> 
> Patched, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
> 
> 
> No significant performance difference in normal mode.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Simplified as suggested by @ExE-Boss

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8160/files
  - new: https://git.openjdk.java.net/jdk/pull/8160/files/49c8fdf8..68f414a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8160.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8160/head:pull/8160

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Fri Apr  8 12:20:32 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 8 Apr 2022 12:20:32 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <IBZhF181v0FXj9MVv8t68Cjsh9SXss0_X4WpUn6F5JA=.a04d378d-f447-4e89-94b0-d52dcaa43e24@github.com>

On Fri, 8 Apr 2022 12:16:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 104:

> 102:         if (exact && accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
> 103:             throwWrongMethodTypeException(ad);
> 104:         }

This?could also?be:
Suggestion:

        super.checkExactAccessMode(ad);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Fri Apr  8 12:20:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Apr 2022 12:20:33 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <IBZhF181v0FXj9MVv8t68Cjsh9SXss0_X4WpUn6F5JA=.a04d378d-f447-4e89-94b0-d52dcaa43e24@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <IBZhF181v0FXj9MVv8t68Cjsh9SXss0_X4WpUn6F5JA=.a04d378d-f447-4e89-94b0-d52dcaa43e24@github.com>
Message-ID: <UUZecDG7eRWQUyilBIwnIU4jS1QNQ8w9fprJTmrPfmg=.f19e00d4-7ecf-4b5e-8f45-7f74076f8bd6@github.com>

On Fri, 8 Apr 2022 12:12:06 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified as suggested by @ExE-Boss
>
> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 104:
> 
>> 102:         if (exact && accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
>> 103:             throwWrongMethodTypeException(ad);
>> 104:         }
> 
> This?could also?be:
> Suggestion:
> 
>         super.checkExactAccessMode(ad);

Good suggestions, fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From jpai at openjdk.java.net  Fri Apr  8 13:08:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 8 Apr 2022 13:08:44 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
Message-ID: <9mXR3uhb373Ngo4EgeZK6HgrxPykWQWMI3-N6l_sh3E=.e97b8f62-15a0-44ba-97a8-598fd4652fa4@github.com>

On Wed, 6 Apr 2022 16:28:21 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 100:

> 98:      * <p>
> 99:      * If <i>n</i> denotes the returned number of inflated bytes then {@code buf[off]}
> 100:      * trough {@code buf[off+}<i>n</i>{@code -1]} will contain the uncompressed data. The

Hello Volker, there's a typo here - "trough" should be "through"

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 107:

> 105:      *
> 106:      * @param buf the buffer into which the data is read
> 107:      * @param off the start offset in the destination array {@code b}

Although not related to this PR, since we are already in this area, could you also please fix this and change `{@code b}` to `{@code buf}`

src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 132:

> 130:      * <p>
> 131:      * If <i>n</i> denotes the returned number of inflated bytes then {@code b[off]}
> 132:      * trough {@code b[off+}<i>n</i>{@code -1]} will contain the uncompressed data. The

Same typo here too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From jpai at openjdk.java.net  Fri Apr  8 13:14:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 8 Apr 2022 13:14:44 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
Message-ID: <HV2d1hwa3E0bOuRD32sJIp7G8eqbl2OBcb6x4Pxrvk4=.9d25ebcd-3274-4af1-9091-422253a08c6b@github.com>

On Wed, 6 Apr 2022 16:28:21 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()

src/java.base/share/classes/java/util/zip/ZipFile.java line 346:

> 344:      * have been returned by invocations of this method.
> 345:      *
> 346:      * @implNote In the JDK implementation this method returns an

The "In the JDK implementation" sounds a bit odd to me. I looked around some other `@implNote`s and many of of them use `@implNote This implementation ....`, so perhaps we should change this to:
``` 
@implNote This implementation returns an instance of {@link java.util.zip.InflaterInputStream}.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From jpai at openjdk.java.net  Fri Apr  8 13:25:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 8 Apr 2022 13:25:45 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
Message-ID: <49430xjrok70legiUEkzV6F2Uzn4e2y78R3uLdp3m1E=.315aa0eb-20f1-4b8e-a71a-823c770f25a6@github.com>

On Wed, 6 Apr 2022 16:28:21 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()

The `GZIPInputStream` and `ZipInputStream` files will need a copyright year update.

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 173:

> 171:      * bytes are read and {@code 0} is returned.
> 172:      * <p>
> 173:      * If <i>n</i> denotes the returned number of inflated bytes then {@code b[off]}

I think this might need a slightly different wording since in this case of `ZipInputStream#read(...)`, the entry's  compression method decides whether or not an inflater will be used to return inflated bytes.

So maybe we should just remove the reference to "inflated bytes" and instead say:

* If <i>n</i> denotes the return value, then {@code b[off]} through {@code b[off+}<i>n</i>{@code -1]}
* will contain the data that has been read. The elements {@code b[off+}<i>n</i>{@code ]} through 
* {@code b[off+}<i>len</i>{@code -1]} are undefined and the implementation may update them during this read
* operation. If the return value is -1 or an exception is thrown the whole content of {@code b} is undefined.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From alanb at openjdk.java.net  Fri Apr  8 15:03:28 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 15:03:28 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
Message-ID: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>

This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.

We will refresh this PR periodically to pick up changes and fixes from the loom repo.

Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.

The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.

There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.

The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.

The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284161
  Stats: 101472 lines in 1116 files changed: 91922 ins; 4207 del; 5343 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From mcimadamore at openjdk.java.net  Fri Apr  8 15:09:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 8 Apr 2022 15:09:38 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <NtKlesPctpOV99R_2q6hZUOS5LvlOKeztlx_X7g4dDI=.dbd0f7a7-47a2-4fca-a9a4-db1229947d24@github.com>

On Fri, 8 Apr 2022 12:20:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

The changes look good. You might want to run few of the memory segment JMH benchmarks - especially the ones in "LoopOverNonConstant" and "TestAdaptVarHandles", to make sure they don't regress.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8160

From naoto at openjdk.java.net  Fri Apr  8 15:26:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 15:26:35 GMT
Subject: Integrated: 8283698: Refactor Locale constructors used in src/test
In-Reply-To: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
References: <wRBDQ738zQ0djbWm5ki1yOnUftNn4oKaOHxcptM-3FE=.7b0d10f0-b110-4f47-9e34-34937fb48503@github.com>
Message-ID: <r6its8TfgpC32jQ7YIdERQEA2ElBz-DOEd9zkKv5vGY=.38b6000b-7b2b-4180-8981-19fc570c322a@github.com>

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`.

This pull request has now been integrated.

Changeset: d6b4693c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb
Stats:     750 lines in 182 files changed: 3 ins; 3 del; 744 mod

8283698: Refactor Locale constructors used in src/test

Reviewed-by: iris, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8130

From darcy at openjdk.java.net  Fri Apr  8 15:37:36 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 8 Apr 2022 15:37:36 GMT
Subject: RFR: 8284567: Collapse identical catch branches in java.base
In-Reply-To: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
References: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
Message-ID: <AoXUpLg-OPW11XPpA6XUtudCGibBI_Tura289hYFRLk=.2ee36c42-53c1-4b7b-979f-133aa141bfd2@github.com>

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

Core libs changes look okay.

I assume the docs build also works fine with the import statements removed.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8081

From kvn at openjdk.java.net  Fri Apr  8 16:36:47 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 16:36:47 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <vTCHK2BpP5WUrHxFeq_bx0qGt5d6MXAUJ1Llt97kkfM=.b038dd46-164e-4122-b6e5-a4399c632d32@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
 <vTCHK2BpP5WUrHxFeq_bx0qGt5d6MXAUJ1Llt97kkfM=.b038dd46-164e-4122-b6e5-a4399c632d32@github.com>
Message-ID: <3ol5UgzLV7Nh2MtleKBs1GzbsmDAj7VBgK0MwQqPBgU=.bc82f703-6e32-43c3-8276-344805f4e9bb@github.com>

On Fri, 8 Apr 2022 01:59:10 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Personally, I think the optimisation for `div < 0` should be handled by the mid-end optimiser, which will not only give us the advantages of dead code elimination, but also global code motion. I would suggest the backend only doing `xorl rdx, rdx; divl $div$$Register` and the optimisation for `div < 0` will be implemented as a part of JDK-8282365. What do you think?

 I agree that we can do more optimizations with constants as JDK-8282365 suggested.

But I think we should proceed with current changes as they are after fixing remaining issues.
I assume that you are talking about case when `divisor` is constant (or both). Because if it is not, IR optimization will not help - we don't profile arithmetic values so we can't generate uncommon trap path without some profiling information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From joehw at openjdk.java.net  Fri Apr  8 16:38:39 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 8 Apr 2022 16:38:39 GMT
Subject: Integrated: 8279876: Clean up: isAssignableFrom usages in xpath and
 jdk internal classes
In-Reply-To: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
References: <wYLhdKql-KUa1CIZ_y0PDLObDbN4RA04dOrNkz3BsD8=.2defb6dc-63b8-446e-b534-c2ca890bb776@github.com>
Message-ID: <3-gRqloLeDbOiyWzUpzo6Hvy5Ai9KHb09w4aGQf-Ycw=.02039e59-4e53-4685-b448-6f5c08755c2b@github.com>

On Tue, 5 Apr 2022 23:05:47 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Clean up the usages of isAssignableFrom in a few xpath and jdk/internal classes where the checks were really about equality or whether they were the exact class types. It was why they worked nonetheless even though some of them were backwards.
> 
> Test: existing tests passed.

This pull request has now been integrated.

Changeset: 0a026759
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a0267590fad6a2d14d499588c97bb11e554feb9
Stats:     26 lines in 6 files changed: 1 ins; 0 del; 25 mod

8279876: Clean up: isAssignableFrom usages in xpath and jdk internal classes

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8116

From kvn at openjdk.java.net  Fri Apr  8 16:42:34 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 16:42:34 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
 <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
 <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>
Message-ID: <oLVoGxGtBz8w5oYb0sYsoY85Paya0AKRrbPWGoVPkSA=.53daf255-10b6-4364-a823-b23d54739c65@github.com>

On Fri, 8 Apr 2022 00:55:50 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> I have few comments.
>
> Hi Vladimir (@vnkozlov),
> 
> Incorporated all the suggestions you made in the previous review and pushed a new commit.
> Please let me know if anything else is needed.
> 
> Thanks,
> Vamsi

@vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a]
#



# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038]
#

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From dfuchs at openjdk.java.net  Fri Apr  8 16:44:01 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Apr 2022 16:44:01 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently
Message-ID: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>

Please find enclosed a patch for 
`8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`

My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.

Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.

-------------

Commit messages:
 - 8283719: java/util/logging/CheckZombieLockTest.java failing intermittently

Changes: https://git.openjdk.java.net/jdk/pull/8168/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8168&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283719
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8168.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8168/head:pull/8168

PR: https://git.openjdk.java.net/jdk/pull/8168

From mchung at openjdk.java.net  Fri Apr  8 16:47:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 8 Apr 2022 16:47:54 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
Message-ID: <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>

On Thu, 7 Apr 2022 03:33:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
> 
> Thanks in advance for the reviews,
> Vicente

Looks okay.   Most of the changes is in javadoc and rename `var` to `varIndex`.  The change in ASMifier looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8135

From alanb at openjdk.java.net  Fri Apr  8 16:47:56 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 16:47:56 GMT
Subject: RFR: 8283892: Compress and expand bits [v4]
In-Reply-To: <ApKOKvCjSGHEVpX0tRrQd8_5XS-XLEl2R8kFu9aiBVI=.a5056526-01dd-45d6-a397-7c5a18cab311@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <ApKOKvCjSGHEVpX0tRrQd8_5XS-XLEl2R8kFu9aiBVI=.a5056526-01dd-45d6-a397-7c5a18cab311@github.com>
Message-ID: <3ANKhHZjNb4xhnM0aNFbbRKi5JOd7CG2aFW4dRyukVo=.1314c92f-d9b8-48d4-8126-d190d56f0160@github.com>

On Thu, 7 Apr 2022 18:29:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
>> 
>> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
>> 
>> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
>> 
>> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
>> 
>> Testing-wise the approach take is three fold:
>> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
>> 2. Tests composed of compress and expand and vice versa.
>> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.
>
> Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo.
>  - Provide examples.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From iklam at openjdk.java.net  Fri Apr  8 16:53:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 8 Apr 2022 16:53:42 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas
In-Reply-To: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
Message-ID: <Fpjxjy5khDddqgZ0XLt54FYoxRvKBiLu3Vpr_WkCubg=.c213f934-a419-4c7e-a563-689e88adf8cd@github.com>

On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that adds dedicated filler objects to the VM?
> 
> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
> 
> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
> 
> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
> 
> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
> 
> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
> 
> This has the following benefits:
> 
> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
> 
> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
> 
> This causes some minor changes to external behavior:
> 
> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
> 
> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
> 
> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
> 
> 
> Testing: tier1-8
> 
> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
> 
> Thanks go to @iklam for helping out with the change.
> 
> Thanks,
>   Thomas

Changes requested by iklam (Reviewer).

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1727:

> 1725:     ArchivedMirrorPatcher::update_array_klasses(k);
> 1726:   }
> 1727:   ArchivedMirrorPatcher::update_array_klasses(Universe::fillerArrayKlassObj());

I think this is not necessary. `Universe::fillerArrayKlassObj()` shares the same mirror as `Universe::intArrayKlassObj()`, which has already been updated in the loop above.

`ArchivedMirrorPatcher::update_array_klasses(k)` will essentially do `k->mirror->pointer_back_to_klass += delta`, so it will incorrectly set the pointer when delta is not zero.

I would suggest running with


-XX:ArchiveRelocationMode=1 -Xlog:cds -Xlog:class+load=debug


and step into the following code: 


void java_lang_Class::update_archived_mirror_native_pointers(oop archived_mirror) {
  assert(MetaspaceShared::relocation_delta() != 0, "must be");

  Klass* k = ((Klass*)archived_mirror->metadata_field(_klass_offset));
  archived_mirror->metadata_field_put(_klass_offset,
      (Klass*)(address(k) + MetaspaceShared::relocation_delta())); <<<< HERE

src/hotspot/share/memory/universe.cpp line 205:

> 203:   }
> 204:   // Hide _fillerArrayKlassObj from JVMTI
> 205:   // closure->do_klass(_fillerArrayKlassObj);

Maybe the comment should be more explicit?

// We don't do the following because it will confuse JVMTI.
// _fillerArrayKlassObj is used only by GC, which doesn't need to see 
// this klass from basic_type_classes_do().

-------------

PR: https://git.openjdk.java.net/jdk/pull/8156

From duke at openjdk.java.net  Fri Apr  8 16:53:51 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 8 Apr 2022 16:53:51 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <oLVoGxGtBz8w5oYb0sYsoY85Paya0AKRrbPWGoVPkSA=.53daf255-10b6-4364-a823-b23d54739c65@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
 <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
 <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>
 <oLVoGxGtBz8w5oYb0sYsoY85Paya0AKRrbPWGoVPkSA=.53daf255-10b6-4364-a823-b23d54739c65@github.com>
Message-ID: <7qJdOYS-ms-iCS9TOplg9pSiWzu-cS-GYzdRfuu5IOU=.855a0fdc-5d87-47a3-98af-b2771b5e79b6@github.com>

On Fri, 8 Apr 2022 16:39:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi Vladimir (@vnkozlov),
>> 
>> Incorporated all the suggestions you made in the previous review and pushed a new commit.
>> Please let me know if anything else is needed.
>> 
>> Thanks,
>> Vamsi
>
> @vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a]
> #
> 
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038]
> #

@vnkozlov  The `uDivI_rRegNode` currently emits machine code equivalent to the following Java pseudocode:

    if (div < 0) {
        // fast path, if div < 0, then (unsigned)div > MAX_UINT / 2U
        // I don't know why this is so complicated, basically this is rax u>= div ? 1 : 0
        return (rax & ~(rax - div)) >>> (Integer.SIZE - 1); 
    } else {
        // slow path, just do the division normally
        return rax u/ div;
    }

What I am suggesting is to leave the negative-divisor fast part to be implemented in the IR and the macro assembler should only concern emitting the division instruction and not worry about optimisation here.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From alanb at openjdk.java.net  Fri Apr  8 16:54:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 16:54:40 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently
In-Reply-To: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
Message-ID: <zfTkcfsbQSC4VU7uZKjZIEoZg4NpuLbGzd_Jx20UZJs=.660676a7-cecd-4171-9012-238a8c334169@github.com>

On Fri, 8 Apr 2022 16:37:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find enclosed a patch for 
> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
> 
> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
> 
> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/logging/CheckZombieLockTest.java line 247:

> 245:                 try (FileChannel fc = FileChannel.open(Paths.get(lock.getAbsolutePath()),
> 246:                     StandardOpenOption.CREATE_NEW, StandardOpenOption.APPEND,
> 247:                     StandardOpenOption.WRITE)) {

Changing this to use try-with-resources looks good. In passing I wonder why it calls lock.getAbsolutePath(), it's okay to call open with a relative path. Also, if you change this test to use import static then you could change this line to:

`try (FileChannel fc = FileChannel.open(Path.of(lock), CREATE_NEW, APPEND, WRITE))`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8168

From ccheung at openjdk.java.net  Fri Apr  8 16:57:35 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 8 Apr 2022 16:57:35 GMT
Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived
 Reference object
In-Reply-To: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
References: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
Message-ID: <mAdYTWaPvRrlJ18ubCK_GDRGR2kdWXMQiLJUuUCCd9w=.ca9bf125-615e-4861-96b8-6acd369162b3@github.com>

On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived.
> 
> The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app).
> 
> I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure.
> 
> Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces.

LGTM.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8151

From vromero at openjdk.java.net  Fri Apr  8 16:59:35 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 8 Apr 2022 16:59:35 GMT
Subject: RFR: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
 <B37CXk2dVwFAFS9V0crI8Lm4gIfHTwd7_a1Gu-aWeh0=.2628f335-5335-4c57-a8fd-feae1717098e@github.com>
Message-ID: <KsoQYl3H2Z6Q_rgwz2bX-xZbazTBJUDHfkm-oRW7Cr0=.8fd38104-23ca-44de-b3c8-517ef677432d@github.com>

On Fri, 8 Apr 2022 16:44:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
>> 
>> Thanks in advance for the reviews,
>> Vicente
>
> Looks okay.   Most of the changes is in javadoc and rename `var` to `varIndex`.  The change in ASMifier looks good.

thanks @mlchung for the review

-------------

PR: https://git.openjdk.java.net/jdk/pull/8135

From vromero at openjdk.java.net  Fri Apr  8 17:04:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 8 Apr 2022 17:04:42 GMT
Subject: Integrated: 8284361: Updating ASM to 9.3 for JDK 19
In-Reply-To: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
References: <bP_focrkM5ZbdRXnrEl2yJ9ndjQ1GOTUuFcKevaw05A=.3c7da55a-d1d8-4269-aef6-a88fff63e3c1@github.com>
Message-ID: <mvuIv28zWYOe-t_QL5ZBeTysMYB3IMbOh9vGeonYcJA=.86409f34-bdd3-4fbe-bd59-f716de3bb6e2@github.com>

On Thu, 7 Apr 2022 03:33:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> We recently updated our ASM version to 9.2 and just this week version 9.3 was announced with support for JDK19 so it makes sense to update to this last version.
> 
> Thanks in advance for the reviews,
> Vicente

This pull request has now been integrated.

Changeset: 1bd8975c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1bd8975cafade1234f653ab994cb7c6f0a82590f
Stats:     438 lines in 57 files changed: 73 ins; 70 del; 295 mod

8284361: Updating ASM to 9.3 for JDK 19

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8135

From dfuchs at openjdk.java.net  Fri Apr  8 17:08:25 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Apr 2022 17:08:25 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v2]
In-Reply-To: <zfTkcfsbQSC4VU7uZKjZIEoZg4NpuLbGzd_Jx20UZJs=.660676a7-cecd-4171-9012-238a8c334169@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
 <zfTkcfsbQSC4VU7uZKjZIEoZg4NpuLbGzd_Jx20UZJs=.660676a7-cecd-4171-9012-238a8c334169@github.com>
Message-ID: <TdqmDKGj07Q-WzHpD-9JNMKEBwmFtg-G92QpmD1cFs8=.0152c726-c365-4846-96ff-3ef923448913@github.com>

On Fri, 8 Apr 2022 16:50:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated review comments
>
> test/jdk/java/util/logging/CheckZombieLockTest.java line 247:
> 
>> 245:                 try (FileChannel fc = FileChannel.open(Paths.get(lock.getAbsolutePath()),
>> 246:                     StandardOpenOption.CREATE_NEW, StandardOpenOption.APPEND,
>> 247:                     StandardOpenOption.WRITE)) {
> 
> Changing this to use try-with-resources looks good. In passing I wonder why it calls lock.getAbsolutePath(), it's okay to call open with a relative path. Also, if you change this test to use import static then you could change this line to:
> 
> `try (FileChannel fc = FileChannel.open(Path.of(lock), CREATE_NEW, APPEND, WRITE))`

Good idea. Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8168

From dfuchs at openjdk.java.net  Fri Apr  8 17:08:25 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Apr 2022 17:08:25 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v2]
In-Reply-To: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
Message-ID: <1XYjKOoXyXbYO-42PP12DRG6TQDHoSy6XpyWSPgdaWw=.b47141fa-382c-42c0-8580-904a5087de72@github.com>

> Please find enclosed a patch for 
> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
> 
> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
> 
> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8168/files
  - new: https://git.openjdk.java.net/jdk/pull/8168/files/752d4ba0..46527e37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8168&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8168&range=00-01

  Stats: 12 lines in 1 file changed: 2 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8168.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8168/head:pull/8168

PR: https://git.openjdk.java.net/jdk/pull/8168

From alanb at openjdk.java.net  Fri Apr  8 17:12:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 17:12:31 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v2]
In-Reply-To: <1XYjKOoXyXbYO-42PP12DRG6TQDHoSy6XpyWSPgdaWw=.b47141fa-382c-42c0-8580-904a5087de72@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
 <1XYjKOoXyXbYO-42PP12DRG6TQDHoSy6XpyWSPgdaWw=.b47141fa-382c-42c0-8580-904a5087de72@github.com>
Message-ID: <nfZR28rrYKMc0hkO5UmtUG8L8p019YLrUN-fCgWQgqw=.1c6404e7-c122-4043-8215-01806bf2927c@github.com>

On Fri, 8 Apr 2022 17:08:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch for 
>> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
>> 
>> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
>> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
>> 
>> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated review comments

Looks fine, you can drop use of getAbsolutePath if you want to, not important here.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8168

From kvn at openjdk.java.net  Fri Apr  8 17:17:48 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 17:17:48 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
Message-ID: <OMKVOxdoud75sDj9KXVwm-JX59QwJDyRp3Vx7YmTFuI=.d81542a4-ca8b-41f9-ae6b-d7746176fb8e@github.com>

On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncomment zero in integer div, mod test

Agree, this is reasonable suggestion. It could be done in these changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From dfuchs at openjdk.java.net  Fri Apr  8 17:20:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Apr 2022 17:20:36 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v3]
In-Reply-To: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
Message-ID: <DxuaYlHAHxGVbeuqo8lnx21bU6eWcULG43lw_AiDwfo=.1dce1db0-6ba0-433c-a339-4218cc032ab8@github.com>

> Please find enclosed a patch for 
> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
> 
> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
> 
> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8168/files
  - new: https://git.openjdk.java.net/jdk/pull/8168/files/46527e37..f0872022

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8168&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8168&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8168.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8168/head:pull/8168

PR: https://git.openjdk.java.net/jdk/pull/8168

From dfuchs at openjdk.java.net  Fri Apr  8 17:20:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Apr 2022 17:20:37 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v2]
In-Reply-To: <nfZR28rrYKMc0hkO5UmtUG8L8p019YLrUN-fCgWQgqw=.1c6404e7-c122-4043-8215-01806bf2927c@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
 <1XYjKOoXyXbYO-42PP12DRG6TQDHoSy6XpyWSPgdaWw=.b47141fa-382c-42c0-8580-904a5087de72@github.com>
 <nfZR28rrYKMc0hkO5UmtUG8L8p019YLrUN-fCgWQgqw=.1c6404e7-c122-4043-8215-01806bf2927c@github.com>
Message-ID: <66VF4EFHxSn3qOKlWWU-ae66FUh8RbV4e4aErrrlSZU=.85754a39-c346-46a8-baf1-e95aad3e65f5@github.com>

On Fri, 8 Apr 2022 17:09:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks fine, you can drop use of getAbsolutePath if you want to, not important here.

Done - used `File::toPath` since `lock` is a `File`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8168

From iklam at openjdk.java.net  Fri Apr  8 17:22:43 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 8 Apr 2022 17:22:43 GMT
Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived
 Reference object
In-Reply-To: <RaQeKNkbg4KrfBv6ypXCy7BFsfL8M2wt69EvaTkGr2Q=.9a64c07b-3325-470e-9fad-33cfe63327c4@github.com>
References: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
 <RaQeKNkbg4KrfBv6ypXCy7BFsfL8M2wt69EvaTkGr2Q=.9a64c07b-3325-470e-9fad-33cfe63327c4@github.com>
Message-ID: <lNUO3r7JZ4K5Cjup4YxtDlzYE8lkJBgCJozG_x6sQ2o=.24e4519f-7d11-4ab7-93af-5cda7d9ca398@github.com>

On Fri, 8 Apr 2022 07:08:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived.
>> 
>> The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app).
>> 
>> I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure.
>> 
>> Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces.
>
> The updates to resetArchivedStates look okay.

Thanks @AlanBateman and @calvinccheung for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8151

From iklam at openjdk.java.net  Fri Apr  8 17:22:43 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 8 Apr 2022 17:22:43 GMT
Subject: Integrated: 8284336: CDS SignedJar.java test fails due to archived
 Reference object
In-Reply-To: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
References: <gZJlURF1E0NovIfZkAta4OVGaun9QbUtZ8AXjLF6hv4=.87f431a9-8d3b-4357-b675-5ab2308cc46f@github.com>
Message-ID: <8Xiu1d7aUGEzZXenIQX6EouQI7jFJWAD1CGxPpFIxRI=.b2eb0af2-7426-4c17-a185-b58f582137db@github.com>

On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived.
> 
> The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app).
> 
> I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure.
> 
> Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces.

This pull request has now been integrated.

Changeset: 662320a0
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/662320a0ec0b373fa1e4df9281224e9bdbdf76ac
Stats:     28 lines in 5 files changed: 25 ins; 0 del; 3 mod

8284336: CDS SignedJar.java test fails due to archived Reference object

Reviewed-by: alanb, ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8151

From naoto at openjdk.java.net  Fri Apr  8 18:21:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 18:21:45 GMT
Subject: RFR: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <tvUCnJtW5eM49aasxZUe-TGLuEzKykVvEdE8tQ0NrBM=.3267ec10-50cd-4004-87f2-51ab2b4b987f@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

I measured the execution time of `CLDRConverter`. Each run measures an average execution time for 5 invocations of `CLDRConverter.main()`, and I ran it 5 times for `java.base` and `jdk.localedata` modules. All average values are in seconds.

- Before the fix
  - java.base: 11.536 - 12.836
  - jdk.localedata: 19.764 - 22.584
- After the fix
  - java.base: 11.666 - 12.833
  - jdk.localedata: 19.183 - 20.838
 
Looking at the results, I don't see any notable tool execution time difference with this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From iris at openjdk.java.net  Fri Apr  8 18:26:06 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 8 Apr 2022 18:26:06 GMT
Subject: RFR: 8284567: Collapse identical catch branches in java.base
In-Reply-To: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
References: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
Message-ID: <pNRkBz-0V_VtdAKNbFNLjI7wo8qRFB9R9zhSuhiqLJw=.74ca9cf0-de8b-4561-b64d-87aec197d636@github.com>

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8081

From sviswanathan at openjdk.java.net  Fri Apr  8 18:34:10 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 8 Apr 2022 18:34:10 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
Message-ID: <km8uHXtW7wserEDr9DrOd4zibq-YKvkndDuFUtV3P5c=.8d4b402d-7588-4268-9eee-88a86899e851@github.com>

On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncomment zero in integer div, mod test

My suggestion is to keep the -ve path assembly optimization in this patch.
When the optimization in IR is introduced, the assembly could then be simplified as suggested by @merykitty.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 18:39:59 2022
From: duke at openjdk.java.net (farhankhan04)
Date: Fri, 8 Apr 2022 18:39:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <27Nx03MrIUd1fTR-T3GAGvt6aaX5_P-RUUVzd4pOgGE=.0194757d-30c9-48ec-bc6b-10195d39cfea@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Marked as reviewed by farhankhan04 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr  8 18:41:53 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 8 Apr 2022 18:41:53 GMT
Subject: RFR: 8283892: Compress and expand bits [v5]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <iU8kMdKaoKcCvlytz58d-gLAxEF09SEVwoSRoXDsunE=.0d09688e-0031-41f1-8a7a-23a1ad6d092d@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Updates to examples

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/96d90e1a..ee062537

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=03-04

  Stats: 40 lines in 2 files changed: 10 ins; 2 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From wetmore at openjdk.java.net  Fri Apr  8 18:44:53 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 8 Apr 2022 18:44:53 GMT
Subject: RFR: 8284567: Collapse identical catch branches in java.base
In-Reply-To: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
References: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
Message-ID: <AhJT_bNsIH0VrDnqWDiSc-noqAd9ljfSrHDB90Pe3ug=.66557617-d98b-4ef9-a94b-19ad4f70b481@github.com>

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

src/java.base/share/classes/java/net/URI.java line 47:

> 45: import sun.nio.cs.UTF_8;
> 46: 
> 47: import java.lang.Character;             // for javadoc

Looks like the javadoc comment no longer applies, so should be ok to remove.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8081

From alanb at openjdk.java.net  Fri Apr  8 19:07:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 8 Apr 2022 19:07:43 GMT
Subject: RFR: 8283719: java/util/logging/CheckZombieLockTest.java failing
 intermittently [v3]
In-Reply-To: <DxuaYlHAHxGVbeuqo8lnx21bU6eWcULG43lw_AiDwfo=.1dce1db0-6ba0-433c-a339-4218cc032ab8@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
 <DxuaYlHAHxGVbeuqo8lnx21bU6eWcULG43lw_AiDwfo=.1dce1db0-6ba0-433c-a339-4218cc032ab8@github.com>
Message-ID: <FnwQRuN-v8OfIEF3B1GhL8O1PjpntRabO5XI40HkJSs=.ecdd83c3-2210-4c6e-b877-b8083735444a@github.com>

On Fri, 8 Apr 2022 17:20:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch for 
>> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
>> 
>> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
>> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
>> 
>> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated review comments

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8168

From ihse at openjdk.java.net  Fri Apr  8 19:10:56 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 8 Apr 2022 19:10:56 GMT
Subject: RFR: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <xAUT9Nzg0QsOAJTRMBVDsGyFLHkqSeyb9MlxsdsqOMQ=.d886093d-edf4-4c59-a8a2-f4873630c47a@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Marked as reviewed by ihse (Reviewer).

Great, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From psandoz at openjdk.java.net  Fri Apr  8 19:13:35 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 8 Apr 2022 19:13:35 GMT
Subject: RFR: 8283892: Compress and expand bits [v6]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <up42fBoFxGq1ZTyG7gy1EshGxhskU7QF6kyfXiSb9MY=.a9542a61-49f7-4114-b223-01a51bf23d9e@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Refer to hexadecimal digit

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/ee062537..f9b7b2bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=04-05

  Stats: 18 lines in 2 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From wetmore at openjdk.java.net  Fri Apr  8 19:31:40 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 8 Apr 2022 19:31:40 GMT
Subject: RFR: 8284567: Collapse identical catch branches in java.base
In-Reply-To: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
References: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
Message-ID: <wRm73g0-q90EUWgogKz6aPX7J5w-vCt2CiTPpYiZsY0=.dfd1a445-2caf-44fe-968e-d354c93dd78a@github.com>

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

LGTM

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8081

From kvn at openjdk.java.net  Fri Apr  8 19:37:44 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 19:37:44 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
In-Reply-To: <km8uHXtW7wserEDr9DrOd4zibq-YKvkndDuFUtV3P5c=.8d4b402d-7588-4268-9eee-88a86899e851@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <IlzZBwOzLV3hUP5L9-qzqal9cAz1QoMzk9LDUo047vo=.3b2610a0-0cbd-493e-82fa-d8830c3f5f19@github.com>
 <km8uHXtW7wserEDr9DrOd4zibq-YKvkndDuFUtV3P5c=.8d4b402d-7588-4268-9eee-88a86899e851@github.com>
Message-ID: <XPUlrzYh4wicxigC8mBhBLNACMCVWS5ipplBN7kmmNc=.f02e8648-0983-411e-951c-e97e3916a147@github.com>

On Fri, 8 Apr 2022 18:32:06 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> My suggestion is to keep the -ve path assembly optimization in this patch.
> When the optimization in IR is introduced, the assembly could then be simplified as suggested by @merykitty.

Okay. Lets do that as part of JDK-8282365.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From naoto at openjdk.java.net  Fri Apr  8 20:17:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Apr 2022 20:17:52 GMT
Subject: RFR: 8265315: Support for CLDR version 41 [v2]
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <B9Xg8dkiI6_9xZ4RFV-XPOdRh5vp0RCTKOX-DyioI-g=.33a091a7-5065-4265-ab9a-db08187fa236@github.com>

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into cldr+
 - Merge branch 'master' into cldr+
 - CLDR v41 final
 - CLDR v41 beta2
 - Merge branch 'master' into cldr+
 - CLDR v41 alpha4
 - Merge branch 'master' into cldr+
 - Update copyright year to 2022
 - CLDR release v40
 - Merge branch 'master' into cldr
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/a8c87526...9ef22a6d

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8150/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8150&range=01
  Stats: 132400 lines in 859 files changed: 96406 ins; 4216 del; 31778 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8150.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8150/head:pull/8150

PR: https://git.openjdk.java.net/jdk/pull/8150

From iris at openjdk.java.net  Fri Apr  8 20:41:51 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 8 Apr 2022 20:41:51 GMT
Subject: RFR: 8265315: Support for CLDR version 41 [v2]
In-Reply-To: <B9Xg8dkiI6_9xZ4RFV-XPOdRh5vp0RCTKOX-DyioI-g=.33a091a7-5065-4265-ab9a-db08187fa236@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
 <B9Xg8dkiI6_9xZ4RFV-XPOdRh5vp0RCTKOX-DyioI-g=.33a091a7-5065-4265-ab9a-db08187fa236@github.com>
Message-ID: <AeVFAkQYXGDQRQmC8h1Gu02XKGTkCgxM9zlD0T1hvyM=.b21ffddd-21cd-4f0a-86d6-367bfc2ff3d6@github.com>

On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into cldr+
>  - Merge branch 'master' into cldr+
>  - CLDR v41 final
>  - CLDR v41 beta2
>  - Merge branch 'master' into cldr+
>  - CLDR v41 alpha4
>  - Merge branch 'master' into cldr+
>  - Update copyright year to 2022
>  - CLDR release v40
>  - Merge branch 'master' into cldr
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/a8c87526...9ef22a6d

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From redestad at openjdk.java.net  Fri Apr  8 21:35:49 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Apr 2022 21:35:49 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <NtKlesPctpOV99R_2q6hZUOS5LvlOKeztlx_X7g4dDI=.dbd0f7a7-47a2-4fca-a9a4-db1229947d24@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <NtKlesPctpOV99R_2q6hZUOS5LvlOKeztlx_X7g4dDI=.dbd0f7a7-47a2-4fca-a9a4-db1229947d24@github.com>
Message-ID: <CV7bgVpwXHt8BJyUJxF_ZVq4-km88pMA8XPVgvzy1YY=.3d5ee87f-9dd2-413a-aabd-3a2bdb9f78c9@github.com>

On Fri, 8 Apr 2022 15:05:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> TestAdaptVarHandles

Thanks for reviewing, Maurizio. I ran the micros you suggested and I detect no change whatsoever at peak performance. With `-Xint` there are some small improvements in line with the results above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Fri Apr  8 22:17:23 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 22:17:23 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Fix the divmod crash due to lack of control node

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/3e3fc977..a71ea238

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=11-12

  Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Fri Apr  8 22:17:23 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Fri, 8 Apr 2022 22:17:23 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
In-Reply-To: <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <lnZsOELe2rQDEugsDOSrk-Fa5Cj2OFePFmCUk6LHDtE=.501289c8-d1c2-470b-a66f-00d582194965@github.com>
 <gApXd9DYG701e-jbAC4eyRSZTol6LSd-WL_u1k0eGlQ=.85050527-e37e-47aa-a303-c1cb50ea040d@github.com>
 <XPGkH6fzhU33jOl9iSMsExbwIzMC24MBGJ4A3qeWO7A=.9f38f2f0-a2b5-481e-8aa0-0ae50485a2d6@github.com>
Message-ID: <fZ4sRJp-svkeOxIRxd0hXhtuupIbFwrPlG6rvApgbWo=.0748195b-4626-4ad4-8a8d-2bef7045c36f@github.com>

On Fri, 8 Apr 2022 00:55:50 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> I have few comments.
>
> Hi Vladimir (@vnkozlov),
> 
> Incorporated all the suggestions you made in the previous review and pushed a new commit.
> Please let me know if anything else is needed.
> 
> Thanks,
> Vamsi

> @vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags:
> 
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a]
> #
> ```
> 
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038]
> #
> ```

Hi Vladimir (@vnkozlov), fixed it in the new commit, could you pls check? 
This is being caused by lack of control() node in udiv/umod related nodes. After adding the control() node, the tests are passing for me. Thanks for pointing this out!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From kvn at openjdk.java.net  Fri Apr  8 22:33:52 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 8 Apr 2022 22:33:52 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
Message-ID: <wV9aluMn8lrPwRgQAoTyxx4xosVBRwrusnkqxACGTVA=.c14b0fac-5a35-4e15-86e5-f88f37f9f6ff@github.com>

On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the divmod crash due to lack of control node

I submitted new testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From mchung at openjdk.java.net  Fri Apr  8 22:45:33 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 8 Apr 2022 22:45:33 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <RREWZzj5X-s8K9QSOk029gdtL_DqmGSJR75vSy_Fs84=.83372c2f-87dd-49c0-a0aa-b092820f2059@github.com>

On Fri, 8 Apr 2022 12:20:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

The change looks fine.  A `checkXXX` method if returning a boolean would typically indicate if it succeeds or not.    `checkExactAccessMode` returns the directness of this VarHandle which is not obvious from its method name.   It'd be better if the method name can be explicit that it returns its directness after the exact access mode check.  But I can't think of a good method name though.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8160

From joehw at openjdk.java.net  Fri Apr  8 23:26:54 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 8 Apr 2022 23:26:54 GMT
Subject: RFR: 8265315: Support for CLDR version 41 [v2]
In-Reply-To: <B9Xg8dkiI6_9xZ4RFV-XPOdRh5vp0RCTKOX-DyioI-g=.33a091a7-5065-4265-ab9a-db08187fa236@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
 <B9Xg8dkiI6_9xZ4RFV-XPOdRh5vp0RCTKOX-DyioI-g=.33a091a7-5065-4265-ab9a-db08187fa236@github.com>
Message-ID: <L6S6lbiTDZTIY_dgLcSpjUBA6oODqnG5uHHO_U8FFGw=.233ded0c-dd00-4943-85ed-8ecd68ef837b@github.com>

On Fri, 8 Apr 2022 20:17:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into cldr+
>  - Merge branch 'master' into cldr+
>  - CLDR v41 final
>  - CLDR v41 beta2
>  - Merge branch 'master' into cldr+
>  - CLDR v41 alpha4
>  - Merge branch 'master' into cldr+
>  - Update copyright year to 2022
>  - CLDR release v40
>  - Merge branch 'master' into cldr
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/a8c87526...9ef22a6d

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From redestad at openjdk.java.net  Fri Apr  8 23:37:37 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 8 Apr 2022 23:37:37 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <3bfRJWInKilIfnGqj9Ne4j8VNHKhcRF0Kk-iQqgeS7M=.242d34b5-ae37-4164-9c5a-c9d10dc44a19@github.com>

On Fri, 8 Apr 2022 12:20:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

I couldn't come up with a better name, either, but I'll see if something comes up over the weekend.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From sviswanathan at openjdk.java.net  Sat Apr  9 00:13:38 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 9 Apr 2022 00:13:38 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <fNRGaO8kqLFhu2LyZVxlocbH5kBHvOQ204gwyW2U0zQ=.605f77a3-bae7-4eb6-b654-2cd1ea8a6610@github.com>

On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861:

> 2859:         ByteSpecies vsp = (ByteSpecies) species;
> 2860:         if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) {
> 2861:             return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo);

Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From smarks at openjdk.java.net  Sat Apr  9 02:51:36 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Sat, 9 Apr 2022 02:51:36 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
Message-ID: <2lkpkgeOhKyYOq26mVjVLONTBbc7bMfldmQwXGymISQ=.77182a3b-a4c6-4beb-a35c-030d23b6ebb9@github.com>

On Wed, 6 Apr 2022 16:02:31 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use (double) DEFAULT_LOAD_FACTOR instead of 0.75

Regarding the scope of call sites in this PR: it's definitely worthwhile including call sites, particularly those that have errors! The issue with including a lot of call sites is that it potentially brings in a lot of additional reviewers. We should definitely include call sites in `java.base` as I'm sure we can get good review coverage for those. Others should be included on a case-by-case basis. Maybe we end up including them all, but maybe there are some cases that are questionable -- I'll have to look. We can adjust the labels based on what's the final set.

Note the mapping between files in the repo and applied labels is in

https://github.com/openjdk/skara/blob/master/config/mailinglist/rules/jdk.json

I don't know if there's a way to have these be reapplied automatically. We might have to do some manual pattern matching.

Regarding `@ForceInline` I don't think it's worth worrying about. Like the floating-point vs integer computation, the overhead of calling a method is likely to be quite small compared to the expense of populating the HashMap. The JIT will inline small methods according to its inline policy and heuristics, which I think we should be comfortable relying on.

Note: I still need a reviewer for the CSR: [JDK-8284377](https://bugs.openjdk.java.net/browse/JDK-8284377).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sat Apr  9 04:36:41 2022
From: duke at openjdk.java.net (liach)
Date: Sat, 9 Apr 2022 04:36:41 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
Message-ID: <1QiBgXaHUbUkqXzzPtVAJ8N4kkuYclX8aSRQ-nhH-zU=.470721b1-86ad-40da-9d7a-b2fd0dd62d51@github.com>

On Wed, 6 Apr 2022 16:02:31 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use (double) DEFAULT_LOAD_FACTOR instead of 0.75

Quick question: If the maps are intended to be fixed-size, can't the users just call `new HashMap<>(size, 1)`, increasing the growth factor to prevent growth?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sat Apr  9 06:53:42 2022
From: duke at openjdk.java.net (Furkan =?UTF-8?B?w5Z6bWVu?=)
Date: Sat, 9 Apr 2022 06:53:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <nfxSJmn1VVFkDT1WPhKDkFgEag8p-aadKBAXoSmMGIU=.b0217219-e315-458a-af72-7a9b3f45b6ec@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username).

Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sat Apr  9 15:28:36 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 9 Apr 2022 15:28:36 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <1QiBgXaHUbUkqXzzPtVAJ8N4kkuYclX8aSRQ-nhH-zU=.470721b1-86ad-40da-9d7a-b2fd0dd62d51@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
 <1QiBgXaHUbUkqXzzPtVAJ8N4kkuYclX8aSRQ-nhH-zU=.470721b1-86ad-40da-9d7a-b2fd0dd62d51@github.com>
Message-ID: <kPkacc-Yi3e2MSWKx9O_AcWpUbNHasvLKmfxx_tp0pE=.a71ce346-941e-4cfa-ab6c-c8a47c730ba3@github.com>

On Sat, 9 Apr 2022 04:33:00 GMT, liach <duke at openjdk.java.net> wrote:

> Quick question: If the maps are intended to be fixed-size, can't the users just call `new HashMap<>(size, 1)`, increasing the growth factor to prevent growth?

@liach this questions equals question : "why default load factor be 0.75 not 1"
In short, when larger the load factor, smaller memory use, and larger hash-collide rate, larger crud time cost.
when smaller the load factor, larger memory use, and smaller hash-collide rate, smaller crud time cost.
As for why default load factor be 0.75 but not 1, it is historical to me. it is already 0.75 when I first learn java and never changed then. But I guess there be some empirical formula behind it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sat Apr  9 16:05:40 2022
From: duke at openjdk.java.net (liach)
Date: Sat, 9 Apr 2022 16:05:40 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <kPkacc-Yi3e2MSWKx9O_AcWpUbNHasvLKmfxx_tp0pE=.a71ce346-941e-4cfa-ab6c-c8a47c730ba3@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
 <1QiBgXaHUbUkqXzzPtVAJ8N4kkuYclX8aSRQ-nhH-zU=.470721b1-86ad-40da-9d7a-b2fd0dd62d51@github.com>
 <kPkacc-Yi3e2MSWKx9O_AcWpUbNHasvLKmfxx_tp0pE=.a71ce346-941e-4cfa-ab6c-c8a47c730ba3@github.com>
Message-ID: <9AO6zf6_I03MswoHsFJnpdyFX8Py1jwMFxMZsKh_ZoM=.91f6f30e-80fd-496c-917d-7bb72e4264a8@github.com>

On Sat, 9 Apr 2022 15:25:47 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> > Quick question: If the maps are intended to be fixed-size, can't the users just call `new HashMap<>(size, 1)`, increasing the growth factor to prevent growth?
> 
> @liach this questions equals question : "why default load factor be 0.75 not 1" In short, when larger the load factor, smaller memory use, and larger hash-collide rate, larger crud time cost. when smaller the load factor, larger memory use, and smaller hash-collide rate, smaller crud time cost. As for why default load factor be 0.75 but not 1, it is historical to me. it is already 0.75 when I first learn java and never changed then. But I guess there be some empirical formula behind it.

No. I mean when the growth factor is 1 and exactly `size` key-value pairs are put into the map, the map will not grow; but when it's 0.75, the map will preemptively grow erroneously. Changing the growth factor is effectively no-op for a hash map that will not have more elements added later during its usage.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sat Apr  9 16:33:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 9 Apr 2022 16:33:33 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <9AO6zf6_I03MswoHsFJnpdyFX8Py1jwMFxMZsKh_ZoM=.91f6f30e-80fd-496c-917d-7bb72e4264a8@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
 <1QiBgXaHUbUkqXzzPtVAJ8N4kkuYclX8aSRQ-nhH-zU=.470721b1-86ad-40da-9d7a-b2fd0dd62d51@github.com>
 <kPkacc-Yi3e2MSWKx9O_AcWpUbNHasvLKmfxx_tp0pE=.a71ce346-941e-4cfa-ab6c-c8a47c730ba3@github.com>
 <9AO6zf6_I03MswoHsFJnpdyFX8Py1jwMFxMZsKh_ZoM=.91f6f30e-80fd-496c-917d-7bb72e4264a8@github.com>
Message-ID: <JidrwtOb3Gih22XoICSkBmnsoOJy2oL9Dnyb2wiezHY=.3846057a-6d87-4c98-b94f-3e3e007db91b@github.com>

On Sat, 9 Apr 2022 16:02:17 GMT, liach <duke at openjdk.java.net> wrote:

> > > Quick question: If the maps are intended to be fixed-size, can't the users just call `new HashMap<>(size, 1)`, increasing the growth factor to prevent growth?
> > 
> > 
> > @liach this questions equals question : "why default load factor be 0.75 not 1" In short, when larger the load factor, smaller memory use, and larger hash-collide rate, larger crud time cost. when smaller the load factor, larger memory use, and smaller hash-collide rate, smaller crud time cost. As for why default load factor be 0.75 but not 1, it is historical to me. it is already 0.75 when I first learn java and never changed then. But I guess there be some empirical formula behind it.
> 
> No. I mean when the growth factor is 1 and exactly `size` key-value pairs are put into the map, the map will not grow; but when it's 0.75, the map will preemptively grow erroneously. Changing the growth factor is effectively no-op for a hash map that will not have more elements added later during its usage.

I don't think you get what I mean.
For example.
There be a people who want a 16-elements map.
If use `new HashMap(16 , 1)`, then he will get a table-length-16 hashMap. It will not growth, wth larger load factor, smaller memory use, and larger hash-collide rate, larger crud time cost.
if use `new HashMap(22, 0.75)`, ?` 22 = Math.celil(16 / 0.75)`?then he will get a table-length-32 hashMap. It will not growth, with smaller load factor, larger memory use, and smaller hash-collide rate, smaller crud time cost.
I hope the example can help you understand what is load factor's usage, and be clear about the difference between using 0.75 and 1 as load factor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From kvn at openjdk.java.net  Sat Apr  9 18:29:37 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 9 Apr 2022 18:29:37 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
Message-ID: <cjrwheNMWa3WCOr8dvLAmaII-mm8a8cI-d650uj8HX8=.6f707cfe-8a8d-4183-898c-7d15849dd9ce@github.com>

On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the divmod crash due to lack of control node

Testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7572

From redestad at openjdk.java.net  Sat Apr  9 20:48:37 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 9 Apr 2022 20:48:37 GMT
Subject: RFR: 8283892: Compress and expand bits [v6]
In-Reply-To: <up42fBoFxGq1ZTyG7gy1EshGxhskU7QF6kyfXiSb9MY=.a9542a61-49f7-4114-b223-01a51bf23d9e@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <up42fBoFxGq1ZTyG7gy1EshGxhskU7QF6kyfXiSb9MY=.a9542a61-49f7-4114-b223-01a51bf23d9e@github.com>
Message-ID: <W9bncxHAbCmckjdjxZcV2vMnLPO7nfVn-NRNbxjqrNE=.a86ea0c3-de53-4280-8e30-f89b1a047669@github.com>

On Fri, 8 Apr 2022 19:13:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
>> 
>> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
>> 
>> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
>> 
>> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
>> 
>> Testing-wise the approach take is three fold:
>> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
>> 2. Tests composed of compress and expand and vice versa.
>> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refer to hexadecimal digit

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From duke at openjdk.java.net  Sun Apr 10 01:19:35 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Sun, 10 Apr 2022 01:19:35 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <cbYr7VF9Pw9AafplmrUErxAOTnteynJeEBxOeXGjSyA=.8e5b5b40-fd6a-461b-ab70-34dbcac19812@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

src/java.base/share/classes/java/lang/Runnable.java line 31:

> 29:  * Represents an operation that does not return a result.
> 30:  *
> 31:  * <p> This is a <a href="package-summary.html">functional interface</a>

This?is?supposed to?point to?the?`package?summary.html` of?`java.util.function`, so?it?should?be:
Suggestion:

 * <p> This is a <a href="../util/function/package-summary.html">functional interface</a>

or
Suggestion:

 * <p> This is a {@linkplain java.util.function functional interface}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sun Apr 10 03:36:46 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Sun, 10 Apr 2022 03:36:46 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <cjrwheNMWa3WCOr8dvLAmaII-mm8a8cI-d650uj8HX8=.6f707cfe-8a8d-4183-898c-7d15849dd9ce@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
 <cjrwheNMWa3WCOr8dvLAmaII-mm8a8cI-d650uj8HX8=.6f707cfe-8a8d-4183-898c-7d15849dd9ce@github.com>
Message-ID: <32_WRVZn9x-znpjO70MY_BZoQT8oRSRdSjtSfhvlzzE=.9ab1fcfa-fb70-4a2a-af25-6ed456b53827@github.com>

On Sat, 9 Apr 2022 18:25:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Testing passed.

Thank you Vladimir!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Sun Apr 10 03:49:47 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Sun, 10 Apr 2022 03:49:47 GMT
Subject: Integrated: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <D7QDnvxCBhkD9yqKZltGmfbVQVwAfiUCkpZlaL3eEx0=.7a8fcca9-dfb4-484d-b064-c5f436bbf2c8@github.com>

On Tue, 22 Feb 2022 09:24:47 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

This pull request has now been integrated.

Changeset: 37e28aea
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37e28aea27c8d8336ddecde777e63b51a939d281
Stats:     1156 lines in 20 files changed: 1154 ins; 1 del; 1 mod

8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long

Reviewed-by: sviswanathan, kvn, jbhateja

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Sun Apr 10 06:50:47 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Sun, 10 Apr 2022 06:50:47 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <hE4CeY2zJ_iT8qv8hHv6YrtHeFOQRJTvfpp7ggvArr8=.b0b2b22a-e44f-4559-bdc7-81f15531a5ff@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
 <zjtH8PTx3JPqjwMf0xaI-Xa6OnmUCxe30uD3CpFo2oY=.4e111bb3-8e8d-44c1-aa1f-5392bed41339@github.com>
 <Aqn9vzq3crvrIexXTI4xPgdkIkiZXNLJDPXw5CSVZfs=.1e038b20-5521-43fa-8127-4f675476ecf2@github.com>
 <hE4CeY2zJ_iT8qv8hHv6YrtHeFOQRJTvfpp7ggvArr8=.b0b2b22a-e44f-4559-bdc7-81f15531a5ff@github.com>
Message-ID: <tX_Roms2ijkSESlji599ikoCKXkof9k905ehcvvUSmM=.b1fbd369-4717-4c23-abe9-ffa769987099@github.com>

On Wed, 6 Apr 2022 06:23:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Also need a jtreg test for this.
>> 
>> Thanks Sandhya for the review. Made the suggested changes and added jtreg tests as well.
>
> Hi @vamsi-parasa , thanks for addressing my comments, looks good to me otherwise apart from the outstanding comments.

@jatin-bhateja Thank you Jatin!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From alanb at openjdk.java.net  Sun Apr 10 07:01:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 10 Apr 2022 07:01:39 GMT
Subject: RFR: 8283892: Compress and expand bits [v6]
In-Reply-To: <up42fBoFxGq1ZTyG7gy1EshGxhskU7QF6kyfXiSb9MY=.a9542a61-49f7-4114-b223-01a51bf23d9e@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
 <up42fBoFxGq1ZTyG7gy1EshGxhskU7QF6kyfXiSb9MY=.a9542a61-49f7-4114-b223-01a51bf23d9e@github.com>
Message-ID: <6qMGoZ3ZXjFirFNJ8lQ03-QjleV1ZceDNH81KTGDQG0=.b70954e2-d46b-445c-a26c-83d4f84a0d64@github.com>

On Fri, 8 Apr 2022 19:13:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
>> 
>> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
>> 
>> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
>> 
>> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
>> 
>> Testing-wise the approach take is three fold:
>> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
>> 2. Tests composed of compress and expand and vice versa.
>> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refer to hexadecimal digit

The insertion of "hexadecimal" makes it clearer, good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8115

From alanb at openjdk.java.net  Sun Apr 10 07:44:33 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 10 Apr 2022 07:44:33 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
Message-ID: <QyeTEl09tn_MZVuM_G9EOCCCS8F23STGSM5NTA864Us=.58f46ebb-f407-49cd-92f8-6a37679b36c3@github.com>

On Wed, 6 Apr 2022 16:02:31 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use (double) DEFAULT_LOAD_FACTOR instead of 0.75

src/java.base/share/classes/java/lang/module/Resolver.java line 501:

> 499:     private Map<ResolvedModule, Set<ResolvedModule>> makeGraph(Configuration cf) {
> 500: 
> 501:         int nameToReferenceSize = nameToReference.size();

This can be renamed moduleCount to make it easier to read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From alanb at openjdk.java.net  Sun Apr 10 07:55:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 10 Apr 2022 07:55:39 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v5]
In-Reply-To: <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
Message-ID: <AkOUUKdp3fGifCYiYAI83woE3AC1hFLrZ85osv-CC_8=.5e2b7ca1-543d-4356-9b32-8dabeb469906@github.com>

On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked 
>> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766)
>> 
>> We found the issue can be produced stably with at least 64 modules.
>> Note that we need to add the --date jmod option to avoid the timestamp issue.
>> 
>> Testing:
>> Added test case fails without fix for JDK-8240734, and passes otherwise.
>> Tested with tier2 on linux x86.
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8240903
>  - Delete extra blank links
>  - Change shell test io java test
>  - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z'
>  - Update Copyright
>  - 8240903: Add a regression test for JDK-8240734

Thanks for the timings. I mostly asked because we've had issues with I/O heavy tests on older macOS tests in our CI. Several tests have had to be dialled down or configured to run with very large timeouts. We'll have to see how this one fares.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From sminervini.prism at protonmail.com  Sun Apr 10 12:04:05 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Sun, 10 Apr 2022 12:04:05 +0000
Subject: Corretto Java Flexible Path to repair OpenJDK,
 Corretto Floating Point Arithmetic, StrictMath, bound classes and interfaces?
Message-ID: <YLeX-qnM7sqgF9bLbcsucfa3uAA2O6qjpPGITPhwAiuQZf-h97BmhqZBH4pvDfZPUOeH6MYMf5KebkeJFGtevQa2aaXthiiYuwS1Ib5-GRU=@protonmail.com>

To OpenJDK core-libs-dev,

I have been part way through a discussion with Amazon Web Services and Corretto on the subject
of a patch to mend OpenJDK's floating point woes. Particularly in a way which will leave
the option of mutual compatability. So far, they seem to take an initial view with their patching
of Java, and have directed us here.

As can be seen and has been outlined through all these discussion threads, it is the case that
IEEE 754 is incomplete in the area of floating point and base 10, and that the JRE can generate
denormal and pronormal values with float and double, which are really range errors.

We have seen a compatability option in the shape of Corretto Java, particularly with their
patching policy to enhance things. We have also thought that mutual compatibility means
no disadvantages, particularly if there were some way to use both approaches in the same
code space, such as a runtime switch would allow, since java can call itself from the command
line, at least.

We have tried to lay down the simplicity and requisite nature of this situation, for ourselves
and others, Java programmers and users, in the following:

https://github.com/corretto/corretto-18/issues/15
https://github.com/corretto/corretto-18/issues/17
https://github.com/corretto/corretto-18/issues/18
https://repost.aws/questions/QU8pXxczMPRdyGypZM2NNX2A/java-floating-point-correction-patch-in-corretto-in-a-compatible-manner
https://repost.aws/questions/QUBDoBC76zQ8KKLwP6UCc7Xg/compatability-enhancement-of-corretto-java-floating-point

Could something like a floating point patch be appropriate for the Corretto space for Java, were
it mutually compatible and efficient, for stable relase versions of Open versions of Java, upcoming
and continuing to the future?

S.M.

From duke at openjdk.java.net  Sun Apr 10 14:33:45 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 10 Apr 2022 14:33:45 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <bSwHPwZ5FZ3nDUn3OgdQEAB8Kof0EaItur4g8i01nNc=.83408b57-5125-4ab2-9309-5b3c463d486b@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

Please keep this PR open; I will continune work on it soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6935

From alanb at openjdk.java.net  Sun Apr 10 15:52:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 10 Apr 2022 15:52:42 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v3]
In-Reply-To: <jLHgNoNagUpcCG3HjnYvw2gHk6t8hV_M6tNRxK5SyAA=.cbc5923b-06f6-44ab-bd24-888fe7419620@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <jLHgNoNagUpcCG3HjnYvw2gHk6t8hV_M6tNRxK5SyAA=.cbc5923b-06f6-44ab-bd24-888fe7419620@github.com>
Message-ID: <ZYMy3JTiuXtcu9156X7ZySHkKDrp0acbYZUnMlXoSRI=.f4b4850d-ee42-4701-9821-b3262f37fb37@github.com>

On Thu, 7 Apr 2022 21:08:34 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert Module::isOpen

The updated changes to Class and Module in 912896d7 look okay, just minor comments.

src/java.base/share/classes/java/lang/Class.java line 3007:

> 3005:                 if (callerModule == null) {
> 3006:                     // no caller
> 3007:                     return thisModule.isOpen(pn);

It might be clear if the comment read "no caller, return true if the package is open to all modules".

src/java.base/share/classes/java/lang/Module.java line 1658:

> 1656:                 if (getPackages().contains(pn)) {
> 1657:                     if (caller == null) {
> 1658:                         if (! isOpen(pn)) {

Minor nit, can you remove the space in "! isOpen".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From duke at openjdk.java.net  Sun Apr 10 17:36:28 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sun, 10 Apr 2022 17:36:28 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v13]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <ooFlwRDFqsCzjxquh3fxwR0yUI6YA0y4SgtGsu0lhPw=.adfd2ffc-cc9e-458c-bb96-9939e8922dba@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  variable nameToReferenceSize rename to moduleCount

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/b973ee51..bdf47f32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=11-12

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sun Apr 10 17:36:29 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sun, 10 Apr 2022 17:36:29 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v12]
In-Reply-To: <QyeTEl09tn_MZVuM_G9EOCCCS8F23STGSM5NTA864Us=.58f46ebb-f407-49cd-92f8-6a37679b36c3@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <T_LamGhgJaUud9Id6eoRKA8fjucAyOmjTw4WOuLpcBk=.cf428921-6cc2-4355-a3f3-308e2880615d@github.com>
 <QyeTEl09tn_MZVuM_G9EOCCCS8F23STGSM5NTA864Us=.58f46ebb-f407-49cd-92f8-6a37679b36c3@github.com>
Message-ID: <mxxzd0_N6t7PbeA8k1SaPXD07HhokTahTARmTwsH1rQ=.55846bfa-7f4e-48c5-a229-bc2fc8c8555e@github.com>

On Sun, 10 Apr 2022 07:41:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use (double) DEFAULT_LOAD_FACTOR instead of 0.75
>
> src/java.base/share/classes/java/lang/module/Resolver.java line 501:
> 
>> 499:     private Map<ResolvedModule, Set<ResolvedModule>> makeGraph(Configuration cf) {
>> 500: 
>> 501:         int nameToReferenceSize = nameToReference.size();
> 
> This can be renamed moduleCount to make it easier to read.

@AlanBateman done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Sun Apr 10 20:28:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sun, 10 Apr 2022 20:28:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v14]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <thTYaib7qsUcjKYs7x6wI4EiKMJYRxT5bqOECcmy9oo=.710d8143-7fc6-4cfa-a07d-04e98b341d58@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into fix_8186958
 - variable nameToReferenceSize rename to moduleCount
 - use (double) DEFAULT_LOAD_FACTOR instead of 0.75
 - drop CalculateHashMapCapacityTestJMH
 - refine javadoc for LinkedHashMap#newLinkedHashMap
 - revert changes in jdk.compile
 - update usages of LinkedHashMap
 - update usages of HashMap
 - update codes
 - update jmh
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/34914f12...7adc89c1

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7928/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=13
  Stats: 139 lines in 50 files changed: 61 ins; 3 del; 75 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From ihse at openjdk.java.net  Sun Apr 10 22:18:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Sun, 10 Apr 2022 22:18:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <ecI0GAEiFeML4xj1-_wKbwo3XaBVK0QytGi3TKC27bA=.389e7fd1-b755-4750-b5bc-4d293f08814a@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81:

> 79:         Constructor<?> ctor;
> 80:         try {
> 81:             Class<?> exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException");

Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Mon Apr 11 00:48:34 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Mon, 11 Apr 2022 00:48:34 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v4]
In-Reply-To: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
Message-ID: <umlvS44m5FhXPyOycZmzTiVMnqGJDZT3kDEZoljFC2Q=.5eeca768-553d-4c48-8afe-3d4bb9bf7394@github.com>

> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
> 
> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
> 
> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  requested changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/912896d7..c5fef46b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134

From jpai at openjdk.java.net  Mon Apr 11 01:27:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 11 Apr 2022 01:27:45 GMT
Subject: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed
 hierarchy
In-Reply-To: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
References: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
Message-ID: <4ehToxCRD4VRMBIADFJ6renBf_Ni4dxp8kIJpe3FRls=.4be875ef-5221-4bf8-a542-0ac6dd175772@github.com>

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which now marks `CollectionView` as a `sealed` class with only `EntrySetView`, `KeySetView` and  `ValuesView` as the sub-classes? This change corresponds to https://bugs.openjdk.java.net/browse/JDK-8284036.
> 
> A CSR has also been drafted for this change https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, marking this class as `sealed` and marking `KeySetView` as `final` shouldn't have any impact in general and also in context of serialization/de-serialization.
> 
> tier1, tier2, tier3 tests have been run successfully with this change.

Thank you Doug and Stuart for considering this change and the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8085

From jpai at openjdk.java.net  Mon Apr 11 01:27:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 11 Apr 2022 01:27:45 GMT
Subject: Integrated: 8284036: Make ConcurrentHashMap.CollectionView a sealed
 hierarchy
In-Reply-To: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
References: <7ivrKlOxryJwlzwJFt0rXTg-5bPJz7GL4COWQnhsC5g=.e3efe869-ea9f-4ee6-b7e0-a055ce206c80@github.com>
Message-ID: <HEub7DYOfjRQrEEoLMeqnNj3-3rNIzogs9u_beCvST4=.36c0222f-3f8f-4aee-b498-fc49f32f07a8@github.com>

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which now marks `CollectionView` as a `sealed` class with only `EntrySetView`, `KeySetView` and  `ValuesView` as the sub-classes? This change corresponds to https://bugs.openjdk.java.net/browse/JDK-8284036.
> 
> A CSR has also been drafted for this change https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, marking this class as `sealed` and marking `KeySetView` as `final` shouldn't have any impact in general and also in context of serialization/de-serialization.
> 
> tier1, tier2, tier3 tests have been run successfully with this change.

This pull request has now been integrated.

Changeset: eb3ead96
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb3ead96b300b05ddc709a1aa9dd03f664539697
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8284036: Make ConcurrentHashMap.CollectionView a sealed hierarchy

Reviewed-by: smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8085

From dholmes at openjdk.java.net  Mon Apr 11 02:04:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 11 Apr 2022 02:04:47 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
Message-ID: <rtrdDSjyrM-o0avltPqmRRG_4OgNVjnPf0XnkZ6iWjY=.27930660-59b5-4038-8fab-d0de562d07cc@github.com>

On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the divmod crash due to lack of control node

This change appears to be causing crashes in tier4 - possibly Xcomp related:

#  assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out

I will file a new bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From dholmes at openjdk.java.net  Mon Apr 11 05:01:40 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 11 Apr 2022 05:01:40 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <zkXkOwbfxSPi7G6BjX3QZDYrAdkLaG5Cpshqqx81274=.01ca72c4-443d-4d6f-b212-f413b1562494@github.com>

On Fri, 8 Apr 2022 12:20:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

`checkExactAccessModeThenIsDirect`?

At a minimum the return value needs documenting via a comment!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Mon Apr 11 05:24:41 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Mon, 11 Apr 2022 05:24:41 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <rtrdDSjyrM-o0avltPqmRRG_4OgNVjnPf0XnkZ6iWjY=.27930660-59b5-4038-8fab-d0de562d07cc@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
 <rtrdDSjyrM-o0avltPqmRRG_4OgNVjnPf0XnkZ6iWjY=.27930660-59b5-4038-8fab-d0de562d07cc@github.com>
Message-ID: <LsSvIsQlWp9zj5rLC-6M42DoPiWi3AzLmP5CqVtvSTo=.a3eb0a5b-4876-44fa-a1d8-589fddbd2569@github.com>

On Mon, 11 Apr 2022 02:01:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This change appears to be causing crashes in tier4 - possibly Xcomp related:
> 
> # assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
> I will file a new bug.

Thank you for informing this issue! In order to reproduce the issue, I just kickstarted a tier4 run on a Xeon server. Will  keep you updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From ksakata at openjdk.java.net  Mon Apr 11 05:39:11 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Mon, 11 Apr 2022 05:39:11 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale is
 ja or zh_CN
Message-ID: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>

# Summary
Running jdeprscan with --help option causes an exception on any OSs when the locale is ja or zh_CN.

# How to reproduce this issue

$ jdeprscan -J-Duser.language=ja --help
Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
        at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
        at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
        at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
        at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
        at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
        at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
        at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
        at java.base/java.lang.Integer.parseInt(Integer.java:668)
        at java.base/java.lang.Integer.parseInt(Integer.java:786)
        at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
        ... 8 more

$ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
?Same as above?

Of course, it works well when the locale is anything other than those locales.

# Details
I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 

I removed extra single quotes.

# Test
It seems there is no test class for it. So I run commands as I mentioned before.

$ jdeprscan -J-Duser.language=ja --help
????: jdeprscan [options] {dir|jar|class} ...

?????:
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

???API????????????????????????
???????????????????????JAR?????
?????????????????????????????
???????????????????????????????
????$????????:

    java.lang.Thread$State

--class-path?????????????????????
???????????

--for-removal??????????????????????????API?
????????????6?7???8????????????

--full-version????????????????????????????

--help (-? -h)?????????????????????????

--list (-l)?????????API???????????????????????
???????JAR??????????????????????

--release????????????????API?????????Java SE
???????????

--verbose (-v)????????????????????????????????

--version????????????????????????????????

$ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
???jdeprscan [options] {dir|jar|class} ...

???
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

????????????????? API?
???????????????JAR ???
????????????????
????????????? $ ???
?????????

    java.lang.Thread$State

--class-path ?????????????
?????

--for-removal ????????????????
? API???????? 6?7 ? 8 ?????

--full-version ???????????????

--help (-? -h) ????????????

--list (-l) ?????????? API???????
???????????jar ?????

--release ????????????? API ?
? Java SE ????

--verbose (-v) ????????????????

--version ???????????????

$ jdeprscan -J-Duser.language=en --help                    
Usage: jdeprscan [options] {dir|jar|class} ...

options:
        --class-path PATH
        --for-removal
        --full-version
  -? -h --help
  -l    --list
        --release 7|8|9|10|11|12|13|14|15|16|17|18|19
  -v    --verbose
        --version

Scans each argument for usages of deprecated APIs. An argument
may be a directory specifying the root of a package hierarchy,
a JAR file, a class file, or a class name. The class name must be
specified using a fully qualified class name using the $ separator
character for nested classes, for example,

    java.lang.Thread$State

The --class-path option provides a search path for resolution
of dependent classes.

The --for-removal option limits scanning or listing to APIs that are
deprecated for removal. Cannot be used with a release value of 6, 7, or 8.

The --full-version option prints out the full version string of the tool.

The --help (-? -h) option prints out a full help message.

The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
so no directory, jar, or class arguments should be provided.

The --release option specifies the Java SE release that provides the set
of deprecated APIs for scanning.

The --verbose (-v) option enables additional message output during processing.

The --version option prints out the abbreviated version string of the tool.

-------------

Commit messages:
 - Remove unnecessary single quotes

Changes: https://git.openjdk.java.net/jdk/pull/8174/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8174&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283870
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8174.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8174/head:pull/8174

PR: https://git.openjdk.java.net/jdk/pull/8174

From thartmann at openjdk.java.net  Mon Apr 11 06:30:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 11 Apr 2022 06:30:45 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13]
In-Reply-To: <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <mxL3ezh2sc6i-QPfQtAgG09tk60e4dMklaHGlocvggo=.5ceb391e-9de7-4ecb-a03b-a73b499c4353@github.com>
Message-ID: <wFVa64QX_Ee4a9qYjr39gLOYxOOjAFSrPIBfPDO7_dA=.42702b64-f70b-40cb-beb3-2fc655bf49da@github.com>

On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the divmod crash due to lack of control node

The issue is easy to reproduce, see [JDK-8284635](https://bugs.openjdk.java.net/browse/JDK-8284635).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From alanb at openjdk.java.net  Mon Apr 11 07:16:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Apr 2022 07:16:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <cbYr7VF9Pw9AafplmrUErxAOTnteynJeEBxOeXGjSyA=.8e5b5b40-fd6a-461b-ab70-34dbcac19812@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <cbYr7VF9Pw9AafplmrUErxAOTnteynJeEBxOeXGjSyA=.8e5b5b40-fd6a-461b-ab70-34dbcac19812@github.com>
Message-ID: <nyHgWbknIvVh0j-xgrjYfgQV4GbUL8dTI7wfmd6oAEc=.c0ff8226-76f1-4356-b6a7-5309233f6f3b@github.com>

On Sun, 10 Apr 2022 00:40:02 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> This?is?supposed to?point to?the?`package?summary.html` 

Thanks, this link is indeed wrong. Will be fixed when we refresh.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon Apr 11 07:16:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Apr 2022 07:16:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <ecI0GAEiFeML4xj1-_wKbwo3XaBVK0QytGi3TKC27bA=.389e7fd1-b755-4750-b5bc-4d293f08814a@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <ecI0GAEiFeML4xj1-_wKbwo3XaBVK0QytGi3TKC27bA=.389e7fd1-b755-4750-b5bc-4d293f08814a@github.com>
Message-ID: <u_46G21Q-lL7lZYcCo-GWcZhgoZo-PcpW7TdIp7_XaI=.a3300291-85e8-418f-9edd-d148862f876b@github.com>

On Sun, 10 Apr 2022 22:14:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...)

The exception is in an incubator module, it's just that code in java.base can't statically reference it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Mon Apr 11 07:36:47 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 11 Apr 2022 07:36:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <u_46G21Q-lL7lZYcCo-GWcZhgoZo-PcpW7TdIp7_XaI=.a3300291-85e8-418f-9edd-d148862f876b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <ecI0GAEiFeML4xj1-_wKbwo3XaBVK0QytGi3TKC27bA=.389e7fd1-b755-4750-b5bc-4d293f08814a@github.com>
 <u_46G21Q-lL7lZYcCo-GWcZhgoZo-PcpW7TdIp7_XaI=.a3300291-85e8-418f-9edd-d148862f876b@github.com>
Message-ID: <Kq6qEX2oehNO1CxdHuag4U5ItIVwqtaFqudsxJmDPTA=.1d3810d7-92e1-46f1-ab63-db449f4e1323@github.com>

On Mon, 11 Apr 2022 07:12:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81:
>> 
>>> 79:         Constructor<?> ctor;
>>> 80:         try {
>>> 81:             Class<?> exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException");
>> 
>> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...)
>
>> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...)
> 
> The exception is in an incubator module, it's just that code in java.base can't statically reference it.

Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`).

It?should?probably also?be?cached.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon Apr 11 07:43:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Apr 2022 07:43:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <Kq6qEX2oehNO1CxdHuag4U5ItIVwqtaFqudsxJmDPTA=.1d3810d7-92e1-46f1-ab63-db449f4e1323@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <ecI0GAEiFeML4xj1-_wKbwo3XaBVK0QytGi3TKC27bA=.389e7fd1-b755-4750-b5bc-4d293f08814a@github.com>
 <u_46G21Q-lL7lZYcCo-GWcZhgoZo-PcpW7TdIp7_XaI=.a3300291-85e8-418f-9edd-d148862f876b@github.com>
 <Kq6qEX2oehNO1CxdHuag4U5ItIVwqtaFqudsxJmDPTA=.1d3810d7-92e1-46f1-ab63-db449f4e1323@github.com>
Message-ID: <Rc3QN0VbjalIXJrb_3FPMaG5_Ne3BnynJymDBtD7ElE=.8c67013a-a45c-4814-87a3-a9944d31f9fe@github.com>

On Mon, 11 Apr 2022 07:33:20 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`).
> 
> It?should?probably also?be?cached.

It is cached. It's also a very exceptional case that only arises when the SC API (separate JEP, not here) is used incorrectly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon Apr 11 08:20:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Apr 2022 08:20:46 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v4]
In-Reply-To: <umlvS44m5FhXPyOycZmzTiVMnqGJDZT3kDEZoljFC2Q=.5eeca768-553d-4c48-8afe-3d4bb9bf7394@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <umlvS44m5FhXPyOycZmzTiVMnqGJDZT3kDEZoljFC2Q=.5eeca768-553d-4c48-8afe-3d4bb9bf7394@github.com>
Message-ID: <Ukx08HsU3PBZqQj5f1Ktl6OxnV3p4ixKpJXxnDjuwpk=.344a673e-d5af-4fa4-afbc-bb1a21936e05@github.com>

On Mon, 11 Apr 2022 00:48:34 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requested changes

Thanks for the update, the src changes in c5fef46b look okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From jbhateja at openjdk.java.net  Mon Apr 11 09:08:41 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 11 Apr 2022 09:08:41 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature
In-Reply-To: <ObTJCUgfcC_HWOapui4POW4nfZ5WljmJtSQaKewL21U=.d4591ddf-0dbe-42b3-99fe-0faf376eaf08@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <qGT_pT7bJXtmGLdET7zfdn61OCP6K0qO3druyXapADc=.86ab137e-49d0-437c-ae54-90370c270ef6@github.com>
 <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com>
 <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com>
 <kqI-nPVHEWDVrqR16zP0gvSnLZJZhyFAmJ4maHvqqD8=.fec2585b-9785-478c-aa1c-5e80f320863c@github.com>
 <ObTJCUgfcC_HWOapui4POW4nfZ5WljmJtSQaKewL21U=.d4591ddf-0dbe-42b3-99fe-0faf376eaf08@github.com>
Message-ID: <CFDqLPf7iBeKTwj_20Imdqm1RbxqV8CA7rgtMZLvkfk=.d5c9224e-e3a3-4db6-b22b-e5b9c873ae26@github.com>

On Thu, 31 Mar 2022 03:53:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yeah, maybe I misunderstood what you mean. So maybe the masked store `(store(src, m))` could be implemented with:
>> 
>> 1) v1 = load
>> 2) v2 = blend(load, src, m)
>> 3) store(v2)
>> 
>> Let's record this a JBS and fix it with a followed-up patch. Thanks!
>
> The optimization for masked store is recorded to: https://bugs.openjdk.java.net/browse/JDK-8284050

> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values.

It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary.  Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From aturbanov at openjdk.java.net  Mon Apr 11 09:35:38 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Apr 2022 09:35:38 GMT
Subject: Integrated: 8284567: Collapse identical catch branches in java.base
In-Reply-To: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
References: <cQLvs_ehxADUnIy4r8BZVK78GNReLTUTv3cFGriLo4w=.2dfbd513-3bd6-44f3-8be9-6a0153e3633f@github.com>
Message-ID: <QZPXev-Im3iBYRvb1MFCkTeo3k078Tdx6S1pIxifNMc=.f75c57d4-624c-48f8-ba55-af1061f32b06@github.com>

On Sat, 2 Apr 2022 16:05:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement

This pull request has now been integrated.

Changeset: f4edb59a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4edb59a6e44d99ba215ee6970ffa6fb26b4798c
Stats:     106 lines in 17 files changed: 0 ins; 60 del; 46 mod

8284567: Collapse identical catch branches in java.base

Reviewed-by: darcy, iris, wetmore

-------------

PR: https://git.openjdk.java.net/jdk/pull/8081

From duke at openjdk.java.net  Mon Apr 11 09:45:45 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 11 Apr 2022 09:45:45 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
Message-ID: <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>

On Fri, 8 Apr 2022 12:20:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified as suggested by @ExE-Boss

How?would the?performance?change if?the?`isDirect` and?`checkExactAccessMode` merger?was?reverted?

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2075:

> 2073: 
> 2074:     @DontInline
> 2075:     final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {

This?can?actually be?`private` and?`static`:
Suggestion:

    private static final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 719:

> 717: //                        MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
> 718: //                    } else {
> 719: //                        MethodHandle mh = handle.getMethodHandle(ad.mode);

The?`direct`?ness?check can?be?hoisted into?an?enclosing `if`?statement:
Suggestion:

//                    if (direct) {
//                        if (handle.vform.methodType_table[ad.type] == ad.symbolicMethodTypeErased) {
//                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
//                            return;
//                        } else if (handle.vform.getMethodType_V(ad.type) == ad.symbolicMethodTypeErased) {
//                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
//                            return;
//                        }
//                    }
//                    MethodHandle mh = handle.getMethodHandle(ad.mode);


Also, any?reason `GUARD_METHOD_TEMPLATE_V` uses `LINK_TO_STATIC_ARGS` instead of?`LINK_TO_STATIC_ARGS_V`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Mon Apr 11 09:56:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 11 Apr 2022 09:56:32 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
Message-ID: <wB4ZBegNKzbnjPXARstWmoHr5LxBTyHmQ2PORTI8uHc=.4378a615-67cc-45aa-9749-980f3167674b@github.com>

On Mon, 11 Apr 2022 09:26:12 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified as suggested by @ExE-Boss
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2075:
> 
>> 2073: 
>> 2074:     @DontInline
>> 2075:     final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {
> 
> This?can?actually be?`private` and?`static`:
> Suggestion:
> 
>     private static final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {

`private` yes. `static` would require to pass the `MethodType` and since this is an exceptional slow-path it doesn't make sense to keep the complexity contained inside the `throw...` method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Mon Apr 11 10:00:46 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 11 Apr 2022 10:00:46 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
Message-ID: <p0ZnGW6Q4B2AwIEJlM21jKJz03dx6WD7OPYnOr8BH3A=.f177c5c2-cfc4-4896-b74e-23cf4583c2dc@github.com>

On Mon, 11 Apr 2022 09:34:17 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified as suggested by @ExE-Boss
>
> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 719:
> 
>> 717: //                        MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
>> 718: //                    } else {
>> 719: //                        MethodHandle mh = handle.getMethodHandle(ad.mode);
> 
> The?`direct`?ness?check can?be?hoisted into?an?enclosing `if`?statement:
> Suggestion:
> 
> //                    if (direct) {
> //                        if (handle.vform.methodType_table[ad.type] == ad.symbolicMethodTypeErased) {
> //                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
> //                            return;
> //                        } else if (handle.vform.getMethodType_V(ad.type) == ad.symbolicMethodTypeErased) {
> //                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
> //                            return;
> //                        }
> //                    }
> //                    MethodHandle mh = handle.getMethodHandle(ad.mode);
> 
> 
> Also, any?reason `GUARD_METHOD_TEMPLATE_V` uses `LINK_TO_STATIC_ARGS` instead of?`LINK_TO_STATIC_ARGS_V`?

> How would the performance change if the `isDirect` and `checkExactAccessMode` merger was reverted?

Add around 15-20ns/op for these micros.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Mon Apr 11 10:07:39 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 11 Apr 2022 10:07:39 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <wB4ZBegNKzbnjPXARstWmoHr5LxBTyHmQ2PORTI8uHc=.4378a615-67cc-45aa-9749-980f3167674b@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
 <wB4ZBegNKzbnjPXARstWmoHr5LxBTyHmQ2PORTI8uHc=.4378a615-67cc-45aa-9749-980f3167674b@github.com>
Message-ID: <SZtrLDF7bUAydol0IMypKLoXvnYdhiO0O7wo4ABwi-E=.6fbfa135-4d5c-444a-a005-e34f15ff82e5@github.com>

On Mon, 11 Apr 2022 09:53:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2075:
>> 
>>> 2073: 
>>> 2074:     @DontInline
>>> 2075:     final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {
>> 
>> This?can?actually be?`private` ~~and?`static`~~:
>> Suggestion:
>> 
>>     private final void throwWrongMethodTypeException(VarHandle.AccessDescriptor ad) {
>
> `private` yes. `static` would require to pass the `MethodType` and since this is an exceptional slow-path it doesn't make sense to keep the complexity contained inside the `throw...` method.

Right, I?missed the?`accessModeType(?)`?call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Mon Apr 11 10:07:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 11 Apr 2022 10:07:40 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <p0ZnGW6Q4B2AwIEJlM21jKJz03dx6WD7OPYnOr8BH3A=.f177c5c2-cfc4-4896-b74e-23cf4583c2dc@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
 <p0ZnGW6Q4B2AwIEJlM21jKJz03dx6WD7OPYnOr8BH3A=.f177c5c2-cfc4-4896-b74e-23cf4583c2dc@github.com>
Message-ID: <82JZ4zL99-H0sVYCFto978Owri1920TjBcVnntJNQXY=.265e05ab-725e-41a8-a154-b22527083487@github.com>

On Mon, 11 Apr 2022 09:57:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 719:
>> 
>>> 717: //                        MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
>>> 718: //                    } else {
>>> 719: //                        MethodHandle mh = handle.getMethodHandle(ad.mode);
>> 
>> The?`direct`?ness?check can?be?hoisted into?an?enclosing `if`?statement:
>> Suggestion:
>> 
>> //                    if (direct) {
>> //                        if (handle.vform.methodType_table[ad.type] == ad.symbolicMethodTypeErased) {
>> //                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
>> //                            return;
>> //                        } else if (handle.vform.getMethodType_V(ad.type) == ad.symbolicMethodTypeErased) {
>> //                            MethodHandle.linkToStatic(<LINK_TO_STATIC_ARGS>);
>> //                            return;
>> //                        }
>> //                    }
>> //                    MethodHandle mh = handle.getMethodHandle(ad.mode);
>> 
>> 
>> Also, any?reason `GUARD_METHOD_TEMPLATE_V` uses `LINK_TO_STATIC_ARGS` instead of?`LINK_TO_STATIC_ARGS_V`?
>
>> How would the performance change if the `isDirect` and `checkExactAccessMode` merger was reverted?
> 
> Add around 15-20ns/op for these micros.

Restructuring so that we only check `direct` once sounds reasonable at face value but would be a lot of churn for little gain (even in the interpreter testing a local boolean field is fast, and JITs will optimize this well).

The `LINK_TO_STATIC_ARGS_V` in the code generator seems like a remnant from an earlier iteration of this code. The `vform.getMemberName_V` method the code generator would emit a call to doesn't even exist. This should probably be cleaned up, separately. @PaulSandoz, WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From redestad at openjdk.java.net  Mon Apr 11 10:13:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 11 Apr 2022 10:13:40 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v3]
In-Reply-To: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
Message-ID: <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>

> A few additional enhancements aiming to improve VH performance in the interpreter:
> 
> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
> 
> Baseline, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
> 
> 
> Patched, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
> 
> 
> No significant performance difference in normal mode.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  checkExactAccessMode -> checkAccessModeThenIsDirect, privatize throw method, cleanup code generator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8160/files
  - new: https://git.openjdk.java.net/jdk/pull/8160/files/68f414a1..2a4fbd6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=01-02

  Stats: 90 lines in 4 files changed: 0 ins; 5 del; 85 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8160.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8160/head:pull/8160

PR: https://git.openjdk.java.net/jdk/pull/8160

From simonis at openjdk.java.net  Mon Apr 11 10:17:43 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 11 Apr 2022 10:17:43 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <HV2d1hwa3E0bOuRD32sJIp7G8eqbl2OBcb6x4Pxrvk4=.9d25ebcd-3274-4af1-9091-422253a08c6b@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
 <HV2d1hwa3E0bOuRD32sJIp7G8eqbl2OBcb6x4Pxrvk4=.9d25ebcd-3274-4af1-9091-422253a08c6b@github.com>
Message-ID: <dVIbCeQrtht5isDCP8AoKwu2-OdiH4YBaAgOg-ygZik=.88e3f1cc-63dc-4303-8964-2eabb1e6e08c@github.com>

On Fri, 8 Apr 2022 13:11:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 346:
> 
>> 344:      * have been returned by invocations of this method.
>> 345:      *
>> 346:      * @implNote In the JDK implementation this method returns an
> 
> The "In the JDK implementation" sounds a bit odd to me. I looked around some other `@implNote`s and many of of them use `@implNote This implementation ....`, so perhaps we should change this to:
> ``` 
> @implNote This implementation returns an instance of {@link java.util.zip.InflaterInputStream}.

Thanks for the suggestion. I've updated to code accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From dholmes at openjdk.java.net  Mon Apr 11 10:40:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 11 Apr 2022 10:40:36 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v24]
In-Reply-To: <rG7Ur0DAsuWCr3mbmdCvY6qqcxLLDbwkd1EF1Eb0ARQ=.ff61030c-9095-4d6b-b07a-32a1571c386c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <rG7Ur0DAsuWCr3mbmdCvY6qqcxLLDbwkd1EF1Eb0ARQ=.ff61030c-9095-4d6b-b07a-32a1571c386c@github.com>
Message-ID: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com>

On Mon, 4 Apr 2022 14:57:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestLinkToNativeRBP

VM changes look good.

Thanks,
David

src/hotspot/share/prims/scopedMemoryAccess.cpp line 141:

> 139: 
> 140: /*
> 141:  * This function performs a thread-local handshake against all threads running at the time

Nit: thread-local??

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7888

From simonis at openjdk.java.net  Mon Apr 11 10:43:30 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 11 Apr 2022 10:43:30 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Adapted wording and copyrights based on @jaikiran review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/7c671aa5..1bf6bc1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=03-04

  Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Mon Apr 11 10:43:31 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 11 Apr 2022 10:43:31 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v4]
In-Reply-To: <49430xjrok70legiUEkzV6F2Uzn4e2y78R3uLdp3m1E=.315aa0eb-20f1-4b8e-a71a-823c770f25a6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <KXw-yDRthc56483kx7uneDQJD91uBKs2BTlUAhg02Us=.881db472-fe37-4295-af89-d314f4cef44d@github.com>
 <49430xjrok70legiUEkzV6F2Uzn4e2y78R3uLdp3m1E=.315aa0eb-20f1-4b8e-a71a-823c770f25a6@github.com>
Message-ID: <ecPu2eg_w8Zmd5p2EoNbJCIpYhiJphKp0r-T5Cxs6oo=.3bf3d678-e074-4e30-9df4-e0149f794d8e@github.com>

On Fri, 8 Apr 2022 13:21:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream()
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 173:
> 
>> 171:      * bytes are read and {@code 0} is returned.
>> 172:      * <p>
>> 173:      * If <i>n</i> denotes the returned number of inflated bytes then {@code b[off]}
> 
> I think this might need a slightly different wording since in this case of `ZipInputStream#read(...)`, the entry's  compression method decides whether or not an inflater will be used to return inflated bytes.
> 
> So maybe we should just remove the reference to "inflated bytes" and instead say:
> 
> * If <i>n</i> denotes the return value, then {@code b[off]} through {@code b[off+}<i>n</i>{@code -1]}
> * will contain the data that has been read. The elements {@code b[off+}<i>n</i>{@code ]} through 
> * {@code b[off+}<i>len</i>{@code -1]} are undefined and the implementation may update them during this read
> * operation. If the return value is -1 or an exception is thrown the whole content of {@code b} is undefined.

Thanks for spotting this. As the restriction only applies to compressed entries, I've simply prefixed the text with "*If the current entry is compressed and..*"

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From tschatzl at openjdk.java.net  Mon Apr 11 10:48:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 11 Apr 2022 10:48:34 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v2]
In-Reply-To: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
Message-ID: <Ci-z3Fm2EesrJSK6amX7FHWO-miEa7tIuWN8o_04jmI=.e2437777-3ad0-45cd-93de-31f177cdb58e@github.com>

> Hi all,
> 
>   can I have reviews for this change that adds dedicated filler objects to the VM?
> 
> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
> 
> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
> 
> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
> 
> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
> 
> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
> 
> This has the following benefits:
> 
> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
> 
> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
> 
> This causes some minor changes to external behavior:
> 
> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
> 
> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
> 
> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
> 
> 
> Testing: tier1-8
> 
> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
> 
> Thanks go to @iklam for helping out with the change.
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - iklam review
 - Test case

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8156/files
  - new: https://git.openjdk.java.net/jdk/pull/8156/files/9cee3295..b3e2c6c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=00-01

  Stats: 54 lines in 2 files changed: 53 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8156.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156

PR: https://git.openjdk.java.net/jdk/pull/8156

From tschatzl at openjdk.java.net  Mon Apr 11 10:48:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 11 Apr 2022 10:48:35 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v2]
In-Reply-To: <Fpjxjy5khDddqgZ0XLt54FYoxRvKBiLu3Vpr_WkCubg=.c213f934-a419-4c7e-a563-689e88adf8cd@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <Fpjxjy5khDddqgZ0XLt54FYoxRvKBiLu3Vpr_WkCubg=.c213f934-a419-4c7e-a563-689e88adf8cd@github.com>
Message-ID: <-NcmZgItAp7e1O6-7x25Zm_0_DjptadNlAxFtr9KiU4=.7fdcf257-ece4-4a83-b433-198bfd547ab6@github.com>

On Fri, 8 Apr 2022 16:45:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - iklam review
>>  - Test case
>
> src/hotspot/share/classfile/systemDictionaryShared.cpp line 1727:
> 
>> 1725:     ArchivedMirrorPatcher::update_array_klasses(k);
>> 1726:   }
>> 1727:   ArchivedMirrorPatcher::update_array_klasses(Universe::fillerArrayKlassObj());
> 
> I think this is not necessary. `Universe::fillerArrayKlassObj()` shares the same mirror as `Universe::intArrayKlassObj()`, which has already been updated in the loop above.
> 
> `ArchivedMirrorPatcher::update_array_klasses(k)` will essentially do `k->mirror->pointer_back_to_klass += delta`, so it will incorrectly set the pointer when delta is not zero.
> 
> I would suggest running with
> 
> 
> -XX:ArchiveRelocationMode=1 -Xlog:cds -Xlog:class+load=debug
> 
> 
> and step into the following code: 
> 
> 
> void java_lang_Class::update_archived_mirror_native_pointers(oop archived_mirror) {
>   assert(MetaspaceShared::relocation_delta() != 0, "must be");
> 
>   Klass* k = ((Klass*)archived_mirror->metadata_field(_klass_offset));
>   archived_mirror->metadata_field_put(_klass_offset,
>       (Klass*)(address(k) + MetaspaceShared::relocation_delta())); <<<< HERE

Stepping into that code (well, I added some logging) indicated that the mirrors for these klasses (`_fillerArrayKlassObj` and `intArrayKlassObj`) are different, so the field is not updated multiple times. So this code seems required, also because there are lots of crashes when removing the `ArchivedMirrorPatcher::update_array_klasses` call.

(Say, if you print the `java_mirror()` after Universe initialization)

The problem with the compiler we had (which was resolved by initializing the filler array before the int-array) was that in the component mirror, there is a reference to the arrayklass that represents an array of that basic type.
So as the code earlier initialized the filler array klass after the int array klass, the compiler used the filler array klass for array instantiation which tests did not like.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8156

From mcimadamore at openjdk.java.net  Mon Apr 11 12:07:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 11 Apr 2022 12:07:34 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v24]
In-Reply-To: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <rG7Ur0DAsuWCr3mbmdCvY6qqcxLLDbwkd1EF1Eb0ARQ=.ff61030c-9095-4d6b-b07a-32a1571c386c@github.com>
 <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com>
Message-ID: <K6hQdB8OYNj6N87F-0V4L8pJrcGGYi0V6V2mR0m3ptk=.b1fc2800-7e2d-4b3d-80f6-4341c4d38c4f@github.com>

On Mon, 11 Apr 2022 10:33:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix TestLinkToNativeRBP
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 141:
> 
>> 139: 
>> 140: /*
>> 141:  * This function performs a thread-local handshake against all threads running at the time
> 
> Nit: thread-local??

I was assuming the term "thread-local handshake" was a thing in the VM, as per:
https://openjdk.java.net/jeps/312

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From jlaskey at openjdk.java.net  Mon Apr 11 12:32:26 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 11 Apr 2022 12:32:26 GMT
Subject: RFR: JDK-8283084 RandomGenerator nextDouble(double,
 double) is documented incorrectly [v2]
In-Reply-To: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
References: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
Message-ID: <E2sgDuukpYw74a6iGktcQqPYkvniP2P6I9YGag6B61g=.68b8c507-4e58-4e31-acb2-6f703cd1792e@github.com>

> `default float nextFloat(float origin, float bound); ` and `default double nextDouble(double origin, double bound); ` are documented incorrectly. The default method checks (origin < bound) and (bound - origin) < +infinity. 
> 
> The exception conditions are incorrect: 
> "if {@code origin} is not finite, 
>  or {@code bound} is not finite, or {@code origin} 
>  is greater than or equal to {@code bound}" 
> 
> This is not true. Calling with -Double.MAX_VALUE and Double.MAX_VALUE satisfies the documented requirements but actually throws an exception.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add between

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8109/files
  - new: https://git.openjdk.java.net/jdk/pull/8109/files/4ab6a0fd..8717dd2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8109&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8109&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8109.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8109/head:pull/8109

PR: https://git.openjdk.java.net/jdk/pull/8109

From dfuchs at openjdk.java.net  Mon Apr 11 13:46:34 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 11 Apr 2022 13:46:34 GMT
Subject: Integrated: 8283719: java/util/logging/CheckZombieLockTest.java
 failing intermittently
In-Reply-To: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
References: <CZaU_-685Qdqj-Ev-bwBzpstor2LLTCRBSILhfG9Hx4=.4b7faa4e-799d-4ba6-8927-d36c5897d1eb@github.com>
Message-ID: <VzdX28th6vJEqE-ns7E53UOQBHcUUESz8U5Sr_gphpg=.995436db-e7f2-4b67-9904-976909eacefc@github.com>

On Fri, 8 Apr 2022 16:37:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find enclosed a patch for 
> `8283719: java/util/logging/CheckZombieLockTest.java failing intermittently`
> 
> My analysis is that the test fails intermittently because the `FileChannel` created by the test is garbage collected too early, which releases the associated lock before the `FileHandler` is created.
> I have replaced the `try { } finally { }` with a `try-with-resource( ) { } finally { }` which will prevent the `FileChannel` from being released before the end of the block. Additional bonus: this should also help with the code that tries to cleanup the files at the end.
> 
> Though I haven't been able to reproduce the exact failure yet, I haven't observed the new version of the test failing either.

This pull request has now been integrated.

Changeset: 74835f73
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74835f73893976c162ef5a441f0cfec16eb8706f
Stats:     16 lines in 1 file changed: 3 ins; 6 del; 7 mod

8283719: java/util/logging/CheckZombieLockTest.java failing intermittently

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8168

From tschatzl at openjdk.java.net  Mon Apr 11 14:55:32 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 11 Apr 2022 14:55:32 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
Message-ID: <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>

> Hi all,
> 
>   can I have reviews for this change that adds dedicated filler objects to the VM?
> 
> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
> 
> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
> 
> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
> 
> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
> 
> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
> 
> This has the following benefits:
> 
> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
> 
> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
> 
> This causes some minor changes to external behavior:
> 
> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
> 
> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
> 
> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
> 
> 
> Testing: tier1-8
> 
> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
> 
> Thanks go to @iklam for helping out with the change.
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Fix test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8156/files
  - new: https://git.openjdk.java.net/jdk/pull/8156/files/b3e2c6c3..effb9cd5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8156.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156

PR: https://git.openjdk.java.net/jdk/pull/8156

From psandoz at openjdk.java.net  Mon Apr 11 15:50:31 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 11 Apr 2022 15:50:31 GMT
Subject: RFR: 8283892: Compress and expand bits [v7]
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <Q8KblzEPiDdVs6IpItABZgT2b97P0JRWXBo1svVFP1Q=.3ec133d0-1868-4833-9a60-8afd5b755f06@github.com>

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  JavaDoc typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8115/files
  - new: https://git.openjdk.java.net/jdk/pull/8115/files/f9b7b2bc..8a52eabe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8115&range=05-06

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115

PR: https://git.openjdk.java.net/jdk/pull/8115

From naoto at openjdk.java.net  Mon Apr 11 16:03:05 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Apr 2022 16:03:05 GMT
Subject: Integrated: 8265315: Support for CLDR version 41
In-Reply-To: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
References: <DdB7YQOFJp1B0h88tRTN5OWj-Qyz1ZCwFISfTzdaovE=.f3698328-3053-4d6f-a5ed-30cf2e06c531@github.com>
Message-ID: <Ybqst1jl7a8jNbbEev6lBmYPf3eYrdluoDcyv5ix35c=.12742c7f-398e-4d1c-bd48-a867835fb355@github.com>

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41

This pull request has now been integrated.

Changeset: 523899e3
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/523899e36c543343283ab0b1f5cfcba805e7b918
Stats:     132400 lines in 859 files changed: 96406 ins; 4216 del; 31778 mod

8265315: Support for CLDR version 41

Reviewed-by: joehw, iris, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/8150

From alanb at openjdk.java.net  Mon Apr 11 16:10:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Apr 2022 16:10:42 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
Message-ID: <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>

On Mon, 11 Apr 2022 10:43:30 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapted wording and copyrights based on @jaikiran review

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 103:

> 101:      * elements {@code buf[off+}<i>n</i>{@code ]} through {@code buf[off+}<i>len</i>{@code -1]}
> 102:      * are undefined and an implementation is free to change them during the inflate
> 103:      * operation. If the return value is -1 or an exception is thrown the whole

The sentence is very long. How about putting "an implementation is free ..." in parentheses after "undefined".

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 104:

> 102:      * are undefined and an implementation is free to change them during the inflate
> 103:      * operation. If the return value is -1 or an exception is thrown the whole
> 104:      * content of {@code buf} is undefined.

"whole content" doesn't seem right, it should be buf[off] to but[off + len - 1] is undefined.

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 110:

> 108:      * @param len the maximum number of bytes read
> 109:      * @return  the actual number of bytes read, or -1 if the end of the
> 110:      *          compressed input stream is reached

We should probably adjust the `@return` description, as was done for InflaterInputStream, otherwise the method. description will say "the returning number of inflated bytes" and the return description will say "the actual number of bytes read".

src/java.base/share/classes/java/util/zip/ZipFile.java line 347:

> 345:      *
> 346:      * @implNote This implementation returns an instance of
> 347:      * {@link java.util.zip.InflaterInputStream}.

What is the reasoning for this note, do we really want it in the API docs?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From psandoz at openjdk.java.net  Mon Apr 11 16:31:42 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 11 Apr 2022 16:31:42 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v2]
In-Reply-To: <82JZ4zL99-H0sVYCFto978Owri1920TjBcVnntJNQXY=.265e05ab-725e-41a8-a154-b22527083487@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <CBABgAZYaOHLjIZEy1_DjlGLH9a6kSpp3RiiPWWnsAM=.a13dd063-ecb2-4f8a-bf74-4f44c3ff99bd@github.com>
 <AS_5E7kY_9_chjrqSFzS9A7pL3HKPJpkSVxp4A6ZhgQ=.2f49d6d8-52b2-4883-8715-27c0277915ed@github.com>
 <p0ZnGW6Q4B2AwIEJlM21jKJz03dx6WD7OPYnOr8BH3A=.f177c5c2-cfc4-4896-b74e-23cf4583c2dc@github.com>
 <82JZ4zL99-H0sVYCFto978Owri1920TjBcVnntJNQXY=.265e05ab-725e-41a8-a154-b22527083487@github.com>
Message-ID: <xTncMUUb408gg-oM1GI7mceF-j8a4nBrDxEfc_2z-dY=.f1ff502b-bfb0-4193-999c-baf3a6487e12@github.com>

On Mon, 11 Apr 2022 10:03:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> How would the performance change if the `isDirect` and `checkExactAccessMode` merger was reverted?
>> 
>> Add around 15-20ns/op for these micros.
>
> Restructuring so that we only check `direct` once sounds reasonable at face value but would be a lot of churn for little gain (even in the interpreter testing a local boolean field is fast, and JITs will optimize this well).
> 
> The `LINK_TO_STATIC_ARGS_V` in the code generator seems like a remnant from an earlier iteration of this code. The `vform.getMemberName_V` method the code generator would emit a call to doesn't even exist. This should probably be cleaned up, separately. @PaulSandoz, WDYT?

I think it was some left-over from prototyping and was not cleaned up. AFAICT `getMemberName_V` never existed in an committed code. It's OK to remove the `LINK_TO_STATIC_ARGS_V` as part of this commit of you wish.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From jlahoda at openjdk.java.net  Mon Apr 11 16:45:18 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 11 Apr 2022 16:45:18 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for switch
 (Third Preview)
Message-ID: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>

This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).

Draft JLS:
http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html

The changes are:
-there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
-a new contextual keyword `when` is used to add a guard, instead of `&&`
-`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
-total patterns are allowed in `instanceof`
-`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.

Feedback is welcome!

Thanks!

-------------

Commit messages:
 - Adding a test for a NPE from guards.
 - Cleanup
 - Merge branch 'master' into type-patterns-third
 - Guards should be a property of (pattern) case labels, not cases.
 - Merge branch 'master' into type-patterns-third
 - Adding MatchException.
 - Merge branch 'switch-null' into type-patterns-third
 - Updating null handling.
 - Merge branch 'case-guard' into type-patterns-third
 - Moving guards to cases.
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/d6f01e9d...da8401d4

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282274
  Stats: 824 lines in 49 files changed: 392 ins; 245 del; 187 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From darcy at openjdk.java.net  Mon Apr 11 16:56:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 11 Apr 2022 16:56:35 GMT
Subject: RFR: JDK-8283084 RandomGenerator nextDouble(double,
 double) is documented incorrectly [v2]
In-Reply-To: <E2sgDuukpYw74a6iGktcQqPYkvniP2P6I9YGag6B61g=.68b8c507-4e58-4e31-acb2-6f703cd1792e@github.com>
References: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
 <E2sgDuukpYw74a6iGktcQqPYkvniP2P6I9YGag6B61g=.68b8c507-4e58-4e31-acb2-6f703cd1792e@github.com>
Message-ID: <OAMQPQgN1DFa9XEo1OcnauSvCrVnO3fXeBFDqmcFfEY=.ceff0cfd-252e-4280-88e9-c97f796b480d@github.com>

On Mon, 11 Apr 2022 12:32:26 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> `default float nextFloat(float origin, float bound); ` and `default double nextDouble(double origin, double bound); ` are documented incorrectly. The default method checks (origin < bound) and (bound - origin) < +infinity. 
>> 
>> The exception conditions are incorrect: 
>> "if {@code origin} is not finite, 
>>  or {@code bound} is not finite, or {@code origin} 
>>  is greater than or equal to {@code bound}" 
>> 
>> This is not true. Calling with -Double.MAX_VALUE and Double.MAX_VALUE satisfies the documented requirements but actually throws an exception.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add between

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8109

From bpb at openjdk.java.net  Mon Apr 11 17:08:40 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 11 Apr 2022 17:08:40 GMT
Subject: RFR: JDK-8283084 RandomGenerator nextDouble(double,
 double) is documented incorrectly [v2]
In-Reply-To: <E2sgDuukpYw74a6iGktcQqPYkvniP2P6I9YGag6B61g=.68b8c507-4e58-4e31-acb2-6f703cd1792e@github.com>
References: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
 <E2sgDuukpYw74a6iGktcQqPYkvniP2P6I9YGag6B61g=.68b8c507-4e58-4e31-acb2-6f703cd1792e@github.com>
Message-ID: <ecuW8zBeHA-pQbxPVUgLUWfGJL3hk6bXjUrfCSIHKjU=.9bd2178c-bdab-4986-a572-2e34c5b9019d@github.com>

On Mon, 11 Apr 2022 12:32:26 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> `default float nextFloat(float origin, float bound); ` and `default double nextDouble(double origin, double bound); ` are documented incorrectly. The default method checks (origin < bound) and (bound - origin) < +infinity. 
>> 
>> The exception conditions are incorrect: 
>> "if {@code origin} is not finite, 
>>  or {@code bound} is not finite, or {@code origin} 
>>  is greater than or equal to {@code bound}" 
>> 
>> This is not true. Calling with -Double.MAX_VALUE and Double.MAX_VALUE satisfies the documented requirements but actually throws an exception.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add between

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8109

From mcimadamore at openjdk.java.net  Mon Apr 11 17:29:56 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 11 Apr 2022 17:29:56 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v25]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <hb4xJvCLDBSwJ6eSBRVLi3AorEVA5ALrmPngePIJHsk=.947fecc2-ad49-4313-81fe-a513e707e65a@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix UnrolledAccess benchmark

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/d84de510..c9afcd17

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=23-24

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From dfuchs at openjdk.java.net  Mon Apr 11 17:31:01 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 11 Apr 2022 17:31:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

src/java.base/share/classes/java/io/BufferedReader.java line 101:

> 99:      */
> 100:     public BufferedReader(Reader in, int sz) {
> 101:         Objects.requireNonNull(in);

Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`.
Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true,  untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Mon Apr 11 18:04:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:04:16 GMT
Subject: RFR: 8284637: Improve String.join performance
Message-ID: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>

8284637: Improve String.join performance

-------------

Commit messages:
 - refine performance of String#join

Changes: https://git.openjdk.java.net/jdk/pull/8169/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8169&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284637
  Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8169/head:pull/8169

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Mon Apr 11 18:04:17 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 11 Apr 2022 18:04:17 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <OnW0ARMmwzNU-QO-RWhQBk-Gwwi4mAGEckEJTiyE760=.0356b5aa-6569-482f-b169-f582db28f86c@github.com>

On Fri, 8 Apr 2022 19:33:26 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8284637: Improve String.join performance

The?issue is?now [JDK?8284637](https://bugs.openjdk.java.net/browse/JDK-8284637 "[JDK?8284637] Improve String.join performance").

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Mon Apr 11 18:07:12 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:07:12 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
Message-ID: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>

@jmehrens what about this then?
I think it safe now(actually this mechanism is learned from Reader)

-------------

Commit messages:
 - store skip buffers in InputStream Object

Changes: https://git.openjdk.java.net/jdk/pull/5872/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284638
  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:07:13 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 11 Apr 2022 18:07:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>

On Fri, 8 Oct 2021 21:19:36 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

You should really post your changes to jdk-dev at openjdk.java.net before submitting these so you can know if a change is potentially good or bad. Since jdk pull requests require issue numbers, you can ask people on the list if this is a good idea; if it is, someone on the list may create an issue for you, which probably means your suggestion is valid, and only then you should send a pull request.

You need to get a ticket so this pr may get merged. probably through suggesting enhancement on https://bugs.java.com (recommended, takes time but guarantees response) or asking on the mailing list

src/java.base/share/classes/java/io/InputStream.java line 550:

> 548: 
> 549:         if ((skipBuffer == null) || (skipBuffer.length < size)) {
> 550:             skipBuffer = new byte[size];

In the `Reader` class, `skipBuffer` access is thread-safe as it's behind a synchronization on the `lock`. This one isn't and is subject to weird java memory models: in extreme cases, if the `skipBuffer` is set to non-null on another thread, it may be non-null on first field read and null on second field read.

Hence you should write code like this instead:

        byte[] skipBuffer = this.skipBuffer;
        if ((skipBuffer == null) || (skipBuffer.length < size)) {
            this.skipBuffer = skipBuffer = new byte[size];
        }

so you only read the field once and get consistent results.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:07:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:07:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
Message-ID: <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>

On Sat, 9 Oct 2021 15:49:01 GMT, liach <duke at openjdk.java.net> wrote:

> You should really post your changes to jdk-dev at openjdk.java.net before submitting these so you can know if a change is potentially good or bad. Since jdk pull requests require issue numbers, you can ask people on the list if this is a good idea; if it is, someone on the list may create an issue for you, which probably means your suggestion is valid, and only then you should send a pull request.

you mean I should pin the patch file at mailing list first? Get it.

I just think it easier to view the code changes at github pr page than the patch file...but if the workflow should be asking at the mailing list first, then I will obey.

> src/java.base/share/classes/java/io/InputStream.java line 550:
> 
>> 548: 
>> 549:         if ((skipBuffer == null) || (skipBuffer.length < size)) {
>> 550:             skipBuffer = new byte[size];
> 
> In the `Reader` class, `skipBuffer` access is thread-safe as it's behind a synchronization on the `lock`. This one isn't and is subject to weird java memory models: in extreme cases, if the `skipBuffer` is set to non-null on another thread, it may be non-null on first field read and null on second field read.
> 
> Hence you should write code like this instead:
> 
>         byte[] skipBuffer = this.skipBuffer;
>         if ((skipBuffer == null) || (skipBuffer.length < size)) {
>             this.skipBuffer = skipBuffer = new byte[size];
>         }
> 
> so you only read the field once and get consistent results.

> In the `Reader` class, `skipBuffer` access is thread-safe as it's behind a synchronization on the `lock`. This one isn't and is subject to weird java memory models: in extreme cases, if the `skipBuffer` is set to non-null on another thread, it may be non-null on first field read and null on second field read.
> 
> Hence you should write code like this instead:
> 
> ```java
>         byte[] skipBuffer = this.skipBuffer;
>         if ((skipBuffer == null) || (skipBuffer.length < size)) {
>             this.skipBuffer = skipBuffer = new byte[size];
>         }
> ```
> 
> so you only read the field once and get consistent results.

@liach

sorry for missing considering about multi-thread situations...
...the question you bring are correct, but maybe this is not that easy to solve.


        byte[] skipBuffer = this.skipBuffer;
        if ((skipBuffer == null) || (skipBuffer.length < size)) {
            this.skipBuffer = skipBuffer = new byte[size];
        }


this solution might also bring another problem:

first, this.skipBuffer = byte[3]

then, Thread A call skip(10)

meanwhile Thread B call skip(6)

in extream situation, when doing `this.skipBuffer = skipBuffer` in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.

So only way to do it safely seems adding some lock like in Reader... that is pretty costy, I don't think it worth...

closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:07:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:07:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
Message-ID: <kWmP5gxCmEzaZRg8mJmKWtR6rZ_tjV6375MDT5wQS_A=.3c20040a-5574-4647-9b68-5262bad60842@github.com>

On Sat, 9 Oct 2021 17:01:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> You should really post your changes to jdk-dev at openjdk.java.net before submitting these so you can know if a change is potentially good or bad. Since jdk pull requests require issue numbers, you can ask people on the list if this is a good idea; if it is, someone on the list may create an issue for you, which probably means your suggestion is valid, and only then you should send a pull request.
>
>> You should really post your changes to jdk-dev at openjdk.java.net before submitting these so you can know if a change is potentially good or bad. Since jdk pull requests require issue numbers, you can ask people on the list if this is a good idea; if it is, someone on the list may create an issue for you, which probably means your suggestion is valid, and only then you should send a pull request.
> 
> you mean I should pin the patch file at mailing list first? Get it.
> 
> I just think it easier to view the code changes at github pr page than the patch file...but if the workflow should be asking at the mailing list first, then I will obey.

> @XenoAmess This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

help needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:07:15 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 11 Apr 2022 18:07:15 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
Message-ID: <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>

On Sat, 9 Oct 2021 17:08:50 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.

No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:07:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:07:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
Message-ID: <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>

On Sat, 9 Oct 2021 18:10:34 GMT, liach <duke at openjdk.java.net> wrote:

> > in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.
> 
> No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)

you are correct. I forgot you use same name local variable hiding the field variable, so the later skipBuffer passed to read() is local variable.

(sigh) I feel like super stupid when facing multithread programming.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 18:08:46 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 18:08:46 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <OnW0ARMmwzNU-QO-RWhQBk-Gwwi4mAGEckEJTiyE760=.0356b5aa-6569-482f-b169-f582db28f86c@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
 <OnW0ARMmwzNU-QO-RWhQBk-Gwwi4mAGEckEJTiyE760=.0356b5aa-6569-482f-b169-f582db28f86c@github.com>
Message-ID: <0zJ505Sld5Xine5OkEyllTutCdLoEme-d-wZFQwK5uE=.4c72abc8-b189-49ad-b3c7-b7fdc8a718fa@github.com>

On Mon, 11 Apr 2022 11:57:04 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> The?issue is?now [JDK?8284637](https://bugs.openjdk.java.net/browse/JDK-8284637).

Yes. Just got the time to update it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From mcimadamore at openjdk.java.net  Mon Apr 11 18:36:48 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 11 Apr 2022 18:36:48 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v26]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <yFf_NovncXTi9WMMHYowyrppHCokFFeiFzBULn1XbGc=.6737d86a-7810-4d7b-825d-928c66777590@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Use a less expensive array element alignment check
  The bit to byte conversion shows up in hot paths

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9afcd17..a68195ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=24-25

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mchung at openjdk.java.net  Mon Apr 11 18:47:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 11 Apr 2022 18:47:34 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v3]
In-Reply-To: <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
Message-ID: <VfT8NpP0x0bSiEJbY258fleblgjua4Q3rHUTAR1nTiI=.07195e8f-7672-4da8-9218-df3b3a2a8193@github.com>

On Mon, 11 Apr 2022 10:13:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checkExactAccessMode -> checkAccessModeThenIsDirect, privatize throw method, cleanup code generator

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From rriggs at openjdk.java.net  Mon Apr 11 19:25:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 11 Apr 2022 19:25:40 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <9yRExad9k6V3jv_HivsQugy04jF2L338eUAatqlJl2I=.c2d62f4e-9723-49df-b7e9-022ced70e0a6@github.com>

On Fri, 8 Apr 2022 19:33:26 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8284637: Improve String.join performance

Is there jmh test data to quantify the improvement?

Is there jmh test data to quantify the improvement?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From rriggs at openjdk.java.net  Mon Apr 11 19:31:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 11 Apr 2022 19:31:46 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <MWs0CBR1KljcBW773skTV1QpMj3n6en-qQm3Big7OYs=.26c96501-003e-457a-b879-2f490699cc55@github.com>

On Fri, 8 Apr 2022 19:33:26 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8284637: Improve String.join performance

src/java.base/share/classes/java/lang/String.java line 3290:

> 3288:                         value,
> 3289:                         off << coder,
> 3290:                         delimiterLengthWithCoder

Is there any benefit to special casing short delimiters?  1..4 bytes?
Arraycopy has a fixed overhead regardless of the delimiter length.
I might expect a big payoff for coder = Latin1 and delimiter length == 1..2  compared to arraycopy.

src/java.base/share/classes/java/lang/String.java line 3290:

> 3288:                         value,
> 3289:                         off << coder,
> 3290:                         delimiterLengthWithCoder

Is there any benefit to special casing short delimiters?  1..4 bytes?
Arraycopy has a fixed overhead regardless of the delimiter length.
I might expect a big payoff for coder = Latin1 and delimiter length == 1..2  compared to arraycopy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Mon Apr 11 20:18:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 20:18:33 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <9yRExad9k6V3jv_HivsQugy04jF2L338eUAatqlJl2I=.c2d62f4e-9723-49df-b7e9-022ced70e0a6@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
 <9yRExad9k6V3jv_HivsQugy04jF2L338eUAatqlJl2I=.c2d62f4e-9723-49df-b7e9-022ced70e0a6@github.com>
Message-ID: <5QAApUCvSm4wE3zpifXVssYaa_w41Veryulmo45mZX8=.092622da-be3f-422d-bd49-2f2acd68fecd@github.com>

On Mon, 11 Apr 2022 19:22:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is there jmh test data to quantify the improvement?

Not yet as I don't really know how to run a jmh for a package static function, who calls some other class private functions...

Should I put the test upon StringJoiner insterad, as it called String.join? 

I would have a try.

> src/java.base/share/classes/java/lang/String.java line 3290:
> 
>> 3288:                         value,
>> 3289:                         off << coder,
>> 3290:                         delimiterLengthWithCoder
> 
> Is there any benefit to special casing short delimiters?  1..4 bytes?
> Arraycopy has a fixed overhead regardless of the delimiter length.
> I might expect a big payoff for coder = Latin1 and delimiter length == 1..2  compared to arraycopy.

yes I think there should be performance benifitial when delimiter coder be Latin 1 and output not, which would call StringLatin1.inflate for many times, that is a waste.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From naoto at openjdk.java.net  Mon Apr 11 20:29:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Apr 2022 20:29:38 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja or zh_CN
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <i73iYGcTunQ7rK_EtWiIYDRcrGQF_UHcc0cmSvVPNOg=.4252c19e-3c62-4e3c-a54a-85393de12847@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja or zh_CN.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Looks good to me. Would you be able to apply the same fix to German bundle (jdeprscan_de.properties)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8174

From duke at openjdk.java.net  Mon Apr 11 21:35:39 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 21:35:39 GMT
Subject: RFR: 8284637: Improve String.join performance [v2]
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <pcB6Vgp8D1XU805LuXJEFXOIx6h8dyLfo3KUEoX37MY=.fcadbc5e-0509-4028-a990-71e845894e73@github.com>

> 8284637: Improve String.join performance

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add jmh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8169/files
  - new: https://git.openjdk.java.net/jdk/pull/8169/files/e6cf3fa2..9df28a89

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8169&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8169&range=00-01

  Stats: 65 lines in 1 file changed: 65 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8169/head:pull/8169

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Mon Apr 11 21:35:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 11 Apr 2022 21:35:40 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <5QAApUCvSm4wE3zpifXVssYaa_w41Veryulmo45mZX8=.092622da-be3f-422d-bd49-2f2acd68fecd@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
 <9yRExad9k6V3jv_HivsQugy04jF2L338eUAatqlJl2I=.c2d62f4e-9723-49df-b7e9-022ced70e0a6@github.com>
 <5QAApUCvSm4wE3zpifXVssYaa_w41Veryulmo45mZX8=.092622da-be3f-422d-bd49-2f2acd68fecd@github.com>
Message-ID: <SDM1YOJsidpzno_cG9ONmSG2ZV-PXE0obTrdZAFbNaQ=.d748e9f3-d3a7-4b2b-9902-240b06889e39@github.com>

On Mon, 11 Apr 2022 20:15:08 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> Is there jmh test data to quantify the improvement?

@RogerRiggs added jmh now.

Is there any test suite to run it but not run other jmh tests? Or I must invoke the jmh jar using commandline myself to achieve it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From redestad at openjdk.java.net  Mon Apr 11 21:35:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 11 Apr 2022 21:35:40 GMT
Subject: RFR: 8284637: Improve String.join performance
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <yqwhfQ5x6jV4bvuGHnITVh1DKEXiejKmjpp2_GyXnNM=.bb4e9e92-0761-4863-b291-59e4027066c9@github.com>

On Fri, 8 Apr 2022 19:33:26 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8284637: Improve String.join performance

I think you can use or extend the existing `org.openjdk.bench.java.util.StringJoinerBench` JMH for this.

Refer to [doc/testing.md](../tree/master/doc/testing.md) for setup help, but you should be able to run specific JMH using the build system with something like `make test TEST=micro:StringJoinerBench.join`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From dholmes at openjdk.java.net  Mon Apr 11 21:54:40 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 11 Apr 2022 21:54:40 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
Message-ID: <J2NjRCB8GeHlHvPk6tF94Eb6d7B7gmT4ADKbBKAObi4=.7a7e251d-8d66-4b94-b31c-d36d41fc6bcd@github.com>

On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that adds dedicated filler objects to the VM?
>> 
>> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
>> 
>> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
>> 
>> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
>> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
>> 
>> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
>> 
>> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
>> 
>> This has the following benefits:
>> 
>> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
>> 
>> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
>> 
>> This causes some minor changes to external behavior:
>> 
>> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
>> 
>> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
>> 
>> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
>> 
>> 
>> Testing: tier1-8
>> 
>> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
>> 
>> Thanks go to @iklam for helping out with the change.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

Do you really need to define a real `FillerObject.java` class? Can't you use an internal-only variant of a hidden class to represent this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8156

From bpb at openjdk.java.net  Mon Apr 11 22:34:40 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 11 Apr 2022 22:34:40 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
Message-ID: <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>

On Sat, 9 Oct 2021 19:02:17 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>>> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.
>> 
>> No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)
>
>> > in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.
>> 
>> No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)
> 
> you are correct. I forgot you use same name local variable hiding the field variable, so the later skipBuffer passed to read() is local variable.
> 
> (sigh) I feel like super stupid when facing multithread programming.

Isn't it the case that the length of the global `skipBuffer` is non-decreasing? Thus skipping 6 bytes after skipping 10 will not result in a new buffer allocation.

Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of `skip` resulting in a "minor" memory leak in the heap.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon Apr 11 22:43:40 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 11 Apr 2022 22:43:40 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
Message-ID: <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>

On Mon, 11 Apr 2022 22:31:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of skip resulting in a "minor" memory leak in the heap.

The minor leak, though maybe somewhat wasteful, is the necessary cost for thread safety as opposed to locking or synchronizing to reliably retrieve a previously allocated array from another thread.

Another concern about this change is that now the skip buffer is no longer immediately GC'd when exiting the scope but will live on till the input stream is no longer reachable. For instance, if an input stream is skipped and then kept for long, this may be a performance regression instead for the increased memory use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From dholmes at openjdk.java.net  Mon Apr 11 22:51:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 11 Apr 2022 22:51:08 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v24]
In-Reply-To: <K6hQdB8OYNj6N87F-0V4L8pJrcGGYi0V6V2mR0m3ptk=.b1fc2800-7e2d-4b3d-80f6-4341c4d38c4f@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <rG7Ur0DAsuWCr3mbmdCvY6qqcxLLDbwkd1EF1Eb0ARQ=.ff61030c-9095-4d6b-b07a-32a1571c386c@github.com>
 <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com>
 <K6hQdB8OYNj6N87F-0V4L8pJrcGGYi0V6V2mR0m3ptk=.b1fc2800-7e2d-4b3d-80f6-4341c4d38c4f@github.com>
Message-ID: <mqqnMeZmi8WyYQeGurn6qV9zx1WDDs-hrwJCYHQKPbU=.4f2d5b81-1de4-4e06-bd6e-b6d8061e31ad@github.com>

On Mon, 11 Apr 2022 12:04:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/hotspot/share/prims/scopedMemoryAccess.cpp line 141:
>> 
>>> 139: 
>>> 140: /*
>>> 141:  * This function performs a thread-local handshake against all threads running at the time
>> 
>> Nit: thread-local??
>
> I was assuming the term "thread-local handshake" was a thing in the VM, as per:
> https://openjdk.java.net/jeps/312

Ha! Mea culpa. I've been too buried in the other kind of thread-local lately. I completely forgot we actually described handshakes that way. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From rriggs at openjdk.java.net  Mon Apr 11 23:01:34 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 11 Apr 2022 23:01:34 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
Message-ID: <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>

On Mon, 11 Apr 2022 22:40:31 GMT, liach <duke at openjdk.java.net> wrote:

>> Isn't it the case that the length of the global `skipBuffer` is non-decreasing? Thus skipping 6 bytes after skipping 10 will not result in a new buffer allocation.
>> 
>> Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of `skip` resulting in a "minor" memory leak in the heap.
>
>> Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of skip resulting in a "minor" memory leak in the heap.
> 
> The minor leak, though maybe somewhat wasteful, is the necessary cost for thread safety as opposed to locking or synchronizing to reliably retrieve a previously allocated array from another thread.
> 
> Another concern about this change is that now the skip buffer is no longer immediately GC'd when exiting the scope but will live on till the input stream is no longer reachable. For instance, if an input stream is skipped and then kept for long, this may be a performance regression instead for the increased memory use.

Is this change proposed as the result of some experience with particular apps and streams or just observation of the implementation?

Is there any information about what kind of underlying streams do not support skip directly
and what is the distribution of sizes expected to be 'skipped'?
GIven the object instance overhead of an array, I'd be inclined to suggest a minimum size that would
cover all of the 'small' skipping that could occur. And if that's not big enough, jump to the MAX_SKIP_BUFFER_SIZE. To keep the code simple, I'd start at 128bytes and jump to the max if that's not big enough.  There is precious little actual information available to fine tune.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From dholmes at openjdk.java.net  Tue Apr 12 01:18:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 12 Apr 2022 01:18:43 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v3]
In-Reply-To: <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
Message-ID: <xcXGL4-9gPXFRTXMm6NLqBI3IU7nX3qaWRrOvC-gwJo=.783d2a4f-28ff-4327-bf88-ffc16fc6ec65@github.com>

On Mon, 11 Apr 2022 10:13:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> checkExactAccessMode -> checkAccessModeThenIsDirect

Don't you still want "Exact" in there? That "access" check seems odd anyway as it only checks for one form of mismatch - should it not also check for `!exact && accessModeType(ad.type) == ad.symbolicMethodTypeExact`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From andrew at openjdk.java.net  Tue Apr 12 01:20:43 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 12 Apr 2022 01:20:43 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <xbC8JhqTY29UdS_HF18UH4GPMBq3_H3vkZZeMAWXYm4=.21f23eb5-ff1c-4e53-b779-41c5838d98e7@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

What's the status of this? The last comment reads as if this is good to go.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From duke at openjdk.java.net  Tue Apr 12 03:34:18 2022
From: duke at openjdk.java.net (Glavo)
Date: Tue, 12 Apr 2022 03:34:18 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
Message-ID: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>

`java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

-------------

Commit messages:
 - 8284702: Add @since for java.time.LocalDate.EPOCH

Changes: https://git.openjdk.java.net/jdk/pull/8192/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8192&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284702
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8192.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8192/head:pull/8192

PR: https://git.openjdk.java.net/jdk/pull/8192

From duke at openjdk.java.net  Tue Apr 12 04:44:42 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 12 Apr 2022 04:44:42 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <ZNn1hrgPCR3ln-oe22Sx-N8abp2OMp9cK27SPzK_3GQ=.a53d9b4d-be64-4955-965b-06e425f834dc@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

Hmm, isn't this misuse detected by `--release 8` in javac flags?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From duke at openjdk.java.net  Tue Apr 12 05:36:41 2022
From: duke at openjdk.java.net (Glavo)
Date: Tue, 12 Apr 2022 05:36:41 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <ZNn1hrgPCR3ln-oe22Sx-N8abp2OMp9cK27SPzK_3GQ=.a53d9b4d-be64-4955-965b-06e425f834dc@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
 <ZNn1hrgPCR3ln-oe22Sx-N8abp2OMp9cK27SPzK_3GQ=.a53d9b4d-be64-4955-965b-06e425f834dc@github.com>
Message-ID: <ys10YJHfnrtlvKSSvpQzybM3lJm7yK8G2NV4WcQlpSg=.7510c247-93a9-4396-b2d1-76bd0d78ce6b@github.com>

On Tue, 12 Apr 2022 04:41:06 GMT, liach <duke at openjdk.java.net> wrote:

> Hmm, isn't this misuse detected by `--release 8` in javac flags?

Ah, yes, when compiling with `--release 8`, it will prompt `the symbol cannot be found`.

But here's the thing: I'm making some Java 11+ projects compatible with Java 8. Since `module-info.java` needs to be compiled, I actually set up `--release 9` and is compatible with Java 8 by transpiling the bytecode, and I check the whole project through IDEA to catch API abuse. 

For the most part, IDEA works just fine, but it misses `java.time.LocalDate.EPOCH`. The weird crash led me to it, but IDEA didn't warn me, and the lack of `@since` confused me for a while.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From ksakata at openjdk.java.net  Tue Apr 12 06:36:29 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 12 Apr 2022 06:36:29 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary single quotes in the German file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8174/files
  - new: https://git.openjdk.java.net/jdk/pull/8174/files/71e3c897..9cd56ec3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8174&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8174&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8174.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8174/head:pull/8174

PR: https://git.openjdk.java.net/jdk/pull/8174

From ksakata at openjdk.java.net  Tue Apr 12 06:36:29 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 12 Apr 2022 06:36:29 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <MNuy9q7BD3vHwJUFLHJNc5oN8AChaenVeuee4rOVQ4A=.c9160f54-13d5-488d-92ca-6a48ba5bf526@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

Sure! I overlooked that file. I've applied the fix to it. Thank you for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8174

From jpai at openjdk.java.net  Tue Apr 12 07:14:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 12 Apr 2022 07:14:41 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
 <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
Message-ID: <Civ2UMWrHNcYg-GNzOtcbQZBW9fsQvFgZI7nKtjfgHo=.1fbaadb5-4b52-4c46-9352-e1ecd09b848b@github.com>

On Mon, 11 Apr 2022 16:03:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapted wording and copyrights based on @jaikiran review
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 347:
> 
>> 345:      *
>> 346:      * @implNote This implementation returns an instance of
>> 347:      * {@link java.util.zip.InflaterInputStream}.
> 
> What is the reasoning for this note, do we really want it in the API docs?

Hello Alan, this change was done by Volker for the point that I raised in the comment here https://github.com/openjdk/jdk/pull/7986#issuecomment-1081319691

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From alanb at openjdk.java.net  Tue Apr 12 07:30:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Apr 2022 07:30:39 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <Civ2UMWrHNcYg-GNzOtcbQZBW9fsQvFgZI7nKtjfgHo=.1fbaadb5-4b52-4c46-9352-e1ecd09b848b@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
 <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
 <Civ2UMWrHNcYg-GNzOtcbQZBW9fsQvFgZI7nKtjfgHo=.1fbaadb5-4b52-4c46-9352-e1ecd09b848b@github.com>
Message-ID: <4Y7Rf9QjXMbWvRBtICze_TNBwIO_S6EQms7ezxi74KU=.5da1c048-983f-4b2f-97e7-8fba06155e7b@github.com>

On Tue, 12 Apr 2022 07:10:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 347:
>> 
>>> 345:      *
>>> 346:      * @implNote This implementation returns an instance of
>>> 347:      * {@link java.util.zip.InflaterInputStream}.
>> 
>> What is the reasoning for this note, do we really want it in the API docs?
>
> Hello Alan, this change was done by Volker for the point that I raised in the comment here https://github.com/openjdk/jdk/pull/7986#issuecomment-1081319691

> Hello Alan, this change was done by Volker for the point that I raised in the comment here [#7986 (comment)](https://github.com/openjdk/jdk/pull/7986#issuecomment-1081319691)

I think it creates the temptation to cast the returned input stream to InflaterInputStream, it might be better to leave it out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From redestad at openjdk.java.net  Tue Apr 12 08:34:41 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 12 Apr 2022 08:34:41 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v3]
In-Reply-To: <xcXGL4-9gPXFRTXMm6NLqBI3IU7nX3qaWRrOvC-gwJo=.783d2a4f-28ff-4327-bf88-ffc16fc6ec65@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
 <xcXGL4-9gPXFRTXMm6NLqBI3IU7nX3qaWRrOvC-gwJo=.783d2a4f-28ff-4327-bf88-ffc16fc6ec65@github.com>
Message-ID: <UVUFLft0hFxVeuJAvCrKm15VNJoBEQBxlOUkm2piHUg=.e2d36fa2-f87f-4dd4-a245-2d05c2523ca1@github.com>

On Tue, 12 Apr 2022 01:15:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > checkExactAccessMode -> checkAccessModeThenIsDirect
> 
> Don't you still want "Exact" in there? That "access" check seems odd anyway as it only checks for one form of mismatch - should it not also check for `!exact && accessModeType(ad.type) == ad.symbolicMethodTypeExact`?

What's checked is that the access mode is nominally OK. It just so happens that the only rule validated up front is that iff the VH is exact then the types must be an exact match. 

For non-exact VH sufficient checks will be done later, eg. by the `asType` call (if the type of the VH isn't adaptable to `ad.symbolicMethodTypeInvoker` this will throw an exception).

With that in mind then the name `checkExactAccessMode` even appears misleading as it can be interpreted that the VH _must_ be `exact`. Which is not the case. Dropping the `Exact` part makes it less ambiguous.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Tue Apr 12 09:01:41 2022
From: duke at openjdk.java.net (zimmermann6)
Date: Tue, 12 Apr 2022 09:01:41 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v6]
In-Reply-To: <T9UpyY5FXWK3OZNr8wkBklXpYhMea3qTabyym_J-YYQ=.2e19a914-ae01-406b-b6db-25828d83dfc7@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <T9UpyY5FXWK3OZNr8wkBklXpYhMea3qTabyym_J-YYQ=.2e19a914-ae01-406b-b6db-25828d83dfc7@github.com>
Message-ID: <Dog6DhdaEZiichRtMmehDWialR9FJz2YIeIDigQlR_g=.cec6b151-799c-4e9a-9260-4385d299c0be@github.com>

On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adapted hashes in ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Enhanced intervals in MathUtils.
>    Updated references to Schubfach v4.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Refactored test classes to better match OpenJDK conventions.
>    Added tests recommended by Guy Steele and Paul Zimmermann.
>  - Changed MAX_CHARS to static
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76

for the record, I post here the review we did with Jean-Michel Muller of the Schubfach algorithm in last October
[review.pdf](https://github.com/openjdk/jdk/files/8471359/review.pdf)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From dfuchs at openjdk.java.net  Tue Apr 12 09:19:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Apr 2022 09:19:41 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <xbC8JhqTY29UdS_HF18UH4GPMBq3_H3vkZZeMAWXYm4=.21f23eb5-ff1c-4e53-b779-41c5838d98e7@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
 <xbC8JhqTY29UdS_HF18UH4GPMBq3_H3vkZZeMAWXYm4=.21f23eb5-ff1c-4e53-b779-41c5838d98e7@github.com>
Message-ID: <Inhckhhr-kgnkM9V-yM9iLnyTA6odoW4UpV0tX1B-i4=.17f68b4c-119a-40b9-bf8f-d0d27231cb56@github.com>

On Tue, 12 Apr 2022 01:17:37 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> What's the status of this? The last comment reads as if this is good to go.

I believe we're still waiting for Martin to reply to the last comment:

> Maybe, you could also log a bug for a test addition and describe in it an environment, and sort of a high-level scenario of how JDK-8275535 can be reproduced.

Otherwise yes - this would be good to go.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From duke at openjdk.java.net  Tue Apr 12 09:20:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 12 Apr 2022 09:20:45 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v6]
In-Reply-To: <T9UpyY5FXWK3OZNr8wkBklXpYhMea3qTabyym_J-YYQ=.2e19a914-ae01-406b-b6db-25828d83dfc7@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <T9UpyY5FXWK3OZNr8wkBklXpYhMea3qTabyym_J-YYQ=.2e19a914-ae01-406b-b6db-25828d83dfc7@github.com>
Message-ID: <k3PBHbO4wjd8Y4lSnIKr-mnZ5wbjn39LmSKebfF4B6A=.400eb13c-281b-4537-903a-e44012e56be1@github.com>

On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adapted hashes in ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Enhanced intervals in MathUtils.
>    Updated references to Schubfach v4.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Refactored test classes to better match OpenJDK conventions.
>    Added tests recommended by Guy Steele and Paul Zimmermann.
>  - Changed MAX_CHARS to static
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76

Thanks Paul, really appreciate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From jlahoda at openjdk.java.net  Tue Apr 12 09:54:11 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Apr 2022 09:54:11 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v2]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <ixensSemQq77NshdAyzmbfd3eIoBQUa3kr3j5IHq0aI=.6a7b4e9b-f321-4bbc-810d-4b72f34f6812@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/da8401d4..d7e2eb0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=00-01

  Stats: 10 lines in 5 files changed: 5 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From mcimadamore at openjdk.java.net  Tue Apr 12 10:24:47 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 12 Apr 2022 10:24:47 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v27]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <kDrY0W07ctgywiR9pbjRpQ6laLhdC3440xMoYVMo9XQ=.1d97c792-c1d0-45bd-a5f9-d64f1993e83c@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add @ForceInline annotation on session accessor
  Beef up UnrolledAccess benchmark

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/a68195ae..66cebe77

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=25-26

  Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From jvernee at openjdk.java.net  Tue Apr 12 11:37:21 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 12 Apr 2022 11:37:21 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v3]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <e-H2KwBqBoM1abG0b2esq1vTnByMZRVEt0ap0TFzvH8=.121b4869-c8bd-4b0c-bb2b-68dc92f3e82c@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded ComputeMoveOrder

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/3434deda..a7b9f131

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=01-02

  Stats: 174 lines in 1 file changed: 0 ins; 174 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From alanb at openjdk.java.net  Tue Apr 12 13:05:33 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Apr 2022 13:05:33 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>
Message-ID: <H77LKVq-R7RXMEhEyxORAM77r9X0yVuiRAYCfyYGqv0=.e8f6de1e-f674-43de-9dc0-f641f0f08638@github.com>

On Mon, 11 Apr 2022 17:27:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`.

Good!  We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jlahoda at openjdk.java.net  Tue Apr 12 13:18:14 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Apr 2022 13:18:14 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/d7e2eb0a..ef7a7d6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From rriggs at openjdk.java.net  Tue Apr 12 13:52:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 12 Apr 2022 13:52:33 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <R4VcW5djySbbF6uiluJ5smZWi2vL7F8KTCUpboyhbCI=.5f697fea-bf77-4da2-85a2-16d49c3dd33d@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8192

From simonis at openjdk.java.net  Tue Apr 12 14:35:41 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 12 Apr 2022 14:35:41 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
 <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
Message-ID: <JeNPD29GRF1fv7WBrMFhOt0wfwOofACXYDY6VV6BNA0=.84cea2fa-e8ad-4a67-8c7d-ce371c7fbd06@github.com>

On Mon, 11 Apr 2022 16:05:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapted wording and copyrights based on @jaikiran review
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 104:
> 
>> 102:      * are undefined and an implementation is free to change them during the inflate
>> 103:      * operation. If the return value is -1 or an exception is thrown the whole
>> 104:      * content of {@code buf} is undefined.
> 
> "whole content" doesn't seem right, it should be buf[off] to but[off + len - 1] is undefined.

Good catch. Fixed and also updated the corresponding part for `InflaterInputStream::read`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Tue Apr 12 14:45:34 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 12 Apr 2022 14:45:34 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
 <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
Message-ID: <AWB03NgkU_OUbU1dA4ehjYFK379eS4XPy5w32mjsI6o=.518d1582-6ffc-40d0-940a-5ddbde36ef1d@github.com>

On Mon, 11 Apr 2022 16:07:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapted wording and copyrights based on @jaikiran review
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 103:
> 
>> 101:      * elements {@code buf[off+}<i>n</i>{@code ]} through {@code buf[off+}<i>len</i>{@code -1]}
>> 102:      * are undefined and an implementation is free to change them during the inflate
>> 103:      * operation. If the return value is -1 or an exception is thrown the whole
> 
> The sentence is very long. How about putting "an implementation is free ..." in parentheses after "undefined".

Done (also in `ZipInputStream` and `GZipInputStream` which both have the same sentence).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Tue Apr 12 14:50:37 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 12 Apr 2022 14:50:37 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v5]
In-Reply-To: <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <gXEjbwhEk3JJu-o5pqAWbVZunlF2V-_MalsdjDbnZXo=.62f73f29-7944-4555-8a63-9e33486abdac@github.com>
 <UIbYl2eyak8CG4EIdEaMeTdBBOxkQoKEMhYi0Fz2lzc=.c934c98c-2064-4165-9085-626ede15edd4@github.com>
Message-ID: <t99B0C10xmeISlp3Rd-VGKI2U1Y7AxVrrFnCVp5SemQ=.165ee4f6-3595-4d36-a7a7-e8ff49ae1108@github.com>

On Mon, 11 Apr 2022 16:04:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapted wording and copyrights based on @jaikiran review
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 110:
> 
>> 108:      * @param len the maximum number of bytes read
>> 109:      * @return  the actual number of bytes read, or -1 if the end of the
>> 110:      *          compressed input stream is reached
> 
> We should probably adjust the `@return` description, as was done for InflaterInputStream, otherwise the method. description will say "the returning number of inflated bytes" and the return description will say "the actual number of bytes read".

Fixed (also in `ZipInputStream`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From duke at openjdk.java.net  Tue Apr 12 15:00:28 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 12 Apr 2022 15:00:28 GMT
Subject: RFR: 8284742: Handle integral division overflow during parsing
Message-ID: <CPR6E5M3GNjtWbp6o-6TftRKx7JIIJgPElYqAB8ZLrE=.d42c407c-4de9-4845-9c51-9d7218aed5d1@github.com>

Hi,

This patch moves the handling of integral division overflow on x86 from code emission time to parsing time. This allows the compiler to perform more efficient transformations and also aids in achieving better code layout.

I also removed the handling for division by 10 in the ad file since it has been handled in `DivLNode::Ideal` already.

Thank you very much.

    Before:
    Benchmark                               (BUFFER_SIZE)  (divisorType)  Mode  Cnt      Score     Error  Units
    IntegerDivMod.testDivide                         1024          mixed  avgt    5   2394.609 ?  66.460  ns/op
    IntegerDivMod.testDivide                         1024       positive  avgt    5   2411.390 ? 136.849  ns/op
    IntegerDivMod.testDivide                         1024       negative  avgt    5   2396.826 ?  57.079  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024          mixed  avgt    5   2121.708 ?  17.194  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024       positive  avgt    5   2118.761 ?  10.002  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024       negative  avgt    5   2118.739 ?  22.626  ns/op
    IntegerDivMod.testDivideKnownPositive            1024          mixed  avgt    5   2467.937 ?  24.213  ns/op
    IntegerDivMod.testDivideKnownPositive            1024       positive  avgt    5   2463.659 ?   6.922  ns/op
    IntegerDivMod.testDivideKnownPositive            1024       negative  avgt    5   2480.384 ? 100.979  ns/op

    Benchmark                               (BUFFER_SIZE)  (divisorType)  Mode  Cnt      Score     Error  Units
    LongDivMod.testDivide                            1024          mixed  avgt    5   8312.558 ?  18.408  ns/op
    LongDivMod.testDivide                            1024       positive  avgt    5   8339.077 ? 127.893  ns/op
    LongDivMod.testDivide                            1024       negative  avgt    5   8335.792 ? 160.274  ns/op
    LongDivMod.testDivideHoistedDivisor              1024          mixed  avgt    5   7438.914 ?  17.948  ns/op
    LongDivMod.testDivideHoistedDivisor              1024       positive  avgt    5   7550.720 ? 572.387  ns/op
    LongDivMod.testDivideHoistedDivisor              1024       negative  avgt    5   7454.072 ?  70.805  ns/op
    LongDivMod.testDivideKnownPositive               1024          mixed  avgt    5  12120.874 ?  82.832  ns/op
    LongDivMod.testDivideKnownPositive               1024       positive  avgt    5   8898.518 ?  29.827  ns/op
    LongDivMod.testDivideKnownPositive               1024       negative  avgt    5    562.742 ?   2.795  ns/op

    After:
    Benchmark                               (BUFFER_SIZE)  (divisorType)  Mode  Cnt      Score     Error  Units
    IntegerDivMod.testDivide                         1024          mixed  avgt    5   2174.521 ?  13.054  ns/op
    IntegerDivMod.testDivide                         1024       positive  avgt    5   2172.389 ?   7.721  ns/op
    IntegerDivMod.testDivide                         1024       negative  avgt    5   2171.290 ?  12.902  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024          mixed  avgt    5   2049.926 ?  29.098  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024       positive  avgt    5   2043.896 ?  11.702  ns/op
    IntegerDivMod.testDivideHoistedDivisor           1024       negative  avgt    5   2045.430 ?  17.232  ns/op
    IntegerDivMod.testDivideKnownPositive            1024          mixed  avgt    5   2281.506 ?  81.440  ns/op
    IntegerDivMod.testDivideKnownPositive            1024       positive  avgt    5   2279.727 ?  21.590  ns/op
    IntegerDivMod.testDivideKnownPositive            1024       negative  avgt    5   2275.898 ?   3.692  ns/op

    Benchmark                               (BUFFER_SIZE)  (divisorType)  Mode  Cnt      Score     Error  Units
    LongDivMod.testDivide                            1024          mixed  avgt    5   8321.347 ?  93.932  ns/op
    LongDivMod.testDivide                            1024       positive  avgt    5   8352.279 ? 213.565  ns/op
    LongDivMod.testDivide                            1024       negative  avgt    5   8347.779 ? 203.612  ns/op
    LongDivMod.testDivideHoistedDivisor              1024          mixed  avgt    5   7313.156 ? 113.426  ns/op
    LongDivMod.testDivideHoistedDivisor              1024       positive  avgt    5   7299.939 ?  38.591  ns/op
    LongDivMod.testDivideHoistedDivisor              1024       negative  avgt    5   7313.142 ? 100.068  ns/op
    LongDivMod.testDivideKnownPositive               1024          mixed  avgt    5   9322.654 ? 276.328  ns/op
    LongDivMod.testDivideKnownPositive               1024       positive  avgt    5   8639.404 ? 479.006  ns/op
    LongDivMod.testDivideKnownPositive               1024       negative  avgt    5    564.148 ?   6.009  ns/op

-------------

Commit messages:
 - comment grammar
 - x86_32
 - add test cases
 - tests
 - refactor
 - Merge branch 'master' into divMidend
 - fix
 - fix ideal
 - guard should come after precompiled
 - x86 implementation
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/37e28aea...249f8c87

Changes: https://git.openjdk.java.net/jdk/pull/8206/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8206&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284742
  Stats: 743 lines in 16 files changed: 391 ins; 249 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8206/head:pull/8206

PR: https://git.openjdk.java.net/jdk/pull/8206

From simonis at openjdk.java.net  Tue Apr 12 15:00:29 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 12 Apr 2022 15:00:29 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v6]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/1bf6bc1b..52524353

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=04-05

  Stats: 14 lines in 4 files changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From bpb at openjdk.java.net  Tue Apr 12 15:06:34 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 12 Apr 2022 15:06:34 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <C-ygrTEitCuWZixb0QDYdZFcXTPJLGeAeY560srlCoc=.700e8bed-d905-4efa-bf84-a20f21706be9@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From iris at openjdk.java.net  Tue Apr 12 15:40:32 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 12 Apr 2022 15:40:32 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <bWgnc9TqaHOxY5ss8ps9lUvP8kMzV-g6BQlM4-hQC0A=.9b85dc4c-16cf-4aaf-b69f-2109fd8c4303@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From duke at openjdk.java.net  Tue Apr 12 15:45:21 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 12 Apr 2022 15:45:21 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails to
 use byte[] seed
Message-ID: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>

Please review this tiny fix.

A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

-------------

Commit messages:
 - 8283083: java.util.random L128X256MixRandom constructor fails to use byte[] seed

Changes: https://git.openjdk.java.net/jdk/pull/8207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8207&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283083
  Stats: 60 lines in 2 files changed: 51 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8207/head:pull/8207

PR: https://git.openjdk.java.net/jdk/pull/8207

From jlaskey at openjdk.java.net  Tue Apr 12 15:51:30 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 12 Apr 2022 15:51:30 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <XFD4k7KwMeACe6-kHN2-J4Lc48KDf8utnTjpD_k6aTM=.3a1125db-22a5-4ba2-9b6a-b04853feae9a@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From bpb at openjdk.java.net  Tue Apr 12 16:02:34 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 12 Apr 2022 16:02:34 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <jUtjphPu4yCMn0Pbr-vOdJMLN8tqD3SHZAjxNBI5j74=.885eac72-b0af-4b00-aa0a-3e8144ee27be@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From darcy at openjdk.java.net  Tue Apr 12 16:06:31 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 12 Apr 2022 16:06:31 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <x5rOC_-fzQIlKi1-jIrWxO7SxM5JQEUr68SHka25OKI=.d9bb4d0c-4eff-40d4-8959-5f493d9e216e@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

The @since tag was omitted as part of JDK-8143413 and it is good to add it now.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8192

From naoto at openjdk.java.net  Tue Apr 12 16:30:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Apr 2022 16:30:55 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <KA2W9mO7gN0_-VF7Gxdy14zj3kEycActtG8Ls-_IKoI=.43144597-9a7e-457c-abfb-59a94e71a834@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From mchung at openjdk.java.net  Tue Apr 12 16:42:45 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 12 Apr 2022 16:42:45 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v3]
In-Reply-To: <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
 <Doi17wm1QNREgTTTzbagSLjV9A1M60gqx-Gb9DQNO4M=.b7a878f8-16ba-44d7-8615-09cc3dba6537@github.com>
Message-ID: <SiB5Wz_lBfKlhRWkAgx5pB-NCIW3C-hLPyGFuWPlrDg=.431aabdb-b8c7-4b8a-a37c-16ddd09aa316@github.com>

On Mon, 11 Apr 2022 10:13:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few additional enhancements aiming to improve VH performance in the interpreter:
>> 
>> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
>> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
>> 
>> Baseline, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
>> 
>> 
>> Patched, `-Xint`
>> 
>> Benchmark                                 Mode  Cnt    Score   Error  Units
>> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
>> 
>> 
>> No significant performance difference in normal mode.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checkExactAccessMode -> checkAccessModeThenIsDirect, privatize throw method, cleanup code generator

Dropping `Exact` from `checkExactAccessMode` is good with me and it'd help future readers if you can add a javadoc what this method does.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Tue Apr 12 16:43:44 2022
From: duke at openjdk.java.net (Tesla I. =?UTF-8?B?WmhhbmfigK4=?=)
Date: Tue, 12 Apr 2022 16:43:44 GMT
Subject: RFR: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <aYi6_-ls3a4P_BOR0m673IiWdqC71nm5gLDs2YXV08w=.50295795-0375-4f6e-83e7-03db045903ab@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

This highly nontrivial change really requires a lot of people to review! But it looks pretty legitimate to me.

-------------

Marked as reviewed by ice1000 at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8192

From djelinski at openjdk.java.net  Tue Apr 12 16:52:54 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Apr 2022 16:52:54 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

src/java.base/share/classes/sun/nio/ch/SelChImpl.java line 89:

> 87:         } else {
> 88:             long millis;
> 89:             if (nanos == 0) {

Was this change intentional? (`<=` replaced by `==`) 
If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From naoto at openjdk.java.net  Tue Apr 12 16:53:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Apr 2022 16:53:40 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
 <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
Message-ID: <_L7WvLhy2DhV6ce-OecIfMsjMdlp5X9Z1OBSjkbdWJE=.1071ee71-d0c0-4cdf-b867-b88312620f7d@github.com>

On Tue, 12 Apr 2022 06:36:29 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> # Summary
>> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
>> 
>> # How to reproduce this issue
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
>> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>>         ... 8 more
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ?Same as above?
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> ?Same as above?
>> 
>> Of course, it works well when the locale is anything other than those locales.
>> 
>> # Details
>> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
>> 
>> I removed extra single quotes.
>> 
>> # Test
>> It seems there is no test class for it. So I run commands as I mentioned before.
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> ????: jdeprscan [options] {dir|jar|class} ...
>> 
>> ?????:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ???API????????????????????????
>> ???????????????????????JAR?????
>> ?????????????????????????????
>> ???????????????????????????????
>> ????$????????:
>> 
>>     java.lang.Thread$State
>> 
>> --class-path?????????????????????
>> ???????????
>> 
>> --for-removal??????????????????????????API?
>> ????????????6?7???8????????????
>> 
>> --full-version????????????????????????????
>> 
>> --help (-? -h)?????????????????????????
>> 
>> --list (-l)?????????API???????????????????????
>> ???????JAR??????????????????????
>> 
>> --release????????????????API?????????Java SE
>> ???????????
>> 
>> --verbose (-v)????????????????????????????????
>> 
>> --version????????????????????????????????
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ???jdeprscan [options] {dir|jar|class} ...
>> 
>> ???
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ????????????????? API?
>> ???????????????JAR ???
>> ????????????????
>> ????????????? $ ???
>> ?????????
>> 
>>     java.lang.Thread$State
>> 
>> --class-path ?????????????
>> ?????
>> 
>> --for-removal ????????????????
>> ? API???????? 6?7 ? 8 ?????
>> 
>> --full-version ???????????????
>> 
>> --help (-? -h) ????????????
>> 
>> --list (-l) ?????????? API???????
>> ???????????jar ?????
>> 
>> --release ????????????? API ?
>> ? Java SE ????
>> 
>> --verbose (-v) ????????????????
>> 
>> --version ???????????????
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
>> 
>> Optionen:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
>> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
>> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
>> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
>> f?r verschachtelte Klassen angegeben werden. Beispiel:
>> 
>>     java.lang.Thread$State
>> 
>> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
>> von abh?ngigen Klassen.
>> 
>> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
>> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
>> 
>> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
>> 
>> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
>> 
>> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
>> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
>> 
>> Die Option --release gibt das Java SE-Release an, das die Gruppe
>> der veralteten APIS zum Scannen liefert.
>> 
>> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
>> 
>> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
>> 
>> $ jdeprscan -J-Duser.language=en --help                    
>> Usage: jdeprscan [options] {dir|jar|class} ...
>> 
>> options:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scans each argument for usages of deprecated APIs. An argument
>> may be a directory specifying the root of a package hierarchy,
>> a JAR file, a class file, or a class name. The class name must be
>> specified using a fully qualified class name using the $ separator
>> character for nested classes, for example,
>> 
>>     java.lang.Thread$State
>> 
>> The --class-path option provides a search path for resolution
>> of dependent classes.
>> 
>> The --for-removal option limits scanning or listing to APIs that are
>> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
>> 
>> The --full-version option prints out the full version string of the tool.
>> 
>> The --help (-? -h) option prints out a full help message.
>> 
>> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
>> so no directory, jar, or class arguments should be provided.
>> 
>> The --release option specifies the Java SE release that provides the set
>> of deprecated APIs for scanning.
>> 
>> The --verbose (-v) option enables additional message output during processing.
>> 
>> The --version option prints out the abbreviated version string of the tool.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary single quotes in the German file

LGTM. Thanks for the fix.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8174

From darcy at openjdk.java.net  Tue Apr 12 17:03:37 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 12 Apr 2022 17:03:37 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <9M0lb4eXrHZopydqFOsZedon2OV7rwLKh2EtmaTAhWo=.76a79851-4a88-4746-8ea9-92fb62ac8a56@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

Are there any tests for corresponding issues in classes for other algorithms? If not, that could be done as follow-up work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From duke at openjdk.java.net  Tue Apr 12 17:16:42 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 12 Apr 2022 17:16:42 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <t0edfpujpiVSwh7lfKAHF9xvmxUXrA1mkHXlYy-fvfs=.0e7201f9-6c4b-4e74-ae03-d79dd7e5051a@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

Not all random generators expose a (byte[]) constructor.
The test is limited to the LXM group because it is specific for the bug and these generators are known to offer such a constructor. There are others, though.
However, I don't know how to query the factory for constructor parameter types.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From jlaskey at openjdk.java.net  Tue Apr 12 17:39:51 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 12 Apr 2022 17:39:51 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <Nk2Bc7dIshYRFfyWKXNdEaUrGZUhnmt-bUqFsP1qdEM=.e16aa0fe-0f1a-4abe-97e4-a4445354d2a0@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

All generators support the byte[] however many ignore the argument. "If byte[] seed is not supported by an [algorithm](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/random/package-summary.html#algorithms) then the no argument form of create is used." Currently only the LXM algorithms use byte[]. If other algorithms get added then the test can be expanded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From darcy at openjdk.java.net  Tue Apr 12 17:39:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 12 Apr 2022 17:39:52 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <Nk2Bc7dIshYRFfyWKXNdEaUrGZUhnmt-bUqFsP1qdEM=.e16aa0fe-0f1a-4abe-97e4-a4445354d2a0@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
 <Nk2Bc7dIshYRFfyWKXNdEaUrGZUhnmt-bUqFsP1qdEM=.e16aa0fe-0f1a-4abe-97e4-a4445354d2a0@github.com>
Message-ID: <KcqCuv-biRNtye3lZ1X4a0EXVFs3wxlji3GUp8dKA7o=.be7f136e-0e80-40b2-b11d-7ed4e0972b57@github.com>

On Tue, 12 Apr 2022 17:30:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> All generators support the byte[] however many ignore the argument. "If byte[] seed is not supported by an [algorithm](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/random/package-summary.html#algorithms) then the no argument form of create is used." Currently only the LXM algorithms use byte[]. If other algorithms get added then the test can be expanded.

Sounds good; thanks for the additional context.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From duke at openjdk.java.net  Tue Apr 12 17:39:52 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 12 Apr 2022 17:39:52 GMT
Subject: RFR: 8283083: java.util.random L128X256MixRandom constructor fails
 to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <VLk6zKJMH38hu6mN-180yoMgURXUC3s7K4i7QmFmS5U=.9bf85e2b-93ea-407f-8d83-2921d4ef90b9@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

j.u.Random and j.u.SplittableRandom do _not_ expose (byte[]) ctors. It's the factory that falls back to the () ctor if needed.
A more sophisticated test could perhaps use reflection to discover which ctors are exposed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From duke at openjdk.java.net  Tue Apr 12 17:39:54 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 12 Apr 2022 17:39:54 GMT
Subject: Integrated: 8283083: java.util.random L128X256MixRandom constructor
 fails to use byte[] seed
In-Reply-To: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
References: <_v4KTJbz09qgJy3ngP1_SNHD3OPSyv4IWDA6jlqyUoE=.f020d3b8-3dbd-4a14-825b-fc95e0bfb2cf@github.com>
Message-ID: <yEbjYYvq_ZgDzM-4m0BSe79m4AdAMBZB0xbOH1F0w5w=.59ad76c3-1194-4183-9ee9-b31898221926@github.com>

On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review this tiny fix.
> 
> A test similar to the code proposed by the bug reporter has been added for the LXM group. It does not pass before the fix and passes after.

This pull request has now been integrated.

Changeset: 19b140a7
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19b140a7f30ea600d66bcf8370d94f5d6bf6d0d1
Stats:     60 lines in 2 files changed: 51 ins; 0 del; 9 mod

8283083: java.util.random L128X256MixRandom constructor fails to use byte[] seed

Reviewed-by: jlaskey, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8207

From duke at openjdk.java.net  Tue Apr 12 18:04:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 12 Apr 2022 18:04:43 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
 <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
Message-ID: <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>

On Mon, 11 Apr 2022 22:58:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Is this change proposed as the result of some experience with particular apps and streams or just observation of the implementation?

just observation of the implementation of InputStream class and Reader class, and somehow wonder why there be different handling in skip to these 2 classes.

> Is there any information about what kind of underlying streams do not support skip directly and what is the distribution of sizes expected to be 'skipped'? GIven the object instance overhead of an array, I'd be inclined to suggest a minimum size that would cover all of the 'small' skipping that could occur. And if that's not big enough, jump to the MAX_SKIP_BUFFER_SIZE. To keep the code simple, I'd start at 128bytes and jump to the max if that's not big enough. There is precious little actual information available to fine tune.

It whould make the problem @liach said above heavier.

For example, if people just invoke 129, then the imput stream object hold a 8192 length array until it die.

That sounds much too memory wasting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From lancea at openjdk.java.net  Tue Apr 12 18:17:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 12 Apr 2022 18:17:05 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v6]
In-Reply-To: <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>
Message-ID: <5muQMeD8W5plaSjqrVGrTeQSbHDBql-qo89c3dYMZBQ=.5b52edcc-d93d-4bda-9e20-5d2ee3e701db@github.com>

On Tue, 12 Apr 2022 15:00:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods

Hi Volker,

I think this reads much better.  Its too bad we cannot take advantage of `@inheritedDoc`

A couple of minor comments below

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 99:

> 97:      * no bytes are read and {@code 0} is returned.
> 98:      * <p>
> 99:      * If <i>n</i> denotes the returned number of inflated bytes then {@code buf[off]}

I think a comma might be needed after "...inflated bytes"

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 103:

> 101:      * elements {@code buf[off+}<i>n</i>{@code ]} through {@code buf[off+}<i>len</i>{@code -1]}
> 102:      * are undefined (an implementation is free to change them during the inflate
> 103:      * operation). If the return value is -1 or an exception is thrown then {@code buf[off]}

perhaps tweak "... is thrown then" 

to

"... is thrown, then the contents of..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From djelinski at openjdk.java.net  Tue Apr 12 19:12:48 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Apr 2022 19:12:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <whmZArcN8psiLD1GiNeJNnfLofJtUwCqF9jPljYPzp0=.42df8f13-6331-4d2f-ac14-1efc1d1d17e9@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110:

> 108: 
> 109:     public void flushBuffer() throws IOException {
> 110:         if (lock instanceof InternalLock locker) {

now that StreamEncoder is final, we can drop the `else` branch

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From rreddy at openjdk.java.net  Tue Apr 12 20:17:17 2022
From: rreddy at openjdk.java.net (Ravi Reddy)
Date: Tue, 12 Apr 2022 20:17:17 GMT
Subject: RFR: 8284771: java/util/zip/CloseInflaterDeflaterTest.java failed with
 "AssertionError: Expected IOException to be thrown, but nothing was thrown"
Message-ID: <SOcUmOkRUgXDsH8SOI_zDMHMeGipJ40dhwIunqa9T98=.603e4f9a-4c22-42ed-bfd9-85762985cee7@github.com>

CloseInflaterDeflaterTest.java is failing intermittently(Observed once in macOS and Linux), testInflaterOutputStream() is added as an extra test as part of https://bugs.openjdk.java.net/browse/JDK-8278794. Disabling this test for now before debugging any timing issues in Inflater.

-------------

Commit messages:
 - 8284771: java/util/zip/CloseInflaterDeflaterTest.java failed with AssertionError: Expected IOException to be thrown, but nothing was thrown

Changes: https://git.openjdk.java.net/jdk/pull/8213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8213&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284771
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8213/head:pull/8213

PR: https://git.openjdk.java.net/jdk/pull/8213

From naoto at openjdk.java.net  Tue Apr 12 20:33:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Apr 2022 20:33:53 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v5]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <IWbsLRDMibMqH2F3EvwoPfJfD5xyRZhDc-Cj0fIgITE=.8fe5b6cb-6e9d-4296-9f73-18f7641c794f@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - abstract class -> top level interface
 - interface -> abstract class
 - Merge branch 'master' into JDK-8279185
 - Removed the method
 - Merge branch 'master' into JDK-8279185
 - Changed to use a type to determine ISO based or not
 - Renamed the new method
 - Merge branch 'master' into JDK-8279185
 - Addresses review comments
 - copyright year fix
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/488250f0...7f596789

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/530ed40e..7f596789

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=03-04

  Stats: 302965 lines in 3965 files changed: 219208 ins; 39068 del; 44689 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From lancea at openjdk.java.net  Tue Apr 12 20:36:39 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 12 Apr 2022 20:36:39 GMT
Subject: RFR: 8284771: java/util/zip/CloseInflaterDeflaterTest.java failed
 with
 "AssertionError: Expected IOException to be thrown, but nothing was thrown"
In-Reply-To: <SOcUmOkRUgXDsH8SOI_zDMHMeGipJ40dhwIunqa9T98=.603e4f9a-4c22-42ed-bfd9-85762985cee7@github.com>
References: <SOcUmOkRUgXDsH8SOI_zDMHMeGipJ40dhwIunqa9T98=.603e4f9a-4c22-42ed-bfd9-85762985cee7@github.com>
Message-ID: <QeSgf5bxGd6iAUCGwiaMH8OzBPZ8D2bFEUBUDoF0GkM=.1fce0116-5b9e-44de-a12c-a89bea736791@github.com>

On Tue, 12 Apr 2022 20:09:31 GMT, Ravi Reddy <rreddy at openjdk.org> wrote:

> CloseInflaterDeflaterTest.java is failing intermittently(Observed once in macOS and Linux), testInflaterOutputStream() is added as an extra test as part of https://bugs.openjdk.java.net/browse/JDK-8278794. Disabling this test for now before debugging any timing issues in Inflater.

Hi Ravi,

Yes, makes sense to disable the test to keep Mach5 happy given this failure is very very intermittent while you try to chase down whether it is an implementation or test issue

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8213

From rreddy at openjdk.java.net  Tue Apr 12 20:42:44 2022
From: rreddy at openjdk.java.net (Ravi Reddy)
Date: Tue, 12 Apr 2022 20:42:44 GMT
Subject: Integrated: 8284771: java/util/zip/CloseInflaterDeflaterTest.java
 failed with
 "AssertionError: Expected IOException to be thrown, but nothing was thrown"
In-Reply-To: <SOcUmOkRUgXDsH8SOI_zDMHMeGipJ40dhwIunqa9T98=.603e4f9a-4c22-42ed-bfd9-85762985cee7@github.com>
References: <SOcUmOkRUgXDsH8SOI_zDMHMeGipJ40dhwIunqa9T98=.603e4f9a-4c22-42ed-bfd9-85762985cee7@github.com>
Message-ID: <68n3-5eVKr3NWxJx5LN-8eynroIvYwBzwnk6M4nMQMg=.afa46abf-79e8-4b56-9909-2e193b129c44@github.com>

On Tue, 12 Apr 2022 20:09:31 GMT, Ravi Reddy <rreddy at openjdk.org> wrote:

> CloseInflaterDeflaterTest.java is failing intermittently(Observed once in macOS and Linux), testInflaterOutputStream() is added as an extra test as part of https://bugs.openjdk.java.net/browse/JDK-8278794. Disabling this test for now before debugging any timing issues in Inflater.

This pull request has now been integrated.

Changeset: 7891085a
Author:    Ravi Reddy <rreddy at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7891085a877b8a5715d095e0c0dbaaf5bc8f16bb
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8284771: java/util/zip/CloseInflaterDeflaterTest.java failed with "AssertionError: Expected IOException to be thrown, but nothing was thrown"

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8213

From rriggs at openjdk.java.net  Tue Apr 12 20:43:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 12 Apr 2022 20:43:41 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
 <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
 <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>
Message-ID: <z-WRw8K4f1dxxtyUCOWsNwytXLtaDk8PWsCC7Oyg488=.7f17a235-f396-4703-b7b2-3b0b67ae3508@github.com>

On Tue, 12 Apr 2022 18:00:18 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> Is this change proposed as the result of some experience with particular apps and streams or just observation of the implementation?
>> 
>> Is there any information about what kind of underlying streams do not support skip directly
>> and what is the distribution of sizes expected to be 'skipped'?
>> GIven the object instance overhead of an array, I'd be inclined to suggest a minimum size that would
>> cover all of the 'small' skipping that could occur. And if that's not big enough, jump to the MAX_SKIP_BUFFER_SIZE. To keep the code simple, I'd start at 128bytes and jump to the max if that's not big enough.  There is precious little actual information available to fine tune.
>
>> Is this change proposed as the result of some experience with particular apps and streams or just observation of the implementation?
> 
> just observation of the implementation of InputStream class and Reader class, and somehow wonder why there be different handling in skip to these 2 classes.
> 
>> Is there any information about what kind of underlying streams do not support skip directly and what is the distribution of sizes expected to be 'skipped'? GIven the object instance overhead of an array, I'd be inclined to suggest a minimum size that would cover all of the 'small' skipping that could occur. And if that's not big enough, jump to the MAX_SKIP_BUFFER_SIZE. To keep the code simple, I'd start at 128bytes and jump to the max if that's not big enough. There is precious little actual information available to fine tune.
> 
> It whould make the problem @liach said above heavier.
> 
> For example, if people just invoke 129, then the imput stream object hold a 8192 length array until it die.
> 
> That sounds much too memory wasting.

Without specific information about use cases, there isn't enough information to
craft a good algorithm/solution and simplicity is preferred. 
The MAX_SKIP_BUFFER_SIZE is 2048 (not 8192).

What subclasses of InputStream in the JDK do not override skip(n)?
Most sequential streams are open for a relatively short period of time, the lifetime of the 
memory for the buffer won't change the memory usage enough to notice.

If the concern is about tying up memory then allocate the buffer once and
don't resize it.  Each resize consumes extra memory and gc cycles to reclaim the last buffer.
Use the requested size but at least nnn and at most MAX_SKIP_BUFFER_SIZE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From redestad at openjdk.java.net  Tue Apr 12 21:13:18 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 12 Apr 2022 21:13:18 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v4]
In-Reply-To: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
Message-ID: <8NY7ciaop7syIzKg2DJPBvDkPx7Q7IyIypgJu7eWaYI=.69ddad48-b298-4398-b834-c03e98120326@github.com>

> A few additional enhancements aiming to improve VH performance in the interpreter:
> 
> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
> 
> Baseline, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
> 
> 
> Patched, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
> 
> 
> No significant performance difference in normal mode.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Improve javadoc for merged method
 - Add javadoc for merged method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8160/files
  - new: https://git.openjdk.java.net/jdk/pull/8160/files/2a4fbd6d..df1d652b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=02-03

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8160.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8160/head:pull/8160

PR: https://git.openjdk.java.net/jdk/pull/8160

From joehw at openjdk.java.net  Tue Apr 12 21:29:59 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 12 Apr 2022 21:29:59 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v5]
In-Reply-To: <IWbsLRDMibMqH2F3EvwoPfJfD5xyRZhDc-Cj0fIgITE=.8fe5b6cb-6e9d-4296-9f73-18f7641c794f@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <IWbsLRDMibMqH2F3EvwoPfJfD5xyRZhDc-Cj0fIgITE=.8fe5b6cb-6e9d-4296-9f73-18f7641c794f@github.com>
Message-ID: <tvNaY_5RP3DQyGR2X0iUUdxgweNhXdrFQzXen1m80bs=.b0fade97-7974-4a52-b589-cdbf4330597c@github.com>

On Tue, 12 Apr 2022 20:33:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Merge branch 'master' into JDK-8279185
>  - Removed the method
>  - Merge branch 'master' into JDK-8279185
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - Merge branch 'master' into JDK-8279185
>  - Addresses review comments
>  - copyright year fix
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c751c9bd...7f596789

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From joehw at openjdk.java.net  Tue Apr 12 21:37:10 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 12 Apr 2022 21:37:10 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v5]
In-Reply-To: <IWbsLRDMibMqH2F3EvwoPfJfD5xyRZhDc-Cj0fIgITE=.8fe5b6cb-6e9d-4296-9f73-18f7641c794f@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <IWbsLRDMibMqH2F3EvwoPfJfD5xyRZhDc-Cj0fIgITE=.8fe5b6cb-6e9d-4296-9f73-18f7641c794f@github.com>
Message-ID: <sBbXNmnq3XXDeW0QiJLpGyW6XOwc6VWEoAr2TthhHv0=.b6cb5318-7241-4734-9cb6-f8229f390dad@github.com>

On Tue, 12 Apr 2022 20:33:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Merge branch 'master' into JDK-8279185
>  - Removed the method
>  - Merge branch 'master' into JDK-8279185
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - Merge branch 'master' into JDK-8279185
>  - Addresses review comments
>  - copyright year fix
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/30616d77...7f596789

Looks good to me. For the name, another option might be IsoCompatible instead of IsoBased as historically those other calendars were established before the ISO standard, although technically, in the Java language, it could be said the xChronology is ISO based.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From redestad at openjdk.java.net  Tue Apr 12 21:48:35 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 12 Apr 2022 21:48:35 GMT
Subject: RFR: 8284579: Improve VarHandle checks for interpreter [v5]
In-Reply-To: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
Message-ID: <v8GyCAUYgEWlIU183LcCupsZQxHo03A3hckm1SklUyg=.d9e8f71d-c10b-45bd-aaa3-d4d13146db04@github.com>

> A few additional enhancements aiming to improve VH performance in the interpreter:
> 
> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
> 
> Baseline, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
> 
> 
> Patched, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
> 
> 
> No significant performance difference in normal mode.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8160/files
  - new: https://git.openjdk.java.net/jdk/pull/8160/files/df1d652b..9998e538

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8160&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8160.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8160/head:pull/8160

PR: https://git.openjdk.java.net/jdk/pull/8160

From duke at openjdk.java.net  Tue Apr 12 22:08:23 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 12 Apr 2022 22:08:23 GMT
Subject: RFR: 8284637: Improve String.join performance [v2]
In-Reply-To: <pcB6Vgp8D1XU805LuXJEFXOIx6h8dyLfo3KUEoX37MY=.fcadbc5e-0509-4028-a990-71e845894e73@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
 <pcB6Vgp8D1XU805LuXJEFXOIx6h8dyLfo3KUEoX37MY=.fcadbc5e-0509-4028-a990-71e845894e73@github.com>
Message-ID: <cKjQfYiMvf_00Y3JWXnMgIRsr_LSUfl4Yf44cVV2P94=.30cda7db-5b1d-429f-be9f-b6b8e6856e4e@github.com>

On Mon, 11 Apr 2022 21:35:39 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8284637: Improve String.join performance
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jmh

JMH results shows not worthy. closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Tue Apr 12 22:08:24 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 12 Apr 2022 22:08:24 GMT
Subject: Withdrawn: 8284637: Improve String.join performance
In-Reply-To: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
References: <KRzDfRG0DUgxhi9v3vD45RhVdSB14VRtY_IWl6zE-hc=.25eed51f-b817-4d4f-a834-682b04a27a2a@github.com>
Message-ID: <Mru-dMxQv-k6-5u6IeoTpQcNK6lPac9F9RS4sRPJQyc=.882b9f23-60d6-4287-8c29-8d554dfddb3a@github.com>

On Fri, 8 Apr 2022 19:33:26 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8284637: Improve String.join performance

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8169

From duke at openjdk.java.net  Tue Apr 12 22:19:18 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 12 Apr 2022 22:19:18 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add MIN_SKIP_BUFFER_SIZE

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/e29f7483..81e9ca49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue Apr 12 22:19:18 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 12 Apr 2022 22:19:18 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <z-WRw8K4f1dxxtyUCOWsNwytXLtaDk8PWsCC7Oyg488=.7f17a235-f396-4703-b7b2-3b0b67ae3508@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
 <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
 <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>
 <z-WRw8K4f1dxxtyUCOWsNwytXLtaDk8PWsCC7Oyg488=.7f17a235-f396-4703-b7b2-3b0b67ae3508@github.com>
Message-ID: <OSvxeFmVfX1uW9NmyOWNl8LhKtZEaKex7J02v8ypc68=.06560466-66e9-4ca2-b784-cfcd52f1d3d0@github.com>

On Tue, 12 Apr 2022 20:39:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Without specific information about use cases, there isn't enough information to craft a good algorithm/solution and simplicity is preferred. The MAX_SKIP_BUFFER_SIZE is 2048 (not 8192).
> 
> What subclasses of InputStream in the JDK do not override skip(n)? Most sequential streams are open for a relatively short period of time, the lifetime of the memory for the buffer won't change the memory usage enough to notice.
> 
> If the concern is about tying up memory then allocate the buffer once and don't resize it. Each resize consumes extra memory and gc cycles to reclaim the last buffer. Use the requested size but at least nnn and at most MAX_SKIP_BUFFER_SIZE.

@RogerRiggs Sounds reasonable and applied. Should we change the implementation in Reader class as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue Apr 12 23:15:34 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 12 Apr 2022 23:15:34 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
Message-ID: <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>

On Tue, 12 Apr 2022 22:19:18 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add MIN_SKIP_BUFFER_SIZE

src/java.base/share/classes/java/io/InputStream.java line 557:

> 555: 
> 556:         while (remaining > 0) {
> 557:             nr = read(skipBuffer, 0, (int)Math.min(size, remaining));

I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue Apr 12 23:38:39 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 12 Apr 2022 23:38:39 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <OSvxeFmVfX1uW9NmyOWNl8LhKtZEaKex7J02v8ypc68=.06560466-66e9-4ca2-b784-cfcd52f1d3d0@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
 <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
 <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>
 <z-WRw8K4f1dxxtyUCOWsNwytXLtaDk8PWsCC7Oyg488=.7f17a235-f396-4703-b7b2-3b0b67ae3508@github.com>
 <OSvxeFmVfX1uW9NmyOWNl8LhKtZEaKex7J0
 2v8ypc68=.06560466-66e9-4ca2-b784-cfcd52f1d3d0@github.com>
Message-ID: <0OY6BtovHw8z0yusyf484Pz3_ccQlHuFMBOZlHuy4JI=.3c4b2e6e-81b6-40a8-8bd3-d8da73c344b9@github.com>

On Tue, 12 Apr 2022 22:15:22 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> What subclasses of InputStream in the JDK do not override skip(n)?

>From a peek, the majority of subclasses do not override `skip(long)`. Most overrides are delegations or optimizations for random access structures; but there are some that create their custom local variable skip buffers, usually of size 512 or minimum of 512 and the skip size. These custom skip buffer ones IMO should have their overrides removed.

> Most sequential streams are open for a relatively short period of time, the lifetime of the
> memory for the buffer won't change the memory usage enough to notice.

True, and with good use of try-with-resources, these instance fields' array allocations shouldn't be too much of a problem compared to allocation in every skip(long) call.

> If the concern is about tying up memory then allocate the buffer once and
don't resize it. Each resize consumes extra memory and gc cycles to reclaim the last buffer.
> Use the requested size but at least nnn and at most MAX_SKIP_BUFFER_SIZE.

Shouldn't be too problematic, as most skip usages in JDK as I see are skipping small number of bytes like 2 or 4, or like skipping over attributes of Java class files. A minimum skip buffer size isn't that helpful, as I don't think we often see skip calls with slowly incremental sizes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 02:22:15 2022
From: duke at openjdk.java.net (Glavo)
Date: Wed, 13 Apr 2022 02:22:15 GMT
Subject: Integrated: 8284702: Add @since for java.time.LocalDate.EPOCH
In-Reply-To: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
References: <363AE84_eBT9gWix7-JGFIgcWF5BFpSEZnZ9x2Dn6nE=.f0b014c0-ee03-49a4-a1b4-09b67a210e6b@github.com>
Message-ID: <1fhrQ53jwgTLAX8phkxxVMth0dmR8FxRtkKdu6h8HUk=.807f6b3f-1be4-4554-92e1-8d11bc981c8e@github.com>

On Tue, 12 Apr 2022 03:21:00 GMT, Glavo <duke at openjdk.java.net> wrote:

> `java.time.LocalDate.EPOCH` was introduced in Java 9, but there is no corresponding `@since` in the javadoc. The absence of `@since` makes it impossible for IDEs to check for misuse of it, it may be misused by users targeting Java 8 and crash at runtime.

This pull request has now been integrated.

Changeset: 5691a3b6
Author:    Glavo <zjx001202 at gmail.com>
Committer: Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5691a3b6afcb3229ccd0e00d3a4ec9ccacc93182
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8284702: Add @since for java.time.LocalDate.EPOCH

Reviewed-by: rriggs, bpb, iris, darcy, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8192

From smarks at openjdk.java.net  Wed Apr 13 04:28:22 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 04:28:22 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v14]
In-Reply-To: <thTYaib7qsUcjKYs7x6wI4EiKMJYRxT5bqOECcmy9oo=.710d8143-7fc6-4cfa-a07d-04e98b341d58@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <thTYaib7qsUcjKYs7x6wI4EiKMJYRxT5bqOECcmy9oo=.710d8143-7fc6-4cfa-a07d-04e98b341d58@github.com>
Message-ID: <4D0sWW9SiN-hzeWLnadmlzCpjsJaZzO-9fjzqNRpWC0=.f286fec6-23d3-4fb1-b7f4-495ae57383d1@github.com>

On Sun, 10 Apr 2022 20:28:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' into fix_8186958
>  - variable nameToReferenceSize rename to moduleCount
>  - use (double) DEFAULT_LOAD_FACTOR instead of 0.75
>  - drop CalculateHashMapCapacityTestJMH
>  - refine javadoc for LinkedHashMap#newLinkedHashMap
>  - revert changes in jdk.compile
>  - update usages of LinkedHashMap
>  - update usages of HashMap
>  - update codes
>  - update jmh
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/34914f12...7adc89c1

OK, the CSR is approved now.

Regarding the load factor of 0.75, I'm not quite sure whether there is a rigorous justification for this value. It seems "traditional." It does seem likely that using a load factor of 0.75 will generate fewer collisions than a load factor of 1.0. It would be an interesting for a future investigation to see how much of a performance difference the load factor makes. In practice I think there are very few cases where it makes sense to use anything other than the default. In any case, there's no reason to change anything from the current default of 0.75.

It occurs to me that `HashSet` and `LinkedHashSet` have the same "capacity" problem. It would be good to add static factory methods for them too. This is probably best done as a separate effort: see [JDK-8284780](https://bugs.openjdk.java.net/browse/JDK-8284780).

I've done some work on add test cases for these new static factory methods, and I've also added API notes to the capacity-based constructors to link to the new factory methods. Note that even though these are javadoc changes, the API notes are non-normative and don't require an update to the CSR. See the last few commits on this branch:

https://github.com/stuart-marks/jdk/commits/JDK-8186958-presized-HashMap

If you think they're good, please pull them in.

Regarding the scope of changes, the number of call sites that are changed is indeed spread rather too widely across the JDK. In order to keep the number of required reviewers small, I think we should trim down the call sites to a more manageable set. Specifically, I'd suggest **removing** from this PR the changes from the files in the following areas:

 * src/java.desktop
 * src/java.management
 * src/jdk.internal.vm.ci
 * src/jdk.jfr
 * src/jdk.management.jfr
 * src/jdk.management
 * src/utils/IdealGraphVisualizer

After removing these, there will still be a fair number of call sites. Several of these have errors, so they'll be sufficient to show the value of the new APIs. After that I'll recompute and readjust labels to pull in the right set of reviewers.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From redestad at openjdk.java.net  Wed Apr 13 07:25:17 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 13 Apr 2022 07:25:17 GMT
Subject: Integrated: 8284579: Improve VarHandle checks for interpreter
In-Reply-To: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
References: <kxwFCI_vWG8oGUYWeeWHqoMPQEJjNqWilL-Nng9Hhgo=.09a444bd-b37b-456f-811c-100088c783c0@github.com>
Message-ID: <k7e4pH54OSzu6bgqE59I5Brru-JNcQbOrFt1FwcvVD4=.27f788e1-af55-4246-a421-75a065a8ff36@github.com>

On Fri, 8 Apr 2022 11:48:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few additional enhancements aiming to improve VH performance in the interpreter:
> 
> - Flatten `TypeAndInvokers`: adds a pointer to `VarHandle` (a small increase 40->48) but removes an object and an indirection on any instance actually used - and might avoid allocating the `MethodHandle[]` unnecessarily on some instances
> - Have `checkExactAccessMode` return the directness of the `VarHandle` so that we can avoid some `isDirect` method calls.
> 
> Baseline, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  478.324 ? 5.762  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  392.114 ? 1.644  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  822.484 ? 1.865  ns/op
> 
> 
> Patched, `-Xint`
> 
> Benchmark                                 Mode  Cnt    Score   Error  Units
> VarHandleExact.exact_exactInvocation      avgt   30  437.704 ? 5.320  ns/op
> VarHandleExact.generic_exactInvocation    avgt   30  374.512 ? 3.154  ns/op
> VarHandleExact.generic_genericInvocation  avgt   30  757.054 ? 1.237  ns/op
> 
> 
> No significant performance difference in normal mode.

This pull request has now been integrated.

Changeset: 280aa428
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/280aa428800043f314b92ae88076d596cb4c2fe0
Stats:     244 lines in 4 files changed: 26 ins; 28 del; 190 mod

8284579: Improve VarHandle checks for interpreter

Reviewed-by: mcimadamore, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8160

From shade at openjdk.java.net  Wed Apr 13 08:34:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 13 Apr 2022 08:34:16 GMT
Subject: RFR: 8283994: Make Xerces DatatypeException stackless [v2]
In-Reply-To: <k2WBknIQLg1Hsn99pqFwZLePPkzALUWwu5a0MQkqrn8=.96caf879-7cd9-412c-bf95-b0d74707c383@github.com>
References: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
 <YFmihRUp8vvh2c0__gk2F_cLQv9LTUrK28igWxczCaw=.06e1d18f-b0d8-4cfc-8783-50b0ddff8fa6@github.com>
 <wqXOrg59fuul9RmX-pqMljVO3BhV08Nl6clMSC5sCik=.e91b5bbf-4d78-43c2-b9dd-d59b99c77731@github.com>
 <k2WBknIQLg1Hsn99pqFwZLePPkzALUWwu5a0MQkqrn8=.96caf879-7cd9-412c-bf95-b0d74707c383@github.com>
Message-ID: <MXFQ9WMrHDq95Ux35lzzni5RTr0GmQUdrY5oYikzZek=.24d9551d-c2c5-4d21-bb82-03d2e1835e6d@github.com>

On Wed, 6 Apr 2022 07:48:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Any other reviews? I would like someone else to confirm my investigation that we don't use the stack traces out of these exceptions too...
>
>> Hello @shipilev, do you think this stackless nature of this specific `DatatypeException` type should be noted in its javadoc, just to avoid any surprises when someone in future ends up using this exception type as the "cause" of some other exception?
> 
> I don't think so. It seems to me the intent for these exceptions is to carry error information without any stack trace info.

> @shipilev
> 
> > Any other reviews? I would like someone else to confirm my investigation that we don't use the stack traces out of these exceptions too...
> 
> I opened [XERCESJ?1742](https://issues.apache.org/jira/browse/XERCESJ-1742) to get this change upstreamed into **Xerces**, the resolution of which should also answer your question about whether the stack traces are really unused.

Thanks! But I see there seem to be no upstream interest yet. So I am planning to integrate this to JDK first, and so asking for JDK-specific reviews again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8036

From dfuchs at openjdk.java.net  Wed Apr 13 09:52:13 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 13 Apr 2022 09:52:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <H77LKVq-R7RXMEhEyxORAM77r9X0yVuiRAYCfyYGqv0=.e8f6de1e-f674-43de-9dc0-f641f0f08638@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>
 <H77LKVq-R7RXMEhEyxORAM77r9X0yVuiRAYCfyYGqv0=.e8f6de1e-f674-43de-9dc0-f641f0f08638@github.com>
Message-ID: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com>

On Tue, 12 Apr 2022 13:02:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedReader.java line 101:
>> 
>>> 99:      */
>>> 100:     public BufferedReader(Reader in, int sz) {
>>> 101:         Objects.requireNonNull(in);
>> 
>> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`.
>> Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true,  untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`?
>
>> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`.
> 
> Good!  We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time.

Thanks - the same issue appears with `BufferedWriter`/`Writer`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Wed Apr 13 11:16:11 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 13 Apr 2022 11:16:11 GMT
Subject: RFR: 8283994: Make Xerces DatatypeException stackless [v2]
In-Reply-To: <YFmihRUp8vvh2c0__gk2F_cLQv9LTUrK28igWxczCaw=.06e1d18f-b0d8-4cfc-8783-50b0ddff8fa6@github.com>
References: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
 <YFmihRUp8vvh2c0__gk2F_cLQv9LTUrK28igWxczCaw=.06e1d18f-b0d8-4cfc-8783-50b0ddff8fa6@github.com>
Message-ID: <jyeBIgN9PXWiGWeb3yBA2teZpL1ePeeenfLwZJALjLw=.56ecb666-487d-45d5-8606-e357db7230ed@github.com>

On Thu, 31 Mar 2022 17:54:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug report for more details. This change improves SPECjvm2008:xml.validation for about +3%:
>> 
>> 
>>  baseline: 298.353 ? 1.008  ops/min
>>  patched:  309.912 ? 1.347  ops/min
>> 
>> Of course, the real improvements might be even higher, as exception might be thrown from much deeper call hierarchy.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `jaxp_all`
>>  - [x] Linux x86_64 fastdebug, `javax/xml`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update LastModified

Marked as reviewed by jpai (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8036

From jpai at openjdk.java.net  Wed Apr 13 11:16:12 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 13 Apr 2022 11:16:12 GMT
Subject: RFR: 8283994: Make Xerces DatatypeException stackless [v2]
In-Reply-To: <MXFQ9WMrHDq95Ux35lzzni5RTr0GmQUdrY5oYikzZek=.24d9551d-c2c5-4d21-bb82-03d2e1835e6d@github.com>
References: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
 <YFmihRUp8vvh2c0__gk2F_cLQv9LTUrK28igWxczCaw=.06e1d18f-b0d8-4cfc-8783-50b0ddff8fa6@github.com>
 <wqXOrg59fuul9RmX-pqMljVO3BhV08Nl6clMSC5sCik=.e91b5bbf-4d78-43c2-b9dd-d59b99c77731@github.com>
 <k2WBknIQLg1Hsn99pqFwZLePPkzALUWwu5a0MQkqrn8=.96caf879-7cd9-412c-bf95-b0d74707c383@github.com>
 <MXFQ9WMrHDq95Ux35lzzni5RTr0GmQUdrY5oYikzZek=.24d9551d-c2c5-4d21-bb82-03d2e1835e6d@github.com>
Message-ID: <0zGsB9jNlFW_BCVEFJ1P1N5pLb0x55MOKErAgGSqkgU=.981305d2-e344-4f65-990f-79dc4ef8735f@github.com>

On Wed, 13 Apr 2022 08:30:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Hello @shipilev, do you think this stackless nature of this specific `DatatypeException` type should be noted in its javadoc, just to avoid any surprises when someone in future ends up using this exception type as the "cause" of some other exception?
>> 
>> I don't think so. It seems to me the intent for these exceptions is to carry error information without any stack trace info.
>
>> @shipilev
>> 
>> > Any other reviews? I would like someone else to confirm my investigation that we don't use the stack traces out of these exceptions too...
>> 
>> I opened [XERCESJ?1742](https://issues.apache.org/jira/browse/XERCESJ-1742) to get this change upstreamed into **Xerces**, the resolution of which should also answer your question about whether the stack traces are really unused.
> 
> Thanks! But I see there seem to be no upstream interest yet. So I am planning to integrate this to JDK first, and so asking for JDK-specific reviews again.

> > Hello @shipilev, do you think this stackless nature of this specific `DatatypeException` type should be noted in its javadoc, just to avoid any surprises when someone in future ends up using this exception type as the "cause" of some other exception?
> 
> I don't think so. It seems to me the intent for these exceptions is to carry error information without any stack trace info.

Looks fine to me then. However, I'm not a Reviewer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8036

From duke at openjdk.java.net  Wed Apr 13 11:50:17 2022
From: duke at openjdk.java.net (Carsten Madsen)
Date: Wed, 13 Apr 2022 11:50:17 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <Gte8YLHxnKxaXg3b89FtQvp0cMgUYkUzWwZWyFs3OFQ=.bbb400f2-378b-45e0-8b3c-f90a75e3df53@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

Look [here](https://github.com/spring-projects/spring-security/issues/10318) for spring based test case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From duke at openjdk.java.net  Wed Apr 13 11:53:23 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 13 Apr 2022 11:53:23 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>
 <H77LKVq-R7RXMEhEyxORAM77r9X0yVuiRAYCfyYGqv0=.e8f6de1e-f674-43de-9dc0-f641f0f08638@github.com>
 <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com>
Message-ID: <R0MbjJvRbc_r2EuG74ciY1I5ta2-Vrhi-V2ueC1IDQY=.cee506ed-8193-4a31-a7f8-da99309329ec@github.com>

On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`.
>> 
>> Good!  We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time.
>
> Thanks - the same issue appears with `BufferedWriter`/`Writer`.

The?solution is?to?add the?`private`?constructor:

	private Reader(Object fallbackLock, Void internal) {
		// assert fallbackLock != null;
		// use InternalLock for trusted classes
		Class<?> clazz = getClass();
		if (clazz == InputStreamReader.class
			|| clazz == BufferedReader.class
			|| clazz == FileReader.class
			|| clazz == sun.nio.cs.StreamDecoder.class) {
			this.lock = InternalLock.newLockOr(fallbackLock);
		} else {
			this.lock = fallbackLock;
		}
	}

to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`).

---

The?`protected`?`Reader`?constructors can?then be?changed to:

	protected Reader() {
		this(this, null);
	}

and

	protected Reader(Object lock) {
		this(Objects.requireNonNull(lock), null);
	}


---

Doing?so will?allow this?change to?be?reverted:
Suggestion:

        super(in);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Wed Apr 13 11:53:27 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 13 Apr 2022 11:53:27 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <whmZArcN8psiLD1GiNeJNnfLofJtUwCqF9jPljYPzp0=.42df8f13-6331-4d2f-ac14-1efc1d1d17e9@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <whmZArcN8psiLD1GiNeJNnfLofJtUwCqF9jPljYPzp0=.42df8f13-6331-4d2f-ac14-1efc1d1d17e9@github.com>
Message-ID: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com>

On Tue, 12 Apr 2022 19:09:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110:
> 
>> 108: 
>> 109:     public void flushBuffer() throws IOException {
>> 110:         if (lock instanceof InternalLock locker) {
> 
> now that StreamEncoder is final, we can drop the `else` branch

Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` (which?it might?be if?it gets?exposed as?a?system?property).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Wed Apr 13 12:02:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 12:02:16 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com>
Message-ID: <42x8p2tSXc1XsNqEQV1xTKhIfg9RBPLMiY2YQOwkS_Q=.25eb38fd-d338-49b5-a0aa-240043062f7b@github.com>

On Tue, 12 Apr 2022 16:49:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll

It's benign for the current usages but you are right, it was not intentional.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From hseigel at openjdk.java.net  Wed Apr 13 12:32:50 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 13 Apr 2022 12:32:50 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
Message-ID: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>

Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.

Thanks, Harold

-------------

Commit messages:
 - 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

Changes: https://git.openjdk.java.net/jdk/pull/8222/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8222&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284642
  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8222.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8222/head:pull/8222

PR: https://git.openjdk.java.net/jdk/pull/8222

From duke at openjdk.java.net  Wed Apr 13 12:50:17 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 13 Apr 2022 12:50:17 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <kZ3T_UtfN2zEQ39Qbade8R12pRbhoMmTaxVmam-omrs=.dfcefb64-ae82-4c39-891d-cd487998a657@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 190:

> 188:             case CASE_NULL -> true;
> 189:             case PATTERN_SWITCH -> true;
> 190:             case TOTAL_PATTERN_IN_INSTACEOF -> true;

small typo in `INSTANCEOF`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From stuefe at openjdk.java.net  Wed Apr 13 12:50:18 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 13 Apr 2022 12:50:18 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <3OTolL7WqKV7VwfoHyTecHdIEGJPsArBq0vJYi1Q1vE=.990fb286-0a67-4d00-96b1-9c2209b823f4@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

How long exactly has this been broken? I'd be worried about use cases where people use MaxDirectMemorySize=0 to prevent usage of direct memory altogether.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From redestad at openjdk.java.net  Wed Apr 13 13:00:16 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 13 Apr 2022 13:00:16 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v9]
In-Reply-To: <E-61wcoVVCPU3QGDpmw0zr_ceOW-iNtzeR-z3r2HhtE=.0cf457a0-61db-43f0-9a45-1de26ef8ee07@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <E-61wcoVVCPU3QGDpmw0zr_ceOW-iNtzeR-z3r2HhtE=.0cf457a0-61db-43f0-9a45-1de26ef8ee07@github.com>
Message-ID: <ZcrgBubBrDulEgcty16MaUy4AzUjcxfOnOYVOJNTb9o=.35e50b92-16f7-49d1-8124-d52e9ec2386d@github.com>

On Thu, 7 Apr 2022 07:01:23 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some merge conflicts

Can't really see anything that I think is the direct cause of the error you're seeing, but there are a couple of places where `Op_AryHashCode` appears to be missing.

src/hotspot/share/adlc/formssel.cpp line 903:

> 901:         strcmp(_matrule->_rChild->_opType,"StrComp"   )==0 ||
> 902:         strcmp(_matrule->_rChild->_opType,"StrEquals" )==0 ||
> 903:         strcmp(_matrule->_rChild->_opType,"StrHashCode")==0 ||

Should you add `AryHashCode` here, too?

src/hotspot/share/opto/loopnode.cpp line 5784:

> 5782:     case Op_StrComp:            // Does a bunch of load-like effects
> 5783:     case Op_StrEquals:
> 5784:     case Op_StrHashCode:

Seems reasonably that you need a `case Op_AryHashCode` here, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700

From alanb at openjdk.java.net  Wed Apr 13 14:15:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:15:13 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <y51hmsocsoH4CeKCjwqfpSGHck_QnIyehKVXAORUTYg=.a7678e85-5aca-471e-8d67-5f6faa63614d@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

If nothing else, I think the man page could be improved to say that JVM chooses the size for NIO direct-buffer allocations automatically when MaxDirectMemorySize is not set.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From alanb at openjdk.java.net  Wed Apr 13 14:21:20 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:21:20 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Refresh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/21972f45..0e12c206

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00-01

  Stats: 1837 lines in 112 files changed: 786 ins; 531 del; 520 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Wed Apr 13 14:22:18 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:22:18 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <whmZArcN8psiLD1GiNeJNnfLofJtUwCqF9jPljYPzp0=.42df8f13-6331-4d2f-ac14-1efc1d1d17e9@github.com>
 <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com>
Message-ID: <DxFzivEgZevPoy_gxdOvNLAnpPQN01YE9iFTrkyBn24=.4434cb05-b614-456f-a18b-2a836e491323@github.com>

On Wed, 13 Apr 2022 11:35:33 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` 

That's right, both StreamEncoder and StreamDecoder need the both cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From stuefe at openjdk.java.net  Wed Apr 13 14:26:13 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 13 Apr 2022 14:26:13 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <s7g-h1U7x0UNhr9peqCSXFui-ZhHJTrJizKCnX8YMTM=.4a4f0119-e7ba-4428-adab-b870bf663f7e@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

Marked as reviewed by stuefe (Reviewer).

I looked a little, and found no example on GH or Google which relied on MaxDirectMemorySize=0 to disable. I found some examples of the opposite, e.g. https://github.com/cloudfoundry/java-buildpack/issues/591. So this is fine I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From alanb at openjdk.java.net  Wed Apr 13 14:39:15 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:39:15 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
Message-ID: <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>

On Tue, 12 Apr 2022 22:19:18 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add MIN_SKIP_BUFFER_SIZE

This change may be  problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.

This change may be  problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From alanb at openjdk.java.net  Wed Apr 13 14:45:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:45:16 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v6]
In-Reply-To: <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>
Message-ID: <7y75OZCM78Jnx8pmgnNTEar4zxGrug7zT6kleacZR_A=.dc704ac9-6ebd-4835-977e-db58e3b5dcd6@github.com>

On Tue, 12 Apr 2022 15:00:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods

You've addressed my points, the updated javadoc looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7986

From duke at openjdk.java.net  Wed Apr 13 14:49:27 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 14:49:27 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
Message-ID: <vfsQB0oPRuyju3vTJD8-YKUKXhmVXRPS5mpekbsi1xg=.71614b77-0237-4843-9e31-a1f68eab725a@github.com>

On Wed, 13 Apr 2022 14:36:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change may be problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.

@AlanBateman
You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.

Is there anything different in the situations about skipBuffer in Reader and InputStream?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Wed Apr 13 14:49:31 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 13 Apr 2022 14:49:31 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
Message-ID: <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>

On Tue, 12 Apr 2022 23:13:26 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add MIN_SKIP_BUFFER_SIZE
>
> src/java.base/share/classes/java/io/InputStream.java line 557:
> 
>> 555: 
>> 556:         while (remaining > 0) {
>> 557:             nr = read(skipBuffer, 0, (int)Math.min(size, remaining));
> 
> I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)

The check for `skipBuffer.length < size` makes it appear that the buffer can be re-allocated.
If it is allocated once then only the `skipBuffer == null` is needed.

The code may be simpler if the 'size' variable is removed.

        byte[] skipBuffer = this.skipBuffer;
        if (skipBuffer == null) {
            this.skipBuffer = skipBuffer = 
                new byte[(remaining < MIN_SKIP_BUFFER_SIZE) ? MIN_SKIP_BUFFER_SIZE : MAX_SKIP_BUFFER_SIZE];
        }
        while (remaining > 0) {
            int nr = read(skipBuffer, 0, (int)Math.min(skipBuffer.length, remaining));

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 14:56:12 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 14:56:12 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  moving nr declaration from the beginning of the method to where it's actually used

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/81e9ca49..85cec668

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 14:56:13 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 14:56:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
 <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>
Message-ID: <P3EmxpkdszNaxYRDZOfTmsyidB_BC18lGEmjPU-_Ai4=.5902e387-4a79-4b5d-b1d3-af20ccdb186c@github.com>

On Wed, 13 Apr 2022 14:45:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/InputStream.java line 557:
>> 
>>> 555: 
>>> 556:         while (remaining > 0) {
>>> 557:             nr = read(skipBuffer, 0, (int)Math.min(size, remaining));
>> 
>> I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)
>
> The check for `skipBuffer.length < size` makes it appear that the buffer can be re-allocated.
> If it is allocated once then only the `skipBuffer == null` is needed.
> 
> The code may be simpler if the 'size' variable is removed.
> 
>         byte[] skipBuffer = this.skipBuffer;
>         if (skipBuffer == null) {
>             this.skipBuffer = skipBuffer = 
>                 new byte[(remaining < MIN_SKIP_BUFFER_SIZE) ? MIN_SKIP_BUFFER_SIZE : MAX_SKIP_BUFFER_SIZE];
>         }
>         while (remaining > 0) {
>             int nr = read(skipBuffer, 0, (int)Math.min(skipBuffer.length, remaining));

It indeed is reallocated when the existing one is not large enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 14:56:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 14:56:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <P3EmxpkdszNaxYRDZOfTmsyidB_BC18lGEmjPU-_Ai4=.5902e387-4a79-4b5d-b1d3-af20ccdb186c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
 <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>
 <P3EmxpkdszNaxYRDZOfTmsyidB_BC18lGEmjPU-_Ai4=.5902e387-4a79-4b5d-b1d3-af20ccdb186c@github.com>
Message-ID: <oMOMN3qsMhMiLdtbrbu70hwFfCAtOxapurUDvTA7G9o=.a2120008-d90b-40a6-806f-de6c7a4c9c28@github.com>

On Wed, 13 Apr 2022 14:51:34 GMT, liach <duke at openjdk.java.net> wrote:

>> The check for `skipBuffer.length < size` makes it appear that the buffer can be re-allocated.
>> If it is allocated once then only the `skipBuffer == null` is needed.
>> 
>> The code may be simpler if the 'size' variable is removed.
>> 
>>         byte[] skipBuffer = this.skipBuffer;
>>         if (skipBuffer == null) {
>>             this.skipBuffer = skipBuffer = 
>>                 new byte[(remaining < MIN_SKIP_BUFFER_SIZE) ? MIN_SKIP_BUFFER_SIZE : MAX_SKIP_BUFFER_SIZE];
>>         }
>>         while (remaining > 0) {
>>             int nr = read(skipBuffer, 0, (int)Math.min(skipBuffer.length, remaining));
>
> It indeed is reallocated when the existing one is not large enough.

> I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)

@liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From alanb at openjdk.java.net  Wed Apr 13 14:59:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 14:59:32 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <R0MbjJvRbc_r2EuG74ciY1I5ta2-Vrhi-V2ueC1IDQY=.cee506ed-8193-4a31-a7f8-da99309329ec@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <gIhyv1JkhaDiOjAMzSa2KitK7AVpez4nEcyUCNZcDy4=.20ba7338-d0f8-4e07-9281-e0db71b1d0e5@github.com>
 <H77LKVq-R7RXMEhEyxORAM77r9X0yVuiRAYCfyYGqv0=.e8f6de1e-f674-43de-9dc0-f641f0f08638@github.com>
 <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com>
 <R0MbjJvRbc_r2EuG74ciY1I5ta2-Vrhi-V2ueC1IDQY=.cee506ed-8193-4a31-a7f8-da99309329ec@github.com>
Message-ID: <t_XYRfB1pyEoG2aE2-7fuySE94Bkg_2iVdaHj5Oz2IE=.c1617a88-0f9c-440b-9602-6a91839201a0@github.com>

On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Thanks - the same issue appears with `BufferedWriter`/`Writer`.
>
> The?solution is?to?add the?`private`?constructor:
> 
> 	private Reader(Object fallbackLock, Void internal) {
> 		// assert fallbackLock != null;
> 		// use InternalLock for trusted classes
> 		Class<?> clazz = getClass();
> 		if (clazz == InputStreamReader.class
> 			|| clazz == BufferedReader.class
> 			|| clazz == FileReader.class
> 			|| clazz == sun.nio.cs.StreamDecoder.class) {
> 			this.lock = InternalLock.newLockOr(fallbackLock);
> 		} else {
> 			this.lock = fallbackLock;
> 		}
> 	}
> 
> to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`).
> 
> ---
> 
> The?`protected`?`Reader`?constructors can?then be?changed to:
> 
> 	protected Reader() {
> 		this(this, null);
> 	}
> 
> and
> 
> 	protected Reader(Object lock) {
> 		this(Objects.requireNonNull(lock), null);
> 	}
> 
> 
> ---
> 
> Doing?so will?allow this?change to?be?reverted:
> Suggestion:
> 
>         super(in);

> Thanks - the same issue appears with `BufferedWriter`/`Writer`.

Right. I think we can reduce this to the case where a BufferedReader is not subclassed, and it wraps an InputStreamReader or FileReader that have not been subclassed. Similarly the case where a BufferedWriter is not subclassed and it wraps an OutputStreamWriter or FileWriter that have not been subclassed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Wed Apr 13 15:06:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 15:06:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
Message-ID: <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>

On Wed, 13 Apr 2022 14:36:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add MIN_SKIP_BUFFER_SIZE
>
> This change may be  problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.

> @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
> 
> Is there anything different in the situations about skipBuffer in Reader and InputStream?

Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:12:11 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 15:12:11 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
 <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
Message-ID: <JSyJ8KwX-1ogl7M2DhrIe9h1oKp54OsUnOKWg7GH-DY=.b32480ef-ef7c-4ced-8e41-0e82203fc5f8@github.com>

On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
> > Is there anything different in the situations about skipBuffer in Reader and InputStream?
> 
> Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.

Making a drop of storing skipBuffer in Reader sonds another solution that acceptable to me, as it makes the handling strategy same in Reader and InputStream classes.

> The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use

I don't think use frequency can influence this. In other words, I still think, if there be no special acceptable reason, we shall make the skipBuffer handle strategy same in Reader and InputStream classes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Wed Apr 13 15:12:12 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 13 Apr 2022 15:12:12 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <oMOMN3qsMhMiLdtbrbu70hwFfCAtOxapurUDvTA7G9o=.a2120008-d90b-40a6-806f-de6c7a4c9c28@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
 <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>
 <P3EmxpkdszNaxYRDZOfTmsyidB_BC18lGEmjPU-_Ai4=.5902e387-4a79-4b5d-b1d3-af20ccdb186c@github.com>
 <oMOMN3qsMhMiLdtbrbu70hwFfCAtOxapurUDvTA7G9o=.a2120008-d90b-40a6-806f-de6c7a4c9c28@github.com>
Message-ID: <uRuoimTA6vMHIoJIpQRT-bikknb3fqHrzkCZYaDBbDU=.a78e97ea-6fcd-4775-aa27-c15ff9dbd4a9@github.com>

On Wed, 13 Apr 2022 14:52:20 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> It indeed is reallocated when the existing one is not large enough.
>
>> I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)
> 
> @liach done.

Sorry, I misunderstood your earlier comment: "Sounds reasonable and applied"
as concurring with not re-allocating to avoid the overhead of gc and wasting the smaller buffer.
The code can be harder to understand because `size` and `skipBuffer.length` may be different.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Wed Apr 13 15:16:16 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 13 Apr 2022 15:16:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
 <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
Message-ID: <fOp0v66S87Iwpw_ke-gNVtYXEI7bsyEN0IenPmCRPig=.12679a53-a66c-4350-af2a-bb0943ef541b@github.com>

On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change may be  problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.
>
>> @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
>> 
>> Is there anything different in the situations about skipBuffer in Reader and InputStream?
> 
> Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.

@AlanBateman Is the concern about holding more memory sufficient to retain the buffer using a SoftReference so it can be freed eagerly?
These buffers are never read from, so are quite a waste, but at least they are only used when
the underlying stream overrides skip.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:23:16 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 15:23:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
Message-ID: <YZEQBwwgex85rhZyP72xZYKMXCe4TZ9xlYFyzvT-k64=.9569a41e-914a-403f-b69e-71cae3173088@github.com>

On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving nr declaration from the beginning of the method to where it's actually used

On a side note for unifying the skip buffer implementation of reader vs input stream: For the input stream subclasses in the JDK that have their own skip with buffering logic (as described in https://github.com/openjdk/jdk/pull/5872#discussion_r848950065), they almost always have only local-variable skip buffers (not kept as fields for reuse), and their buffers' max sizes are smaller that provided by the InputStream class.

Imo we should check the usage of `skip` in other projects; in JDK it's like skipping 2 bytes in certain image formats, and I would expect usages like reading class file attribute name and size then skip by the read size.

> This change may be problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.

If per-object allocation is a problem, would it be feasible to allocate a static soft reference to a max-sized skip buffer? It can be potentially shared with the `Reader` class, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:28:15 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 15:28:15 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <YZEQBwwgex85rhZyP72xZYKMXCe4TZ9xlYFyzvT-k64=.9569a41e-914a-403f-b69e-71cae3173088@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
 <YZEQBwwgex85rhZyP72xZYKMXCe4TZ9xlYFyzvT-k64=.9569a41e-914a-403f-b69e-71cae3173088@github.com>
Message-ID: <e0KEpeECRp4RPSFEW7EDH0EfyhPLt17yEPa3Xb5HSLM=.82dd9bba-7cf9-432c-be17-cda9289bcb69@github.com>

On Wed, 13 Apr 2022 15:20:06 GMT, liach <duke at openjdk.java.net> wrote:

> On a side note for unifying the skip buffer implementation of reader vs input stream: For the input stream subclasses in the JDK that have their own skip with buffering logic (as described in https://github.com/openjdk/jdk/pull/5872#discussion_r848950065), they almost always have only local-variable skip buffers (not kept as fields for reuse), and their buffers' max sizes are smaller that provided by the InputStream class.
> 
> Imo we should check the usage of `skip` in other projects; in JDK it's like skipping 2 bytes in certain image formats, and I would expect usages like reading class file attribute name and size then skip by the read size.
> 
> > This change may be problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.
> 
> If per-object allocation is a problem, would it be feasible to allocate a static soft reference to a max-sized skip buffer? It can be potentially shared with the `Reader` class, too.

No as security reason. Any subclass can read this buffer using read function? thus might cause secure data leak.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:28:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 15:28:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <e0KEpeECRp4RPSFEW7EDH0EfyhPLt17yEPa3Xb5HSLM=.82dd9bba-7cf9-432c-be17-cda9289bcb69@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
 <YZEQBwwgex85rhZyP72xZYKMXCe4TZ9xlYFyzvT-k64=.9569a41e-914a-403f-b69e-71cae3173088@github.com>
 <e0KEpeECRp4RPSFEW7EDH0EfyhPLt17yEPa3Xb5HSLM=.82dd9bba-7cf9-432c-be17-cda9289bcb69@github.com>
Message-ID: <RfCLNLWgJFL2cJ524DJ_lRA0jfz3t80DS8-rgr6r9xo=.2c8b1d44-3409-4bcd-878b-9413558b1c8c@github.com>

On Wed, 13 Apr 2022 15:23:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> > On a side note for unifying the skip buffer implementation of reader vs input stream: For the input stream subclasses in the JDK that have their own skip with buffering logic (as described in https://github.com/openjdk/jdk/pull/5872#discussion_r848950065), they almost always have only local-variable skip buffers (not kept as fields for reuse), and their buffers' max sizes are smaller that provided by the InputStream class.
> > 
> > Imo we should check the usage of `skip` in other projects; in JDK it's like skipping 2 bytes in certain image formats, and I would expect usages like reading class file attribute name and size then skip by the read size.
> > 
> > > This change may be problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.
> > 
> > If per-object allocation is a problem, would it be feasible to allocate a static soft reference to a max-sized skip buffer? It can be potentially shared with the `Reader` class, too.
> 
> No as security reason. Any subclass can read this buffer using read function? thus might cause secure data leak.

see https://github.com/openjdk/jdk/pull/5855

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:40:14 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 15:40:14 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
Message-ID: <gC4VV9c-P0zjQLD8t1gKdU5LUZwNSnqwKeOl9XCz0Rs=.e242655a-c26a-47a4-9826-b9297ce21718@github.com>

On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving nr declaration from the beginning of the method to where it's actually used

Yeah forgot about that part. Thus I guess using soft reference would be a better way to deal with this extra memory use issue. So something like

private SoftReference<byte[]> skipBuffer;

private byte[] skipBuffer(long remaining) {
    int size = (int) Math.min(MAX_SKIP_BUFFER_SIZE, remaining);
    SoftReference<byte[]> ref = this.skipBuffer;
    byte[] buffer;
    if (ref == null || (buffer = ref.get()) == null || buffer.length < size) {
        buffer = new byte[size];
        this.skipBuffer = new SoftReference(buffer);
    }
    return buffer;
}


This should be thread-safe, and we can just call `byte[] skipBuffer = skipBuffer(remaining);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 15:51:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 15:51:16 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
Message-ID: <0fRlHgrwIWYKZ4ADb07OceRyBZ5CL1IEgG6TAqJNNhA=.32f6ded9-cdd4-4b48-bb8a-ea0c1348a3ec@github.com>

On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving nr declaration from the beginning of the method to where it's actually used

> Yeah forgot about that part. Thus I guess using soft reference would be a better way to deal with this extra memory use issue. So something like
> 
> ```java
> private SoftReference<byte[]> skipBuffer;
> 
> private byte[] skipBuffer(long remaining) {
>     int size = (int) Math.min(MAX_SKIP_BUFFER_SIZE, remaining);
>     SoftReference<byte[]> ref = this.skipBuffer;
>     byte[] buffer;
>     if (ref == null || (buffer = ref.get()) == null || buffer.length < size) {
>         buffer = new byte[size];
>         this.skipBuffer = new SoftReference(buffer);
>     }
>     return buffer;
> }
> ```
> 
> This should be thread-safe, and we can just call `byte[] skipBuffer = skipBuffer(remaining);`

LGTM

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Wed Apr 13 16:05:18 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 13 Apr 2022 16:05:18 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
Message-ID: <KUF_evnlFbLnCT-tiEdvUe5uoOiROfZ2HatRx6mA5ps=.29b78cbc-422f-43e1-8f16-f6f7b1a5e65d@github.com>

On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving nr declaration from the beginning of the method to where it's actually used

I'd be a quite cautious about the slippery slope of incremental change with very little measurable benefit.
Most applications reading InputStreams or Readers are using the buffered versions that already
handle skip. These are the fallback versions.
Except for the buffered versions, the lower level InputStreams can do a better job of skip
then at the higher level built on read().  FileInputStream directly uses seek, other direct streams
can probably do a more efficient skip() by reading into private buffers. For example low level I/O for networking already reads into private buffers.  But the dominate case is still the buffered streams and readers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From alanb at openjdk.java.net  Wed Apr 13 16:05:19 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 16:05:19 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
 <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
Message-ID: <84YsekICpjY77dhw3Tx9QLKlO1EHQ01kuIlZEXKgTXQ=.e3692542-d8bb-49e2-9949-6a1ff292e9a5@github.com>

On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change may be  problematic for servers with a large number connections and an input stream for each connection. It could add up to 2k to the footprint of each connection when skip is used.
>
>> @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
>> 
>> Is there anything different in the situations about skipBuffer in Reader and InputStream?
> 
> Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.

> @AlanBateman Is the concern about holding more memory sufficient to retain the buffer using a SoftReference so it can be freed eagerly?
> These buffers are never read from, so are quite a waste, but at least they are only used when
> the underlying stream overrides skip.

Maybe but I think it needs some benchmarks to know if caching a byte[] will help or just bloat memory. If the InputStream is to a file or socket then maybe skip is dominated by the I/O rather than the array allocation and zero'ing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 16:11:06 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 16:11:06 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v15]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <FfGE_8gkTVgUqilSS4D9j71hyI0hQuF2pHrVUOiwVQw=.966f41f1-bae8-4844-9b06-6fcf6ce22300@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with three additional commits since the last revision:

 - Add apiNote to appropriate constructors of HM, LHM, and WHM.
 - Add test cases for static factory methods.
 - Minor adjustment to test cases of WhiteBoxResizeTest

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/7adc89c1..ab8fbb83

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=13-14

  Stats: 85 lines in 4 files changed: 77 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From alanb at openjdk.java.net  Wed Apr 13 16:16:23 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 13 Apr 2022 16:16:23 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v27]
In-Reply-To: <kDrY0W07ctgywiR9pbjRpQ6laLhdC3440xMoYVMo9XQ=.1d97c792-c1d0-45bd-a5f9-d64f1993e83c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <kDrY0W07ctgywiR9pbjRpQ6laLhdC3440xMoYVMo9XQ=.1d97c792-c1d0-45bd-a5f9-d64f1993e83c@github.com>
Message-ID: <sdmzFLNIr3ABlN8AGMEpMu-9QEpLpu8jUmjpZblPoNg=.c247b3d6-6a2c-49d8-8e85-8287437b1e8c@github.com>

On Tue, 12 Apr 2022 10:24:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline annotation on session accessor
>   Beef up UnrolledAccess benchmark

src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052:

> 1050:     public MemorySegment map(MapMode mode, long offset, long size,
> 1051:                                       MemorySession session)
> 1052:             throws IOException, UnsupportedOperationException

Just a minor here is that UOE is a runtime exception so probably shouldn't be in the throws.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Wed Apr 13 16:29:11 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 16:29:11 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  revert changes in:
  src/java.desktop
  src/java.management
  src/jdk.internal.vm.ci
  src/jdk.jfr
  src/jdk.management.jfr
  src/jdk.management
  src/utils/IdealGraphVisualizer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/ab8fbb83..2f5617bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=14-15

  Stats: 36 lines in 20 files changed: 0 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr 13 16:31:02 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 16:31:02 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v14]
In-Reply-To: <4D0sWW9SiN-hzeWLnadmlzCpjsJaZzO-9fjzqNRpWC0=.f286fec6-23d3-4fb1-b7f4-495ae57383d1@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <thTYaib7qsUcjKYs7x6wI4EiKMJYRxT5bqOECcmy9oo=.710d8143-7fc6-4cfa-a07d-04e98b341d58@github.com>
 <4D0sWW9SiN-hzeWLnadmlzCpjsJaZzO-9fjzqNRpWC0=.f286fec6-23d3-4fb1-b7f4-495ae57383d1@github.com>
Message-ID: <novQQKznVFiUdso75Gplrfd5RuUWCksRiXpYl1AqjNs=.36bcdf16-2adb-425b-b2e3-ef5286062e58@github.com>

On Wed, 13 Apr 2022 04:24:41 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I've done some work on add test cases for these new static factory methods, and I've also added API notes to the capacity-based constructors to link to the new factory methods. Note that even though these are javadoc changes, the API notes are non-normative and don't require an update to the CSR. See the last few commits on this branch:
> 
> https://github.com/stuart-marks/jdk/commits/JDK-8186958-presized-HashMap
> 
> If you think they're good, please pull them in.
> 
> Regarding the scope of changes, the number of call sites that are changed is indeed spread rather too widely across the JDK. In order to keep the number of required reviewers small, I think we should trim down the call sites to a more manageable set. Specifically, I'd suggest **removing** from this PR the changes from the files in the following areas:
> 
> * src/java.desktop
> * src/java.management
> * src/jdk.internal.vm.ci
> * src/jdk.jfr
> * src/jdk.management.jfr
> * src/jdk.management
> * src/utils/IdealGraphVisualizer

@stuart-marks done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From simonis at openjdk.java.net  Wed Apr 13 17:42:57 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 13 Apr 2022 17:42:57 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v7]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Updated wording based on @LanceAndersen's review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/52524353..c9b60404

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=05-06

  Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Wed Apr 13 17:42:58 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 13 Apr 2022 17:42:58 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v6]
In-Reply-To: <5muQMeD8W5plaSjqrVGrTeQSbHDBql-qo89c3dYMZBQ=.5b52edcc-d93d-4bda-9e20-5d2ee3e701db@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <TuXbetbsrsHFEoz8_eNCix5umCKZZhrN71IDeXxOgoQ=.7ecfc409-ec7a-4da4-995e-e056a6255730@github.com>
 <5muQMeD8W5plaSjqrVGrTeQSbHDBql-qo89c3dYMZBQ=.5b52edcc-d93d-4bda-9e20-5d2ee3e701db@github.com>
Message-ID: <ZI6QISGn3Hvh-44igOcrlazZJYaIFZN90n9n86pQ6KU=.fe19682d-b6c6-4bcf-8f85-56393379278a@github.com>

On Tue, 12 Apr 2022 18:12:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 103:
> 
>> 101:      * elements {@code buf[off+}<i>n</i>{@code ]} through {@code buf[off+}<i>len</i>{@code -1]}
>> 102:      * are undefined (an implementation is free to change them during the inflate
>> 103:      * operation). If the return value is -1 or an exception is thrown then {@code buf[off]}
> 
> perhaps tweak "... is thrown then" 
> 
> to
> 
> "... is thrown, then the contents of..."

Updated as requested (also in `ZipInputStream` and `InflaterInputStream`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From lancea at openjdk.java.net  Wed Apr 13 17:51:21 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 13 Apr 2022 17:51:21 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v7]
In-Reply-To: <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
Message-ID: <fu9p6ncNtxmpEkhgPOb7ddaxhIAtV3nAFZ_XJjhGHA0=.a6cc0480-b1c6-42ee-a69d-026d3b44ace0@github.com>

On Wed, 13 Apr 2022 17:42:57 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @LanceAndersen's review

Hi Volker,

The updates look good.  Thank you.   Next up is updating the CSR with the changes and craft the release-note as a subtask.

Thank you for your efforts here

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Wed Apr 13 18:15:15 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 13 Apr 2022 18:15:15 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v3]
In-Reply-To: <PcZAPt4TDKMHBHVh8-lm8tpWdRZWq3o5KMdIiGjcFJE=.87277867-ec31-4ed2-a67c-87bc50122429@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <hle3CzoC0pII6-hQjg-WpRXGY-vAk4m5iw3Oo7BlEsA=.82c931d4-a2e6-4ce1-9451-94ebba2a1927@github.com>
 <PcZAPt4TDKMHBHVh8-lm8tpWdRZWq3o5KMdIiGjcFJE=.87277867-ec31-4ed2-a67c-87bc50122429@github.com>
Message-ID: <sHNEpJ7SZpqWTzlaNm2mMUB7_4meaq8F1Sl62dUKi0Q=.70e14d22-5a19-4507-8773-355db25d63a7@github.com>

On Sun, 3 Apr 2022 19:04:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extended API-doc based on reviewer feedback
>
> A suggestion for the structure is to start the new paragraph by saying it reads n bytes of uncompressed data into b[off] to b[off+n-1]. Then follow to say that the contents of b[n] to b[off+len-1] after the read are are undefined, then say that an implementation is free to ...   Finally just finish it by saying that the contents are also undefined when the method fails by throwing an exception.

Thanks @AlanBateman, @LanceAndersen. I've just updated the CSR with the latest wording from this PR. Please feel free to review the CSR as well so I can finalize it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From duke at openjdk.java.net  Wed Apr 13 19:01:26 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 19:01:26 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
Message-ID: <U-jzPFM6B0Wx0qHnizFf1GJupdKk0P7d45AoLWRUdJk=.9e04080c-0b7d-439e-b5d2-f77620d170c9@github.com>

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Typo fix; add implSpec to Executable.
>  - Appease jcheck.
>  - Fix some bugs found by inspection, docs cleanup.
>  - Merge branch 'master' into JDK-8266670
>  - Initial support for accessFlags methods
>  - Add mask to access flag functionality.
>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/0053820b...14980605

Here, I argue for the case of splitting different types of access flags into distinct enums, such as `MemberAccessFlag`, `ModuleRequiresAccessFlag`, `ModuleExportsAccessFlag` implementing a sealed interface `AccessFlag` that keeps all its existing methods, since most of those access flags will never be returned in the same collection. The `accessFlags()` method should return a `Set<? extends AccessFlag>`, which is 1. safe as the set is read-only; 2. can be overridden with `Set<? extends MemberAccessFlag>` (For forward compability, we can make `MemberAccessFlag` an interface with static final fields, implemented by some package-private enum in case we want to split it into more specific types down the road).

But you may ask, what about `SYNTHETIC`, `MANDATED`, `FINAL`? Aren't they shared by almost all of the locations? What if users test with incorrect enum instance, such as looking for the `MemberAccessFlag.SYNTHETIC` in `moduleDescriptor.accessFlags()`?

This problem can be prevented:
1. by making `ModuleDescriptor.accessFlags()` return `Set<? extends ModuleDescriptorAccessFlag>`, thus the IDE can easily detect misuse when they insert the access flag of a different type;
2. In the current hodgepodge `AccessFlag`, we have `STATIC` and `STATIC_PHASE`, and the incorrect `ModuleDescriptor.accessFlags().contains(AccessFlag.STATIC)` call is much more subtle, especially to new users of this class. Arguably, this misuse would be way worse than that in the distinct enum case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From smarks at openjdk.java.net  Wed Apr 13 19:31:18 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 19:31:18 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
Message-ID: <tyREZE5_pIE3fSFQ00_rWQqm3PuMcbtv5HpmUnHebkk=.9779c0a0-a489-4dd0-a5db-dbf3cfd5ef74@github.com>

On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in:
>   src/java.desktop
>   src/java.management
>   src/jdk.internal.vm.ci
>   src/jdk.jfr
>   src/jdk.management.jfr
>   src/jdk.management
>   src/utils/IdealGraphVisualizer

Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From naoto at openjdk.java.net  Wed Apr 13 20:10:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Apr 2022 20:10:11 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
Message-ID: <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>

On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in:
>   src/java.desktop
>   src/java.management
>   src/jdk.internal.vm.ci
>   src/jdk.jfr
>   src/jdk.management.jfr
>   src/jdk.management
>   src/utils/IdealGraphVisualizer

Looks good for changes in i18n related call sites, assuming that the copyright years will be updated.

Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`?

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

From aturbanov at openjdk.java.net  Wed Apr 13 20:45:35 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Apr 2022 20:45:35 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
Message-ID: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>

Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

-------------

Commit messages:
 - [PATCH] Fix 'expected' typo
 - [PATCH] Fix 'expected' typo
 - [PATCH] Fix 'expected' typo

Changes: https://git.openjdk.java.net/jdk/pull/8231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284853
  Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231

PR: https://git.openjdk.java.net/jdk/pull/8231

From joehw at openjdk.java.net  Wed Apr 13 21:05:23 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 13 Apr 2022 21:05:23 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
Message-ID: <21Zq0-bQTy5fAlxd-WnsAp-JQ6DwJ5HO4ceFTN3zCRQ=.98cd3042-cbe2-4c6a-9647-7762fcb20d89@github.com>

On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in:
>   src/java.desktop
>   src/java.management
>   src/jdk.internal.vm.ci
>   src/jdk.jfr
>   src/jdk.management.jfr
>   src/jdk.management
>   src/utils/IdealGraphVisualizer

Looks good for the changes in java.xml, like Naoto, assuming copyright years and the LastModified tag are updated. I generally prefer for the source level to stay at 8 as the upstream source is maintained at an older JDK level, but these changes seem to be small enough to tolerate.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr 13 21:18:16 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 13 Apr 2022 21:18:16 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
Message-ID: <eeadqA6W7ZISwLR883ubuOYGApklylyMqdEMBJuh3zs=.083f410d-e7dc-4110-8d86-e9f98d7b538b@github.com>

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Typo fix; add implSpec to Executable.
>  - Appease jcheck.
>  - Fix some bugs found by inspection, docs cleanup.
>  - Merge branch 'master' into JDK-8266670
>  - Initial support for accessFlags methods
>  - Add mask to access flag functionality.
>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/364bd126...14980605

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167:

> 165:              * but is optional in the dynamic phase, during execution.
> 166:              */
> 167:             STATIC(AccessFlag.STATIC.mask()),

This?is?actually `AccessFlag.STATIC_PHASE`?(`0x0040`), and?not `AccessFlag.STATIC`?(`0x0008`):
Suggestion:

            STATIC(AccessFlag.STATIC_PHASE.mask()),

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From duke at openjdk.java.net  Wed Apr 13 21:25:20 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 21:25:20 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <eeadqA6W7ZISwLR883ubuOYGApklylyMqdEMBJuh3zs=.083f410d-e7dc-4110-8d86-e9f98d7b538b@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
 <eeadqA6W7ZISwLR883ubuOYGApklylyMqdEMBJuh3zs=.083f410d-e7dc-4110-8d86-e9f98d7b538b@github.com>
Message-ID: <uwKxB1M0800i9rzeM0cn8CuZxRqUzJlRtPu0rWsDZq0=.9df6ee52-6bac-409b-ad77-393c814cd265@github.com>

On Wed, 13 Apr 2022 21:12:40 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Make workding changes suggested in review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Typo fix; add implSpec to Executable.
>>  - Appease jcheck.
>>  - Fix some bugs found by inspection, docs cleanup.
>>  - Merge branch 'master' into JDK-8266670
>>  - Initial support for accessFlags methods
>>  - Add mask to access flag functionality.
>>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/afd02683...14980605
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167:
> 
>> 165:              * but is optional in the dynamic phase, during execution.
>> 166:              */
>> 167:             STATIC(AccessFlag.STATIC.mask()),
> 
> This?is?actually `AccessFlag.STATIC_PHASE`?(`0x0040`), and?not `AccessFlag.STATIC`?(`0x0008`):
> Suggestion:
> 
>             STATIC(AccessFlag.STATIC_PHASE.mask()),

> In the current hodgepodge AccessFlag, we have STATIC and STATIC_PHASE, and the incorrect ModuleDescriptor.accessFlags().contains(AccessFlag.STATIC) call is much more subtle, especially to new users of this class. Arguably, this misuse would be way worse than that in the distinct enum case.

Oops, didn't know this already happened. Good spot right there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From lancea at openjdk.java.net  Wed Apr 13 21:26:15 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 13 Apr 2022 21:26:15 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
Message-ID: <zaLc73nUF0KwecqGKR700uZrqqbeNHkL5CaILJO7g7Q=.48bf66a8-5baf-49c2-8ec4-8caaf8145ac3@github.com>

On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes in:
>   src/java.desktop
>   src/java.management
>   src/jdk.internal.vm.ci
>   src/jdk.jfr
>   src/jdk.management.jfr
>   src/jdk.management
>   src/utils/IdealGraphVisualizer

The ZipFS and Jar changes seem OK

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

From mcimadamore at openjdk.java.net  Wed Apr 13 21:30:17 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 13 Apr 2022 21:30:17 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v27]
In-Reply-To: <sdmzFLNIr3ABlN8AGMEpMu-9QEpLpu8jUmjpZblPoNg=.c247b3d6-6a2c-49d8-8e85-8287437b1e8c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <kDrY0W07ctgywiR9pbjRpQ6laLhdC3440xMoYVMo9XQ=.1d97c792-c1d0-45bd-a5f9-d64f1993e83c@github.com>
 <sdmzFLNIr3ABlN8AGMEpMu-9QEpLpu8jUmjpZblPoNg=.c247b3d6-6a2c-49d8-8e85-8287437b1e8c@github.com>
Message-ID: <JcktL-l7Vh88jyCdqs7RmDxOWYB4gUr0EAruSHo7uDs=.4d9c4a7a-780a-4ac0-b74f-7062994b9de4@github.com>

On Wed, 13 Apr 2022 16:12:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @ForceInline annotation on session accessor
>>   Beef up UnrolledAccess benchmark
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052:
> 
>> 1050:     public MemorySegment map(MapMode mode, long offset, long size,
>> 1051:                                       MemorySession session)
>> 1052:             throws IOException, UnsupportedOperationException
> 
> Just a minor here is that UOE is a runtime exception so probably shouldn't be in the throws.

whoops - good catch - will fix!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Wed Apr 13 21:35:07 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 13 Apr 2022 21:35:07 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v28]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <Tx8fkcthejSAQgTHhcIDGfr6yDgCKAUjDQbwL3bKV_A=.1b536e9a-ee0a-4b98-ab09-e5f35c4f7c5b@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop `UnsupportedOperationException` from throws clause in FileChannel/FileChannelImpl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/66cebe77..3a87df5e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=27
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=26-27

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Wed Apr 13 21:36:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 13 Apr 2022 21:36:58 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v29]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <CjDv3YYnnjWcuoSZ5p6lV9Mh8D6-7T_A0kePY2zGoII=.9cd91eb9-ad7a-4615-898f-8c99bc9fad38@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove whitespaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/3a87df5e..8637379e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=28
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=27-28

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Wed Apr 13 21:58:06 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 21:58:06 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add jmh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/85cec668..7a9844cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=02-03

  Stats: 288 lines in 1 file changed: 288 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 21:58:06 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 21:58:06 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <84YsekICpjY77dhw3Tx9QLKlO1EHQ01kuIlZEXKgTXQ=.e3692542-d8bb-49e2-9949-6a1ff292e9a5@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
 <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
 <84YsekICpjY77dhw3Tx9QLKlO1EHQ01kuIlZEXKgTXQ=.e3692542-d8bb-49e2-9949-6a1ff292e9a5@github.com>
Message-ID: <rJTc8DtyHXr8x0Z0U15AAcB-ihSb5ibwP05T2NUhxEg=.08f07667-9550-4256-a57f-278c6367eea4@github.com>

On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
>>> 
>>> Is there anything different in the situations about skipBuffer in Reader and InputStream?
>> 
>> Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.
>
>> @AlanBateman Is the concern about holding more memory sufficient to retain the buffer using a SoftReference so it can be freed eagerly?
>> These buffers are never read from, so are quite a waste, but at least they are only used when
>> the underlying stream overrides skip.
> 
> Maybe but I think it needs some benchmarks to know if caching a byte[] will help or just bloat memory. If the InputStream is to a file or socket then maybe skip is dominated by the I/O rather than the array allocation and zero'ing.

@AlanBateman jmh test added

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 13 21:58:07 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 21:58:07 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v3]
In-Reply-To: <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <_ae02AqBCeNAMyggFV-30n_rVzICDug7CtNco56mnT8=.d650594b-af02-48ce-be09-f61ed08eeaad@github.com>
Message-ID: <sPuHC_cEssy6uIgtsTEdjdN2oEm7uVR7nHNT1MuntO4=.eb091842-dc27-43ef-8b32-3ade427c8357@github.com>

On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving nr declaration from the beginning of the method to where it's actually used

# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 1)

# Run progress: 0.00% complete, ETA 00:14:00
# Fork: 1 of 3
# Warmup Iteration   1: 3188201.250 ns/op
# Warmup Iteration   2: 2445386.603 ns/op
# Warmup Iteration   3: 2395206.481 ns/op
# Warmup Iteration   4: 2391797.196 ns/op
# Warmup Iteration   5: 2518698.039 ns/op
# Warmup Iteration   6: 2414542.254 ns/op
# Warmup Iteration   7: 2419808.019 ns/op
# Warmup Iteration   8: 2430526.540 ns/op
# Warmup Iteration   9: 2430806.635 ns/op
# Warmup Iteration  10: 2414558.173 ns/op
Iteration   1: 2426910.427 ns/op
Iteration   2: 2429144.811 ns/op
Iteration   3: 2574322.500 ns/op
Iteration   4: 2396079.907 ns/op
Iteration   5: 2425966.509 ns/op
Iteration   6: 2461450.239 ns/op
Iteration   7: 2527480.392 ns/op
Iteration   8: 2523890.640 ns/op
Iteration   9: 2511460.488 ns/op
Iteration  10: 2532332.843 ns/op

# Run progress: 1.19% complete, ETA 00:14:36
# Fork: 2 of 3
# Warmup Iteration   1: 3174534.969 ns/op
# Warmup Iteration   2: 2499138.235 ns/op
# Warmup Iteration   3: 2421553.521 ns/op
# Warmup Iteration   4: 2416571.698 ns/op
# Warmup Iteration   5: 2384638.889 ns/op
# Warmup Iteration   6: 2377448.387 ns/op
# Warmup Iteration   7: 2395746.512 ns/op
# Warmup Iteration   8: 2384657.209 ns/op
# Warmup Iteration   9: 2403249.302 ns/op
# Warmup Iteration  10: 2397511.163 ns/op
Iteration   1: 2386731.481 ns/op
Iteration   2: 2418383.491 ns/op
Iteration   3: 2394599.535 ns/op
Iteration   4: 2436117.536 ns/op
Iteration   5: 2399048.357 ns/op
Iteration   6: 2483871.498 ns/op
Iteration   7: 2496279.612 ns/op
Iteration   8: 2496743.204 ns/op
Iteration   9: 2491237.811 ns/op
Iteration  10: 2493390.338 ns/op

# Run progress: 2.38% complete, ETA 00:14:25
# Fork: 3 of 3
# Warmup Iteration   1: 3677115.714 ns/op
# Warmup Iteration   2: 2423365.877 ns/op
# Warmup Iteration   3: 2480975.962 ns/op
# Warmup Iteration   4: 2412990.610 ns/op
# Warmup Iteration   5: 2433951.185 ns/op
# Warmup Iteration   6: 2389266.190 ns/op
# Warmup Iteration   7: 2407245.933 ns/op
# Warmup Iteration   8: 2375563.721 ns/op
# Warmup Iteration   9: 2388543.981 ns/op
# Warmup Iteration  10: 2393794.419 ns/op
Iteration   1: 2403104.306 ns/op
Iteration   2: 2414766.355 ns/op
Iteration   3: 2408296.667 ns/op
Iteration   4: 2509554.412 ns/op
Iteration   5: 2402212.440 ns/op
Iteration   6: 2436674.272 ns/op
Iteration   7: 2466500.000 ns/op
Iteration   8: 2472919.712 ns/op
Iteration   9: 2462019.139 ns/op
Iteration  10: 2453551.905 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  2457834.694 ?(99.9%) 33354.477 ns/op [Average]
  (min, avg, max) = (2386731.481, 2457834.694, 2574322.500), stdev = 49923.415
  CI (99.9%): [2424480.217, 2491189.172] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 8)

# Run progress: 3.57% complete, ETA 00:14:13
# Fork: 1 of 3
# Warmup Iteration   1: 432960.511 ns/op
# Warmup Iteration   2: 336604.734 ns/op
# Warmup Iteration   3: 330185.843 ns/op
# Warmup Iteration   4: 325184.675 ns/op
# Warmup Iteration   5: 328446.641 ns/op
# Warmup Iteration   6: 327902.621 ns/op
# Warmup Iteration   7: 330808.786 ns/op
# Warmup Iteration   8: 347259.824 ns/op
# Warmup Iteration   9: 325685.010 ns/op
# Warmup Iteration  10: 327215.911 ns/op
Iteration   1: 326363.255 ns/op
Iteration   2: 328112.283 ns/op
Iteration   3: 328520.409 ns/op
Iteration   4: 328192.298 ns/op
Iteration   5: 340780.468 ns/op
Iteration   6: 343513.740 ns/op
Iteration   7: 339350.495 ns/op
Iteration   8: 342972.315 ns/op
Iteration   9: 344445.097 ns/op
Iteration  10: 350693.452 ns/op

# Run progress: 4.76% complete, ETA 00:14:02
# Fork: 2 of 3
# Warmup Iteration   1: 503495.030 ns/op
# Warmup Iteration   2: 323265.522 ns/op
# Warmup Iteration   3: 325264.161 ns/op
# Warmup Iteration   4: 312467.682 ns/op
# Warmup Iteration   5: 307800.661 ns/op
# Warmup Iteration   6: 315526.290 ns/op
# Warmup Iteration   7: 302447.260 ns/op
# Warmup Iteration   8: 301606.959 ns/op
# Warmup Iteration   9: 304443.979 ns/op
# Warmup Iteration  10: 303558.949 ns/op
Iteration   1: 305632.977 ns/op
Iteration   2: 304706.452 ns/op
Iteration   3: 304734.752 ns/op
Iteration   4: 304647.030 ns/op
Iteration   5: 303296.986 ns/op
Iteration   6: 308326.426 ns/op
Iteration   7: 307861.538 ns/op
Iteration   8: 310309.671 ns/op
Iteration   9: 308256.783 ns/op
Iteration  10: 310094.610 ns/op

# Run progress: 5.95% complete, ETA 00:13:51
# Fork: 3 of 3
# Warmup Iteration   1: 423681.099 ns/op
# Warmup Iteration   2: 331443.907 ns/op
# Warmup Iteration   3: 325272.884 ns/op
# Warmup Iteration   4: 326737.206 ns/op
# Warmup Iteration   5: 327400.978 ns/op
# Warmup Iteration   6: 333933.247 ns/op
# Warmup Iteration   7: 334043.381 ns/op
# Warmup Iteration   8: 324878.689 ns/op
# Warmup Iteration   9: 326202.222 ns/op
# Warmup Iteration  10: 324154.253 ns/op
Iteration   1: 324469.987 ns/op
Iteration   2: 321729.508 ns/op
Iteration   3: 327916.008 ns/op
Iteration   4: 323248.774 ns/op
Iteration   5: 327260.817 ns/op
Iteration   6: 335050.000 ns/op
Iteration   7: 334465.887 ns/op
Iteration   8: 332373.493 ns/op
Iteration   9: 332774.758 ns/op
Iteration  10: 334466.124 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  324485.546 ?(99.9%) 9594.651 ns/op [Average]
  (min, avg, max) = (303296.986, 324485.546, 350693.452), stdev = 14360.823
  CI (99.9%): [314890.895, 334080.198] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 32)

# Run progress: 7.14% complete, ETA 00:13:42
# Fork: 1 of 3
# Warmup Iteration   1: 157982.625 ns/op
# Warmup Iteration   2: 118242.606 ns/op
# Warmup Iteration   3: 118988.755 ns/op
# Warmup Iteration   4: 116650.870 ns/op
# Warmup Iteration   5: 116501.544 ns/op
# Warmup Iteration   6: 117494.746 ns/op
# Warmup Iteration   7: 116678.389 ns/op
# Warmup Iteration   8: 119845.086 ns/op
# Warmup Iteration   9: 124761.701 ns/op
# Warmup Iteration  10: 131184.009 ns/op
Iteration   1: 127549.720 ns/op
Iteration   2: 128505.980 ns/op
Iteration   3: 124631.989 ns/op
Iteration   4: 124192.308 ns/op
Iteration   5: 124832.198 ns/op
Iteration   6: 121911.619 ns/op
Iteration   7: 122014.377 ns/op
Iteration   8: 120072.613 ns/op
Iteration   9: 119579.097 ns/op
Iteration  10: 120206.452 ns/op

# Run progress: 8.33% complete, ETA 00:13:31
# Fork: 2 of 3
# Warmup Iteration   1: 154871.139 ns/op
# Warmup Iteration   2: 122151.482 ns/op
# Warmup Iteration   3: 115675.248 ns/op
# Warmup Iteration   4: 116348.184 ns/op
# Warmup Iteration   5: 117370.941 ns/op
# Warmup Iteration   6: 116512.639 ns/op
# Warmup Iteration   7: 117318.053 ns/op
# Warmup Iteration   8: 117803.068 ns/op
# Warmup Iteration   9: 117686.096 ns/op
# Warmup Iteration  10: 116044.860 ns/op
Iteration   1: 116761.451 ns/op
Iteration   2: 117445.679 ns/op
Iteration   3: 116673.003 ns/op
Iteration   4: 115562.183 ns/op
Iteration   5: 116082.398 ns/op
Iteration   6: 118057.978 ns/op
Iteration   7: 120118.816 ns/op
Iteration   8: 120141.873 ns/op
Iteration   9: 122371.829 ns/op
Iteration  10: 119617.317 ns/op

# Run progress: 9.52% complete, ETA 00:13:21
# Fork: 3 of 3
# Warmup Iteration   1: 153774.641 ns/op
# Warmup Iteration   2: 118236.151 ns/op
# Warmup Iteration   3: 118701.089 ns/op
# Warmup Iteration   4: 117544.991 ns/op
# Warmup Iteration   5: 118908.965 ns/op
# Warmup Iteration   6: 116556.597 ns/op
# Warmup Iteration   7: 116960.708 ns/op
# Warmup Iteration   8: 117323.268 ns/op
# Warmup Iteration   9: 118292.823 ns/op
# Warmup Iteration  10: 118358.750 ns/op
Iteration   1: 119093.418 ns/op
Iteration   2: 119664.406 ns/op
Iteration   3: 119291.078 ns/op
Iteration   4: 119179.563 ns/op
Iteration   5: 119678.926 ns/op
Iteration   6: 120095.905 ns/op
Iteration   7: 119978.473 ns/op
Iteration   8: 119794.866 ns/op
Iteration   9: 119378.122 ns/op
Iteration  10: 120919.192 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  120446.761 ?(99.9%) 2038.143 ns/op [Average]
  (min, avg, max) = (115562.183, 120446.761, 128505.980), stdev = 3050.596
  CI (99.9%): [118408.618, 122484.903] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 128)

# Run progress: 10.71% complete, ETA 00:13:10
# Fork: 1 of 3
# Warmup Iteration   1: 102663.829 ns/op
# Warmup Iteration   2: 83648.860 ns/op
# Warmup Iteration   3: 78914.332 ns/op
# Warmup Iteration   4: 78855.969 ns/op
# Warmup Iteration   5: 78423.452 ns/op
# Warmup Iteration   6: 79308.987 ns/op
# Warmup Iteration   7: 79245.060 ns/op
# Warmup Iteration   8: 78493.284 ns/op
# Warmup Iteration   9: 79586.881 ns/op
# Warmup Iteration  10: 77774.863 ns/op
Iteration   1: 80046.149 ns/op
Iteration   2: 77178.902 ns/op
Iteration   3: 77045.684 ns/op
Iteration   4: 77329.515 ns/op
Iteration   5: 77123.399 ns/op
Iteration   6: 80490.295 ns/op
Iteration   7: 82318.670 ns/op
Iteration   8: 82269.526 ns/op
Iteration   9: 83190.164 ns/op
Iteration  10: 83596.219 ns/op

# Run progress: 11.90% complete, ETA 00:12:59
# Fork: 2 of 3
# Warmup Iteration   1: 109741.726 ns/op
# Warmup Iteration   2: 81610.000 ns/op
# Warmup Iteration   3: 77431.550 ns/op
# Warmup Iteration   4: 77795.449 ns/op
# Warmup Iteration   5: 77021.062 ns/op
# Warmup Iteration   6: 77504.265 ns/op
# Warmup Iteration   7: 79110.988 ns/op
# Warmup Iteration   8: 78471.372 ns/op
# Warmup Iteration   9: 79013.571 ns/op
# Warmup Iteration  10: 76824.813 ns/op
Iteration   1: 77220.497 ns/op
Iteration   2: 76968.315 ns/op
Iteration   3: 77452.563 ns/op
Iteration   4: 77063.835 ns/op
Iteration   5: 77165.763 ns/op
Iteration   6: 77498.838 ns/op
Iteration   7: 79278.259 ns/op
Iteration   8: 81120.645 ns/op
Iteration   9: 80998.644 ns/op
Iteration  10: 81013.150 ns/op

# Run progress: 13.10% complete, ETA 00:12:48
# Fork: 3 of 3
# Warmup Iteration   1: 102657.228 ns/op
# Warmup Iteration   2: 83686.451 ns/op
# Warmup Iteration   3: 79767.733 ns/op
# Warmup Iteration   4: 79342.178 ns/op
# Warmup Iteration   5: 79293.307 ns/op
# Warmup Iteration   6: 79669.975 ns/op
# Warmup Iteration   7: 78855.248 ns/op
# Warmup Iteration   8: 79944.160 ns/op
# Warmup Iteration   9: 79307.401 ns/op
# Warmup Iteration  10: 79501.854 ns/op
Iteration   1: 77225.988 ns/op
Iteration   2: 76637.151 ns/op
Iteration   3: 77185.755 ns/op
Iteration   4: 76765.182 ns/op
Iteration   5: 77099.521 ns/op
Iteration   6: 78191.114 ns/op
Iteration   7: 78648.578 ns/op
Iteration   8: 79591.636 ns/op
Iteration   9: 81063.063 ns/op
Iteration  10: 80659.528 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  78981.218 ?(99.9%) 1455.232 ns/op [Average]
  (min, avg, max) = (76637.151, 78981.218, 83596.219), stdev = 2178.122
  CI (99.9%): [77525.987, 80436.450] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 512)

# Run progress: 14.29% complete, ETA 00:12:38
# Fork: 1 of 3
# Warmup Iteration   1: 110284.355 ns/op
# Warmup Iteration   2: 87845.780 ns/op
# Warmup Iteration   3: 86279.993 ns/op
# Warmup Iteration   4: 86616.478 ns/op
# Warmup Iteration   5: 86007.761 ns/op
# Warmup Iteration   6: 86624.126 ns/op
# Warmup Iteration   7: 86011.156 ns/op
# Warmup Iteration   8: 86494.165 ns/op
# Warmup Iteration   9: 86150.461 ns/op
# Warmup Iteration  10: 87206.396 ns/op
Iteration   1: 86158.701 ns/op
Iteration   2: 86814.809 ns/op
Iteration   3: 86391.159 ns/op
Iteration   4: 86420.481 ns/op
Iteration   5: 86192.492 ns/op
Iteration   6: 86387.883 ns/op
Iteration   7: 86515.532 ns/op
Iteration   8: 86804.092 ns/op
Iteration   9: 92068.945 ns/op
Iteration  10: 94226.402 ns/op

# Run progress: 15.48% complete, ETA 00:12:27
# Fork: 2 of 3
# Warmup Iteration   1: 125421.884 ns/op
# Warmup Iteration   2: 104713.860 ns/op
# Warmup Iteration   3: 92435.580 ns/op
# Warmup Iteration   4: 93801.039 ns/op
# Warmup Iteration   5: 91955.016 ns/op
# Warmup Iteration   6: 89863.662 ns/op
# Warmup Iteration   7: 89482.934 ns/op
# Warmup Iteration   8: 89784.940 ns/op
# Warmup Iteration   9: 89200.178 ns/op
# Warmup Iteration  10: 92073.483 ns/op
Iteration   1: 90659.436 ns/op
Iteration   2: 89330.763 ns/op
Iteration   3: 88061.523 ns/op
Iteration   4: 89087.350 ns/op
Iteration   5: 90807.571 ns/op
Iteration   6: 89006.133 ns/op
Iteration   7: 89833.473 ns/op
Iteration   8: 86286.802 ns/op
Iteration   9: 87186.204 ns/op
Iteration  10: 87149.704 ns/op

# Run progress: 16.67% complete, ETA 00:12:16
# Fork: 3 of 3
# Warmup Iteration   1: 112808.804 ns/op
# Warmup Iteration   2: 88255.384 ns/op
# Warmup Iteration   3: 87005.771 ns/op
# Warmup Iteration   4: 87296.134 ns/op
# Warmup Iteration   5: 86430.054 ns/op
# Warmup Iteration   6: 86560.017 ns/op
# Warmup Iteration   7: 86641.664 ns/op
# Warmup Iteration   8: 87761.186 ns/op
# Warmup Iteration   9: 86926.524 ns/op
# Warmup Iteration  10: 87537.658 ns/op
Iteration   1: 88463.151 ns/op
Iteration   2: 88457.574 ns/op
Iteration   3: 88471.720 ns/op
Iteration   4: 87268.556 ns/op
Iteration   5: 87252.555 ns/op
Iteration   6: 89661.423 ns/op
Iteration   7: 91098.844 ns/op
Iteration   8: 89373.957 ns/op
Iteration   9: 89355.994 ns/op
Iteration  10: 87744.177 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  88417.914 ?(99.9%) 1324.450 ns/op [Average]
  (min, avg, max) = (86158.701, 88417.914, 94226.402), stdev = 1982.375
  CI (99.9%): [87093.463, 89742.364] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 2048)

# Run progress: 17.86% complete, ETA 00:12:06
# Fork: 1 of 3
# Warmup Iteration   1: 102055.637 ns/op
# Warmup Iteration   2: 83953.095 ns/op
# Warmup Iteration   3: 81054.527 ns/op
# Warmup Iteration   4: 81460.215 ns/op
# Warmup Iteration   5: 81400.711 ns/op
# Warmup Iteration   6: 80534.898 ns/op
# Warmup Iteration   7: 82214.429 ns/op
# Warmup Iteration   8: 79675.975 ns/op
# Warmup Iteration   9: 80020.870 ns/op
# Warmup Iteration  10: 79895.252 ns/op
Iteration   1: 80148.246 ns/op
Iteration   2: 80310.782 ns/op
Iteration   3: 80039.960 ns/op
Iteration   4: 79770.754 ns/op
Iteration   5: 79818.343 ns/op
Iteration   6: 81146.106 ns/op
Iteration   7: 82810.122 ns/op
Iteration   8: 82839.421 ns/op
Iteration   9: 82310.678 ns/op
Iteration  10: 80088.597 ns/op

# Run progress: 19.05% complete, ETA 00:11:55
# Fork: 2 of 3
# Warmup Iteration   1: 102615.678 ns/op
# Warmup Iteration   2: 82043.463 ns/op
# Warmup Iteration   3: 79697.718 ns/op
# Warmup Iteration   4: 80145.736 ns/op
# Warmup Iteration   5: 80305.335 ns/op
# Warmup Iteration   6: 81131.083 ns/op
# Warmup Iteration   7: 79974.670 ns/op
# Warmup Iteration   8: 79974.868 ns/op
# Warmup Iteration   9: 79699.256 ns/op
# Warmup Iteration  10: 80816.486 ns/op
Iteration   1: 82163.022 ns/op
Iteration   2: 81062.705 ns/op
Iteration   3: 80207.153 ns/op
Iteration   4: 81797.205 ns/op
Iteration   5: 84417.675 ns/op
Iteration   6: 80766.897 ns/op
Iteration   7: 80014.765 ns/op
Iteration   8: 80701.136 ns/op
Iteration   9: 80743.715 ns/op
Iteration  10: 80494.425 ns/op

# Run progress: 20.24% complete, ETA 00:11:45
# Fork: 3 of 3
# Warmup Iteration   1: 104127.774 ns/op
# Warmup Iteration   2: 84746.915 ns/op
# Warmup Iteration   3: 86138.469 ns/op
# Warmup Iteration   4: 87681.478 ns/op
# Warmup Iteration   5: 84842.044 ns/op
# Warmup Iteration   6: 83701.255 ns/op
# Warmup Iteration   7: 82922.666 ns/op
# Warmup Iteration   8: 83111.535 ns/op
# Warmup Iteration   9: 83815.198 ns/op
# Warmup Iteration  10: 82283.971 ns/op
Iteration   1: 82810.192 ns/op
Iteration   2: 82679.581 ns/op
Iteration   3: 83454.692 ns/op
Iteration   4: 82988.826 ns/op
Iteration   5: 82807.421 ns/op
Iteration   6: 83196.126 ns/op
Iteration   7: 83579.131 ns/op
Iteration   8: 82080.933 ns/op
Iteration   9: 82578.360 ns/op
Iteration  10: 83344.252 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  81705.707 ?(99.9%) 920.354 ns/op [Average]
  (min, avg, max) = (79770.754, 81705.707, 84417.675), stdev = 1377.543
  CI (99.9%): [80785.353, 82626.062] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0
# Parameters: (inputStreamSize = 1000000, skipLength = 8192)

# Run progress: 21.43% complete, ETA 00:11:34
# Fork: 1 of 3
# Warmup Iteration   1: 26489.399 ns/op
# Warmup Iteration   2: 20772.307 ns/op
# Warmup Iteration   3: 20483.216 ns/op
# Warmup Iteration   4: 20574.444 ns/op
# Warmup Iteration   5: 20634.652 ns/op
# Warmup Iteration   6: 20914.959 ns/op
# Warmup Iteration   7: 20702.594 ns/op
# Warmup Iteration   8: 20567.134 ns/op
# Warmup Iteration   9: 21063.642 ns/op
# Warmup Iteration  10: 20678.942 ns/op
Iteration   1: 20854.266 ns/op
Iteration   2: 20827.427 ns/op
Iteration   3: 21071.932 ns/op
Iteration   4: 20818.294 ns/op
Iteration   5: 21002.478 ns/op
Iteration   6: 21187.056 ns/op
Iteration   7: 20785.493 ns/op
Iteration   8: 21084.103 ns/op
Iteration   9: 20689.386 ns/op
Iteration  10: 21348.985 ns/op

# Run progress: 22.62% complete, ETA 00:11:24
# Fork: 2 of 3
# Warmup Iteration   1: 27175.485 ns/op
# Warmup Iteration   2: 20977.799 ns/op
# Warmup Iteration   3: 20391.248 ns/op
# Warmup Iteration   4: 20353.639 ns/op
# Warmup Iteration   5: 20575.407 ns/op
# Warmup Iteration   6: 20616.771 ns/op
# Warmup Iteration   7: 20574.437 ns/op
# Warmup Iteration   8: 20775.360 ns/op
# Warmup Iteration   9: 20537.898 ns/op
# Warmup Iteration  10: 20699.992 ns/op
Iteration   1: 20790.142 ns/op
Iteration   2: 20897.762 ns/op
Iteration   3: 21178.964 ns/op
Iteration   4: 20589.881 ns/op
Iteration   5: 20817.220 ns/op
Iteration   6: 20242.485 ns/op
Iteration   7: 20483.477 ns/op
Iteration   8: 20255.665 ns/op
Iteration   9: 20323.850 ns/op
Iteration  10: 20249.024 ns/op

# Run progress: 23.81% complete, ETA 00:11:13
# Fork: 3 of 3
# Warmup Iteration   1: 25386.842 ns/op
# Warmup Iteration   2: 20431.106 ns/op
# Warmup Iteration   3: 20256.294 ns/op
# Warmup Iteration   4: 20195.299 ns/op
# Warmup Iteration   5: 20128.312 ns/op
# Warmup Iteration   6: 20162.641 ns/op
# Warmup Iteration   7: 20195.761 ns/op
# Warmup Iteration   8: 20102.447 ns/op
# Warmup Iteration   9: 20219.653 ns/op
# Warmup Iteration  10: 20158.666 ns/op
Iteration   1: 20247.113 ns/op
Iteration   2: 20228.567 ns/op
Iteration   3: 20150.238 ns/op
Iteration   4: 20209.225 ns/op
Iteration   5: 20179.959 ns/op
Iteration   6: 20125.067 ns/op
Iteration   7: 20237.787 ns/op
Iteration   8: 20129.995 ns/op
Iteration   9: 20133.099 ns/op
Iteration  10: 20239.677 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip0":
  20579.287 ?(99.9%) 260.370 ns/op [Average]
  (min, avg, max) = (20125.067, 20579.287, 21348.985), stdev = 389.710
  CI (99.9%): [20318.917, 20839.658] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 1)

# Run progress: 25.00% complete, ETA 00:11:03
# Fork: 1 of 3
# Warmup Iteration   1: 1523456.213 ns/op
# Warmup Iteration   2: 1472994.236 ns/op
# Warmup Iteration   3: 1507210.557 ns/op
# Warmup Iteration   4: 1478360.807 ns/op
# Warmup Iteration   5: 1483629.769 ns/op
# Warmup Iteration   6: 1477262.931 ns/op
# Warmup Iteration   7: 1483323.563 ns/op
# Warmup Iteration   8: 1482942.486 ns/op
# Warmup Iteration   9: 1468771.429 ns/op
# Warmup Iteration  10: 1482198.844 ns/op
Iteration   1: 1473512.034 ns/op
Iteration   2: 1469536.103 ns/op
Iteration   3: 1472926.801 ns/op
Iteration   4: 1481235.447 ns/op
Iteration   5: 1474775.931 ns/op
Iteration   6: 1519975.740 ns/op
Iteration   7: 1526036.499 ns/op
Iteration   8: 1535044.478 ns/op
Iteration   9: 1536937.838 ns/op
Iteration  10: 1530933.433 ns/op

# Run progress: 26.19% complete, ETA 00:10:52
# Fork: 2 of 3
# Warmup Iteration   1: 1552555.556 ns/op
# Warmup Iteration   2: 1527709.009 ns/op
# Warmup Iteration   3: 1528438.279 ns/op
# Warmup Iteration   4: 1518343.195 ns/op
# Warmup Iteration   5: 1529964.179 ns/op
# Warmup Iteration   6: 1523591.445 ns/op
# Warmup Iteration   7: 1525374.184 ns/op
# Warmup Iteration   8: 1555876.061 ns/op
# Warmup Iteration   9: 1528672.997 ns/op
# Warmup Iteration  10: 1539299.102 ns/op
Iteration   1: 1537250.450 ns/op
Iteration   2: 1522923.669 ns/op
Iteration   3: 1547069.069 ns/op
Iteration   4: 1539041.617 ns/op
Iteration   5: 1522994.065 ns/op
Iteration   6: 1569674.618 ns/op
Iteration   7: 1601412.150 ns/op
Iteration   8: 1599402.795 ns/op
Iteration   9: 1594985.759 ns/op
Iteration  10: 1600359.502 ns/op

# Run progress: 27.38% complete, ETA 00:10:42
# Fork: 3 of 3
# Warmup Iteration   1: 1524622.121 ns/op
# Warmup Iteration   2: 1481929.107 ns/op
# Warmup Iteration   3: 1482453.097 ns/op
# Warmup Iteration   4: 1484176.012 ns/op
# Warmup Iteration   5: 1490247.688 ns/op
# Warmup Iteration   6: 1492335.015 ns/op
# Warmup Iteration   7: 1486042.241 ns/op
# Warmup Iteration   8: 1471062.286 ns/op
# Warmup Iteration   9: 1486252.802 ns/op
# Warmup Iteration  10: 1471295.308 ns/op
Iteration   1: 1474984.814 ns/op
Iteration   2: 1476571.976 ns/op
Iteration   3: 1490120.349 ns/op
Iteration   4: 1477158.453 ns/op
Iteration   5: 1475879.765 ns/op
Iteration   6: 1516047.892 ns/op
Iteration   7: 1544309.009 ns/op
Iteration   8: 1551311.712 ns/op
Iteration   9: 1545775.767 ns/op
Iteration  10: 1548329.321 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  1525217.235 ?(99.9%) 27978.461 ns/op [Average]
  (min, avg, max) = (1469536.103, 1525217.235, 1601412.150), stdev = 41876.847
  CI (99.9%): [1497238.774, 1553195.696] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 8)

# Run progress: 28.57% complete, ETA 00:10:31
# Fork: 1 of 3
# Warmup Iteration   1: 192351.609 ns/op
# Warmup Iteration   2: 189616.617 ns/op
# Warmup Iteration   3: 188225.852 ns/op
# Warmup Iteration   4: 188603.855 ns/op
# Warmup Iteration   5: 188402.449 ns/op
# Warmup Iteration   6: 189370.562 ns/op
# Warmup Iteration   7: 188774.681 ns/op
# Warmup Iteration   8: 188737.542 ns/op
# Warmup Iteration   9: 188681.259 ns/op
# Warmup Iteration  10: 190408.207 ns/op
Iteration   1: 188971.941 ns/op
Iteration   2: 189903.754 ns/op
Iteration   3: 189887.533 ns/op
Iteration   4: 188621.447 ns/op
Iteration   5: 189700.981 ns/op
Iteration   6: 193320.978 ns/op
Iteration   7: 196261.000 ns/op
Iteration   8: 195928.457 ns/op
Iteration   9: 195466.991 ns/op
Iteration  10: 197301.259 ns/op

# Run progress: 29.76% complete, ETA 00:10:20
# Fork: 2 of 3
# Warmup Iteration   1: 187504.503 ns/op
# Warmup Iteration   2: 184882.996 ns/op
# Warmup Iteration   3: 184515.966 ns/op
# Warmup Iteration   4: 184307.994 ns/op
# Warmup Iteration   5: 184678.868 ns/op
# Warmup Iteration   6: 184980.223 ns/op
# Warmup Iteration   7: 183748.592 ns/op
# Warmup Iteration   8: 185279.573 ns/op
# Warmup Iteration   9: 184684.610 ns/op
# Warmup Iteration  10: 184443.885 ns/op
Iteration   1: 184406.371 ns/op
Iteration   2: 184960.014 ns/op
Iteration   3: 186565.974 ns/op
Iteration   4: 184390.717 ns/op
Iteration   5: 185884.584 ns/op
Iteration   6: 188783.848 ns/op
Iteration   7: 191297.669 ns/op
Iteration   8: 191109.757 ns/op
Iteration   9: 191154.704 ns/op
Iteration  10: 191611.298 ns/op

# Run progress: 30.95% complete, ETA 00:10:09
# Fork: 3 of 3
# Warmup Iteration   1: 190824.529 ns/op
# Warmup Iteration   2: 188365.423 ns/op
# Warmup Iteration   3: 188230.648 ns/op
# Warmup Iteration   4: 189560.333 ns/op
# Warmup Iteration   5: 187967.616 ns/op
# Warmup Iteration   6: 188946.296 ns/op
# Warmup Iteration   7: 187657.372 ns/op
# Warmup Iteration   8: 189650.076 ns/op
# Warmup Iteration   9: 189438.104 ns/op
# Warmup Iteration  10: 190728.117 ns/op
Iteration   1: 189878.007 ns/op
Iteration   2: 190540.653 ns/op
Iteration   3: 189824.547 ns/op
Iteration   4: 188339.108 ns/op
Iteration   5: 189789.315 ns/op
Iteration   6: 194161.932 ns/op
Iteration   7: 198048.557 ns/op
Iteration   8: 196308.552 ns/op
Iteration   9: 198357.204 ns/op
Iteration  10: 196089.210 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  191228.879 ?(99.9%) 2728.044 ns/op [Average]
  (min, avg, max) = (184390.717, 191228.879, 198357.204), stdev = 4083.208
  CI (99.9%): [188500.835, 193956.922] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 32)

# Run progress: 32.14% complete, ETA 00:09:58
# Fork: 1 of 3
# Warmup Iteration   1: 47020.515 ns/op
# Warmup Iteration   2: 46247.723 ns/op
# Warmup Iteration   3: 46182.438 ns/op
# Warmup Iteration   4: 46208.308 ns/op
# Warmup Iteration   5: 46222.293 ns/op
# Warmup Iteration   6: 46657.978 ns/op
# Warmup Iteration   7: 46119.194 ns/op
# Warmup Iteration   8: 46314.229 ns/op
# Warmup Iteration   9: 46221.869 ns/op
# Warmup Iteration  10: 46214.746 ns/op
Iteration   1: 47073.035 ns/op
Iteration   2: 46924.679 ns/op
Iteration   3: 45965.503 ns/op
Iteration   4: 46100.403 ns/op
Iteration   5: 46483.749 ns/op
Iteration   6: 47107.007 ns/op
Iteration   7: 48610.423 ns/op
Iteration   8: 48526.145 ns/op
Iteration   9: 48241.095 ns/op
Iteration  10: 48140.497 ns/op

# Run progress: 33.33% complete, ETA 00:09:48
# Fork: 2 of 3
# Warmup Iteration   1: 47336.314 ns/op
# Warmup Iteration   2: 46190.271 ns/op
# Warmup Iteration   3: 46755.051 ns/op
# Warmup Iteration   4: 46235.545 ns/op
# Warmup Iteration   5: 46373.365 ns/op
# Warmup Iteration   6: 46401.496 ns/op
# Warmup Iteration   7: 46284.166 ns/op
# Warmup Iteration   8: 46384.406 ns/op
# Warmup Iteration   9: 46106.442 ns/op
# Warmup Iteration  10: 46427.825 ns/op
Iteration   1: 52484.633 ns/op
Iteration   2: 46570.381 ns/op
Iteration   3: 46128.033 ns/op
Iteration   4: 46140.002 ns/op
Iteration   5: 46394.625 ns/op
Iteration   6: 47880.470 ns/op
Iteration   7: 48180.503 ns/op
Iteration   8: 48317.870 ns/op
Iteration   9: 48875.872 ns/op
Iteration  10: 48279.216 ns/op

# Run progress: 34.52% complete, ETA 00:09:37
# Fork: 3 of 3
# Warmup Iteration   1: 47143.462 ns/op
# Warmup Iteration   2: 46500.437 ns/op
# Warmup Iteration   3: 47997.362 ns/op
# Warmup Iteration   4: 46331.281 ns/op
# Warmup Iteration   5: 47204.824 ns/op
# Warmup Iteration   6: 47144.315 ns/op
# Warmup Iteration   7: 46605.933 ns/op
# Warmup Iteration   8: 46093.840 ns/op
# Warmup Iteration   9: 46401.258 ns/op
# Warmup Iteration  10: 47681.845 ns/op
Iteration   1: 53448.013 ns/op
Iteration   2: 47572.703 ns/op
Iteration   3: 47485.336 ns/op
Iteration   4: 49342.260 ns/op
Iteration   5: 48232.387 ns/op
Iteration   6: 49119.861 ns/op
Iteration   7: 49558.622 ns/op
Iteration   8: 49691.322 ns/op
Iteration   9: 49110.505 ns/op
Iteration  10: 48517.337 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  48150.083 ?(99.9%) 1148.057 ns/op [Average]
  (min, avg, max) = (45965.503, 48150.083, 53448.013), stdev = 1718.358
  CI (99.9%): [47002.026, 49298.140] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 128)

# Run progress: 35.71% complete, ETA 00:09:27
# Fork: 1 of 3
# Warmup Iteration   1: 12330.665 ns/op
# Warmup Iteration   2: 11722.089 ns/op
# Warmup Iteration   3: 12353.039 ns/op
# Warmup Iteration   4: 11698.434 ns/op
# Warmup Iteration   5: 11686.629 ns/op
# Warmup Iteration   6: 11515.056 ns/op
# Warmup Iteration   7: 11610.590 ns/op
# Warmup Iteration   8: 11498.757 ns/op
# Warmup Iteration   9: 11501.151 ns/op
# Warmup Iteration  10: 11533.614 ns/op
Iteration   1: 11598.396 ns/op
Iteration   2: 11579.238 ns/op
Iteration   3: 11503.041 ns/op
Iteration   4: 11636.755 ns/op
Iteration   5: 11539.315 ns/op
Iteration   6: 12007.921 ns/op
Iteration   7: 12192.884 ns/op
Iteration   8: 12156.460 ns/op
Iteration   9: 12048.044 ns/op
Iteration  10: 12059.764 ns/op

# Run progress: 36.90% complete, ETA 00:09:16
# Fork: 2 of 3
# Warmup Iteration   1: 11855.981 ns/op
# Warmup Iteration   2: 11682.551 ns/op
# Warmup Iteration   3: 12439.423 ns/op
# Warmup Iteration   4: 11758.123 ns/op
# Warmup Iteration   5: 11615.049 ns/op
# Warmup Iteration   6: 11728.112 ns/op
# Warmup Iteration   7: 11614.891 ns/op
# Warmup Iteration   8: 11594.453 ns/op
# Warmup Iteration   9: 11602.327 ns/op
# Warmup Iteration  10: 11595.842 ns/op
Iteration   1: 11707.182 ns/op
Iteration   2: 11602.736 ns/op
Iteration   3: 11596.377 ns/op
Iteration   4: 11523.631 ns/op
Iteration   5: 11503.697 ns/op
Iteration   6: 11996.688 ns/op
Iteration   7: 12037.708 ns/op
Iteration   8: 12208.886 ns/op
Iteration   9: 12049.150 ns/op
Iteration  10: 12053.711 ns/op

# Run progress: 38.10% complete, ETA 00:09:05
# Fork: 3 of 3
# Warmup Iteration   1: 11887.778 ns/op
# Warmup Iteration   2: 11707.665 ns/op
# Warmup Iteration   3: 12312.211 ns/op
# Warmup Iteration   4: 11684.768 ns/op
# Warmup Iteration   5: 11535.829 ns/op
# Warmup Iteration   6: 11549.765 ns/op
# Warmup Iteration   7: 11634.504 ns/op
# Warmup Iteration   8: 11544.766 ns/op
# Warmup Iteration   9: 11546.806 ns/op
# Warmup Iteration  10: 11577.687 ns/op
Iteration   1: 11620.211 ns/op
Iteration   2: 11530.818 ns/op
Iteration   3: 11783.076 ns/op
Iteration   4: 11554.441 ns/op
Iteration   5: 11625.092 ns/op
Iteration   6: 11848.789 ns/op
Iteration   7: 12090.720 ns/op
Iteration   8: 11922.810 ns/op
Iteration   9: 11951.847 ns/op
Iteration  10: 11923.596 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  11815.100 ?(99.9%) 161.631 ns/op [Average]
  (min, avg, max) = (11503.041, 11815.100, 12208.886), stdev = 241.921
  CI (99.9%): [11653.469, 11976.730] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 512)

# Run progress: 39.29% complete, ETA 00:08:55
# Fork: 1 of 3
# Warmup Iteration   1: 3177.096 ns/op
# Warmup Iteration   2: 3311.765 ns/op
# Warmup Iteration   3: 2981.654 ns/op
# Warmup Iteration   4: 3449.263 ns/op
# Warmup Iteration   5: 3386.895 ns/op
# Warmup Iteration   6: 3396.692 ns/op
# Warmup Iteration   7: 3372.876 ns/op
# Warmup Iteration   8: 3379.558 ns/op
# Warmup Iteration   9: 3377.420 ns/op
# Warmup Iteration  10: 2915.753 ns/op
Iteration   1: 2912.218 ns/op
Iteration   2: 2898.650 ns/op
Iteration   3: 2919.153 ns/op
Iteration   4: 2889.924 ns/op
Iteration   5: 2890.539 ns/op
Iteration   6: 2988.560 ns/op
Iteration   7: 3068.767 ns/op
Iteration   8: 2996.055 ns/op
Iteration   9: 3020.060 ns/op
Iteration  10: 3037.292 ns/op

# Run progress: 40.48% complete, ETA 00:08:44
# Fork: 2 of 3
# Warmup Iteration   1: 3171.775 ns/op
# Warmup Iteration   2: 3328.823 ns/op
# Warmup Iteration   3: 2990.940 ns/op
# Warmup Iteration   4: 3408.990 ns/op
# Warmup Iteration   5: 3390.932 ns/op
# Warmup Iteration   6: 3384.514 ns/op
# Warmup Iteration   7: 3395.854 ns/op
# Warmup Iteration   8: 3381.799 ns/op
# Warmup Iteration   9: 3380.299 ns/op
# Warmup Iteration  10: 2901.734 ns/op
Iteration   1: 2899.932 ns/op
Iteration   2: 2909.648 ns/op
Iteration   3: 2899.611 ns/op
Iteration   4: 2888.904 ns/op
Iteration   5: 2888.650 ns/op
Iteration   6: 2978.012 ns/op
Iteration   7: 3028.067 ns/op
Iteration   8: 3038.785 ns/op
Iteration   9: 3016.161 ns/op
Iteration  10: 3009.468 ns/op

# Run progress: 41.67% complete, ETA 00:08:34
# Fork: 3 of 3
# Warmup Iteration   1: 3188.730 ns/op
# Warmup Iteration   2: 3315.451 ns/op
# Warmup Iteration   3: 3014.636 ns/op
# Warmup Iteration   4: 3407.085 ns/op
# Warmup Iteration   5: 3391.513 ns/op
# Warmup Iteration   6: 3382.438 ns/op
# Warmup Iteration   7: 3432.490 ns/op
# Warmup Iteration   8: 3374.117 ns/op
# Warmup Iteration   9: 3415.525 ns/op
# Warmup Iteration  10: 2910.263 ns/op
Iteration   1: 2893.772 ns/op
Iteration   2: 2898.702 ns/op
Iteration   3: 2895.024 ns/op
Iteration   4: 2911.677 ns/op
Iteration   5: 2895.069 ns/op
Iteration   6: 2996.832 ns/op
Iteration   7: 3008.649 ns/op
Iteration   8: 3020.422 ns/op
Iteration   9: 3022.532 ns/op
Iteration  10: 3008.558 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  2957.656 ?(99.9%) 41.162 ns/op [Average]
  (min, avg, max) = (2888.650, 2957.656, 3068.767), stdev = 61.609
  CI (99.9%): [2916.495, 2998.818] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 2048)

# Run progress: 42.86% complete, ETA 00:08:23
# Fork: 1 of 3
# Warmup Iteration   1: 1078.433 ns/op
# Warmup Iteration   2: 826.944 ns/op
# Warmup Iteration   3: 822.322 ns/op
# Warmup Iteration   4: 825.544 ns/op
# Warmup Iteration   5: 820.143 ns/op
# Warmup Iteration   6: 822.538 ns/op
# Warmup Iteration   7: 823.453 ns/op
# Warmup Iteration   8: 820.741 ns/op
# Warmup Iteration   9: 829.214 ns/op
# Warmup Iteration  10: 813.310 ns/op
Iteration   1: 810.661 ns/op
Iteration   2: 816.678 ns/op
Iteration   3: 809.886 ns/op
Iteration   4: 814.349 ns/op
Iteration   5: 814.185 ns/op
Iteration   6: 828.766 ns/op
Iteration   7: 842.838 ns/op
Iteration   8: 843.721 ns/op
Iteration   9: 839.100 ns/op
Iteration  10: 836.942 ns/op

# Run progress: 44.05% complete, ETA 00:08:12
# Fork: 2 of 3
# Warmup Iteration   1: 1097.360 ns/op
# Warmup Iteration   2: 825.663 ns/op
# Warmup Iteration   3: 815.648 ns/op
# Warmup Iteration   4: 821.306 ns/op
# Warmup Iteration   5: 822.394 ns/op
# Warmup Iteration   6: 819.957 ns/op
# Warmup Iteration   7: 820.763 ns/op
# Warmup Iteration   8: 818.912 ns/op
# Warmup Iteration   9: 835.157 ns/op
# Warmup Iteration  10: 810.131 ns/op
Iteration   1: 813.615 ns/op
Iteration   2: 813.852 ns/op
Iteration   3: 817.584 ns/op
Iteration   4: 815.711 ns/op
Iteration   5: 812.929 ns/op
Iteration   6: 841.412 ns/op
Iteration   7: 849.280 ns/op
Iteration   8: 847.687 ns/op
Iteration   9: 846.453 ns/op
Iteration  10: 850.110 ns/op

# Run progress: 45.24% complete, ETA 00:08:02
# Fork: 3 of 3
# Warmup Iteration   1: 1079.828 ns/op
# Warmup Iteration   2: 829.916 ns/op
# Warmup Iteration   3: 814.199 ns/op
# Warmup Iteration   4: 823.611 ns/op
# Warmup Iteration   5: 824.004 ns/op
# Warmup Iteration   6: 828.554 ns/op
# Warmup Iteration   7: 823.272 ns/op
# Warmup Iteration   8: 822.055 ns/op
# Warmup Iteration   9: 822.314 ns/op
# Warmup Iteration  10: 812.882 ns/op
Iteration   1: 814.219 ns/op
Iteration   2: 811.064 ns/op
Iteration   3: 812.238 ns/op
Iteration   4: 812.719 ns/op
Iteration   5: 814.585 ns/op
Iteration   6: 831.875 ns/op
Iteration   7: 841.715 ns/op
Iteration   8: 863.932 ns/op
Iteration   9: 878.186 ns/op
Iteration  10: 883.537 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  830.994 ?(99.9%) 13.880 ns/op [Average]
  (min, avg, max) = (809.886, 830.994, 883.537), stdev = 20.774
  CI (99.9%): [817.115, 844.874] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1
# Parameters: (inputStreamSize = 1000000, skipLength = 8192)

# Run progress: 46.43% complete, ETA 00:07:51
# Fork: 1 of 3
# Warmup Iteration   1: 673.621 ns/op
# Warmup Iteration   2: 497.891 ns/op
# Warmup Iteration   3: 448.860 ns/op
# Warmup Iteration   4: 491.408 ns/op
# Warmup Iteration   5: 484.470 ns/op
# Warmup Iteration   6: 477.959 ns/op
# Warmup Iteration   7: 493.714 ns/op
# Warmup Iteration   8: 495.703 ns/op
# Warmup Iteration   9: 489.659 ns/op
# Warmup Iteration  10: 471.387 ns/op
Iteration   1: 463.286 ns/op
Iteration   2: 485.156 ns/op
Iteration   3: 465.842 ns/op
Iteration   4: 456.823 ns/op
Iteration   5: 452.152 ns/op
Iteration   6: 459.910 ns/op
Iteration   7: 462.217 ns/op
Iteration   8: 458.735 ns/op
Iteration   9: 463.817 ns/op
Iteration  10: 459.041 ns/op

# Run progress: 47.62% complete, ETA 00:07:41
# Fork: 2 of 3
# Warmup Iteration   1: 701.791 ns/op
# Warmup Iteration   2: 503.358 ns/op
# Warmup Iteration   3: 480.923 ns/op
# Warmup Iteration   4: 509.666 ns/op
# Warmup Iteration   5: 498.563 ns/op
# Warmup Iteration   6: 491.844 ns/op
# Warmup Iteration   7: 502.889 ns/op
# Warmup Iteration   8: 509.837 ns/op
# Warmup Iteration   9: 507.599 ns/op
# Warmup Iteration  10: 479.780 ns/op
Iteration   1: 460.536 ns/op
Iteration   2: 477.708 ns/op
Iteration   3: 466.100 ns/op
Iteration   4: 464.881 ns/op
Iteration   5: 475.830 ns/op
Iteration   6: 466.699 ns/op
Iteration   7: 464.882 ns/op
Iteration   8: 469.254 ns/op
Iteration   9: 481.899 ns/op
Iteration  10: 458.864 ns/op

# Run progress: 48.81% complete, ETA 00:07:30
# Fork: 3 of 3
# Warmup Iteration   1: 810.525 ns/op
# Warmup Iteration   2: 491.270 ns/op
# Warmup Iteration   3: 455.686 ns/op
# Warmup Iteration   4: 503.087 ns/op
# Warmup Iteration   5: 512.982 ns/op
# Warmup Iteration   6: 491.758 ns/op
# Warmup Iteration   7: 775.896 ns/op
# Warmup Iteration   8: 640.211 ns/op
# Warmup Iteration   9: 487.164 ns/op
# Warmup Iteration  10: 467.138 ns/op
Iteration   1: 454.451 ns/op
Iteration   2: 449.081 ns/op
Iteration   3: 467.106 ns/op
Iteration   4: 459.483 ns/op
Iteration   5: 442.272 ns/op
Iteration   6: 451.958 ns/op
Iteration   7: 454.426 ns/op
Iteration   8: 454.101 ns/op
Iteration   9: 462.280 ns/op
Iteration  10: 456.994 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip1":
  462.193 ?(99.9%) 6.262 ns/op [Average]
  (min, avg, max) = (442.272, 462.193, 485.156), stdev = 9.373
  CI (99.9%): [455.930, 468.455] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 1)

# Run progress: 50.00% complete, ETA 00:07:20
# Fork: 1 of 3
# Warmup Iteration   1: 1600381.931 ns/op
# Warmup Iteration   2: 1522918.455 ns/op
# Warmup Iteration   3: 1630929.524 ns/op
# Warmup Iteration   4: 1491878.261 ns/op
# Warmup Iteration   5: 1703253.970 ns/op
# Warmup Iteration   6: 1520223.894 ns/op
# Warmup Iteration   7: 1560624.620 ns/op
# Warmup Iteration   8: 1527514.243 ns/op
# Warmup Iteration   9: 1486408.382 ns/op
# Warmup Iteration  10: 1598800.932 ns/op
Iteration   1: 1626938.611 ns/op
Iteration   2: 1614250.784 ns/op
Iteration   3: 1535637.313 ns/op
Iteration   4: 1518382.599 ns/op
Iteration   5: 1552711.480 ns/op
Iteration   6: 1544972.372 ns/op
Iteration   7: 1546436.446 ns/op
Iteration   8: 1549668.115 ns/op
Iteration   9: 1551146.526 ns/op
Iteration  10: 1568442.553 ns/op

# Run progress: 51.19% complete, ETA 00:07:09
# Fork: 2 of 3
# Warmup Iteration   1: 1533575.676 ns/op
# Warmup Iteration   2: 1506874.257 ns/op
# Warmup Iteration   3: 1491809.887 ns/op
# Warmup Iteration   4: 1571289.599 ns/op
# Warmup Iteration   5: 1589797.840 ns/op
# Warmup Iteration   6: 1542688.060 ns/op
# Warmup Iteration   7: 1487715.939 ns/op
# Warmup Iteration   8: 1487999.425 ns/op
# Warmup Iteration   9: 1489184.682 ns/op
# Warmup Iteration  10: 1489307.536 ns/op
Iteration   1: 1516429.501 ns/op
Iteration   2: 1505329.619 ns/op
Iteration   3: 1502676.316 ns/op
Iteration   4: 1492915.988 ns/op
Iteration   5: 1512904.412 ns/op
Iteration   6: 1539914.630 ns/op
Iteration   7: 1576945.065 ns/op
Iteration   8: 1548133.033 ns/op
Iteration   9: 1553487.037 ns/op
Iteration  10: 1539195.077 ns/op

# Run progress: 52.38% complete, ETA 00:06:59
# Fork: 3 of 3
# Warmup Iteration   1: 1616053.770 ns/op
# Warmup Iteration   2: 1534533.433 ns/op
# Warmup Iteration   3: 1558576.087 ns/op
# Warmup Iteration   4: 1522562.537 ns/op
# Warmup Iteration   5: 1535325.595 ns/op
# Warmup Iteration   6: 1633598.092 ns/op
# Warmup Iteration   7: 1486916.474 ns/op
# Warmup Iteration   8: 1489124.855 ns/op
# Warmup Iteration   9: 1527958.336 ns/op
# Warmup Iteration  10: 1504804.692 ns/op
Iteration   1: 1509667.251 ns/op
Iteration   2: 1499703.509 ns/op
Iteration   3: 1516409.971 ns/op
Iteration   4: 1494003.287 ns/op
Iteration   5: 1486538.329 ns/op
Iteration   6: 1546076.383 ns/op
Iteration   7: 1555692.427 ns/op
Iteration   8: 1539352.395 ns/op
Iteration   9: 1540285.629 ns/op
Iteration  10: 1542448.160 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  1537556.494 ?(99.9%) 21742.419 ns/op [Average]
  (min, avg, max) = (1486538.329, 1537556.494, 1626938.611), stdev = 32543.032
  CI (99.9%): [1515814.074, 1559298.913] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 8)

# Run progress: 53.57% complete, ETA 00:06:49
# Fork: 1 of 3
# Warmup Iteration   1: 185371.371 ns/op
# Warmup Iteration   2: 183307.449 ns/op
# Warmup Iteration   3: 182315.098 ns/op
# Warmup Iteration   4: 187214.568 ns/op
# Warmup Iteration   5: 185688.753 ns/op
# Warmup Iteration   6: 188393.474 ns/op
# Warmup Iteration   7: 189366.899 ns/op
# Warmup Iteration   8: 183992.960 ns/op
# Warmup Iteration   9: 185575.514 ns/op
# Warmup Iteration  10: 181025.369 ns/op
Iteration   1: 183273.295 ns/op
Iteration   2: 182561.018 ns/op
Iteration   3: 182924.154 ns/op
Iteration   4: 188795.195 ns/op
Iteration   5: 188157.953 ns/op
Iteration   6: 189084.412 ns/op
Iteration   7: 188771.998 ns/op
Iteration   8: 186180.402 ns/op
Iteration   9: 188485.897 ns/op
Iteration  10: 188463.456 ns/op

# Run progress: 54.76% complete, ETA 00:06:38
# Fork: 2 of 3
# Warmup Iteration   1: 194303.991 ns/op
# Warmup Iteration   2: 188420.584 ns/op
# Warmup Iteration   3: 188523.503 ns/op
# Warmup Iteration   4: 194708.892 ns/op
# Warmup Iteration   5: 193929.368 ns/op
# Warmup Iteration   6: 195480.738 ns/op
# Warmup Iteration   7: 193859.593 ns/op
# Warmup Iteration   8: 187464.082 ns/op
# Warmup Iteration   9: 194546.740 ns/op
# Warmup Iteration  10: 190254.623 ns/op
Iteration   1: 188285.537 ns/op
Iteration   2: 197087.962 ns/op
Iteration   3: 189061.239 ns/op
Iteration   4: 191956.135 ns/op
Iteration   5: 201364.409 ns/op
Iteration   6: 195187.339 ns/op
Iteration   7: 195076.821 ns/op
Iteration   8: 194520.644 ns/op
Iteration   9: 194947.864 ns/op
Iteration  10: 195179.620 ns/op

# Run progress: 55.95% complete, ETA 00:06:28
# Fork: 3 of 3
# Warmup Iteration   1: 184327.204 ns/op
# Warmup Iteration   2: 186002.339 ns/op
# Warmup Iteration   3: 182669.655 ns/op
# Warmup Iteration   4: 181794.527 ns/op
# Warmup Iteration   5: 183875.509 ns/op
# Warmup Iteration   6: 181113.371 ns/op
# Warmup Iteration   7: 182148.956 ns/op
# Warmup Iteration   8: 183315.816 ns/op
# Warmup Iteration   9: 185507.307 ns/op
# Warmup Iteration  10: 187052.277 ns/op
Iteration   1: 183289.454 ns/op
Iteration   2: 188415.764 ns/op
Iteration   3: 182838.199 ns/op
Iteration   4: 182503.405 ns/op
Iteration   5: 183008.517 ns/op
Iteration   6: 190570.564 ns/op
Iteration   7: 189398.978 ns/op
Iteration   8: 189497.454 ns/op
Iteration   9: 192048.496 ns/op
Iteration  10: 189030.023 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  189332.207 ?(99.9%) 3247.491 ns/op [Average]
  (min, avg, max) = (182503.405, 189332.207, 201364.409), stdev = 4860.692
  CI (99.9%): [186084.716, 192579.698] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 32)

# Run progress: 57.14% complete, ETA 00:06:17
# Fork: 1 of 3
# Warmup Iteration   1: 47850.037 ns/op
# Warmup Iteration   2: 46659.427 ns/op
# Warmup Iteration   3: 47270.330 ns/op
# Warmup Iteration   4: 47999.907 ns/op
# Warmup Iteration   5: 49255.815 ns/op
# Warmup Iteration   6: 48634.200 ns/op
# Warmup Iteration   7: 46455.428 ns/op
# Warmup Iteration   8: 46539.115 ns/op
# Warmup Iteration   9: 47064.733 ns/op
# Warmup Iteration  10: 47868.692 ns/op
Iteration   1: 57653.853 ns/op
Iteration   2: 47379.669 ns/op
Iteration   3: 47948.496 ns/op
Iteration   4: 46640.387 ns/op
Iteration   5: 47723.613 ns/op
Iteration   6: 47966.644 ns/op
Iteration   7: 47933.212 ns/op
Iteration   8: 48347.938 ns/op
Iteration   9: 48094.860 ns/op
Iteration  10: 48044.961 ns/op

# Run progress: 58.33% complete, ETA 00:06:07
# Fork: 2 of 3
# Warmup Iteration   1: 47638.581 ns/op
# Warmup Iteration   2: 48160.921 ns/op
# Warmup Iteration   3: 47481.423 ns/op
# Warmup Iteration   4: 47336.627 ns/op
# Warmup Iteration   5: 47251.883 ns/op
# Warmup Iteration   6: 47986.668 ns/op
# Warmup Iteration   7: 48765.566 ns/op
# Warmup Iteration   8: 48343.893 ns/op
# Warmup Iteration   9: 47200.414 ns/op
# Warmup Iteration  10: 47264.175 ns/op
Iteration   1: 56334.120 ns/op
Iteration   2: 45987.112 ns/op
Iteration   3: 45937.484 ns/op
Iteration   4: 46165.962 ns/op
Iteration   5: 45820.335 ns/op
Iteration   6: 47027.428 ns/op
Iteration   7: 47424.048 ns/op
Iteration   8: 47939.154 ns/op
Iteration   9: 47751.216 ns/op
Iteration  10: 47594.162 ns/op

# Run progress: 59.52% complete, ETA 00:05:56
# Fork: 3 of 3
# Warmup Iteration   1: 47265.528 ns/op
# Warmup Iteration   2: 48105.453 ns/op
# Warmup Iteration   3: 46152.588 ns/op
# Warmup Iteration   4: 46524.674 ns/op
# Warmup Iteration   5: 47519.314 ns/op
# Warmup Iteration   6: 46015.564 ns/op
# Warmup Iteration   7: 46843.617 ns/op
# Warmup Iteration   8: 46430.362 ns/op
# Warmup Iteration   9: 46798.617 ns/op
# Warmup Iteration  10: 46941.591 ns/op
Iteration   1: 60447.365 ns/op
Iteration   2: 46222.971 ns/op
Iteration   3: 46016.704 ns/op
Iteration   4: 47446.011 ns/op
Iteration   5: 49055.165 ns/op
Iteration   6: 48529.352 ns/op
Iteration   7: 47828.611 ns/op
Iteration   8: 47579.666 ns/op
Iteration   9: 47993.586 ns/op
Iteration  10: 47763.715 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  48486.593 ?(99.9%) 2287.385 ns/op [Average]
  (min, avg, max) = (45820.335, 48486.593, 60447.365), stdev = 3423.651
  CI (99.9%): [46199.208, 50773.979] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 128)

# Run progress: 60.71% complete, ETA 00:05:46
# Fork: 1 of 3
# Warmup Iteration   1: 12307.069 ns/op
# Warmup Iteration   2: 12034.649 ns/op
# Warmup Iteration   3: 13604.872 ns/op
# Warmup Iteration   4: 11211.318 ns/op
# Warmup Iteration   5: 11145.343 ns/op
# Warmup Iteration   6: 11142.724 ns/op
# Warmup Iteration   7: 11182.241 ns/op
# Warmup Iteration   8: 11131.610 ns/op
# Warmup Iteration   9: 10905.528 ns/op
# Warmup Iteration  10: 10850.074 ns/op
Iteration   1: 11283.908 ns/op
Iteration   2: 12276.360 ns/op
Iteration   3: 11603.058 ns/op
Iteration   4: 11028.135 ns/op
Iteration   5: 11091.345 ns/op
Iteration   6: 11225.388 ns/op
Iteration   7: 11318.498 ns/op
Iteration   8: 11307.435 ns/op
Iteration   9: 11276.733 ns/op
Iteration  10: 11290.993 ns/op

# Run progress: 61.90% complete, ETA 00:05:35
# Fork: 2 of 3
# Warmup Iteration   1: 12356.381 ns/op
# Warmup Iteration   2: 11794.944 ns/op
# Warmup Iteration   3: 13355.614 ns/op
# Warmup Iteration   4: 11287.547 ns/op
# Warmup Iteration   5: 11185.967 ns/op
# Warmup Iteration   6: 11171.306 ns/op
# Warmup Iteration   7: 12259.531 ns/op
# Warmup Iteration   8: 12410.751 ns/op
# Warmup Iteration   9: 12021.365 ns/op
# Warmup Iteration  10: 11839.859 ns/op
Iteration   1: 11170.718 ns/op
Iteration   2: 10898.701 ns/op
Iteration   3: 10958.143 ns/op
Iteration   4: 10919.660 ns/op
Iteration   5: 10894.873 ns/op
Iteration   6: 11276.859 ns/op
Iteration   7: 11375.605 ns/op
Iteration   8: 11436.379 ns/op
Iteration   9: 11294.827 ns/op
Iteration  10: 11292.266 ns/op

# Run progress: 63.10% complete, ETA 00:05:24
# Fork: 3 of 3
# Warmup Iteration   1: 12326.366 ns/op
# Warmup Iteration   2: 11813.472 ns/op
# Warmup Iteration   3: 13255.021 ns/op
# Warmup Iteration   4: 11268.230 ns/op
# Warmup Iteration   5: 11134.791 ns/op
# Warmup Iteration   6: 11205.229 ns/op
# Warmup Iteration   7: 11090.444 ns/op
# Warmup Iteration   8: 11149.783 ns/op
# Warmup Iteration   9: 10900.722 ns/op
# Warmup Iteration  10: 10968.211 ns/op
Iteration   1: 10840.022 ns/op
Iteration   2: 10896.874 ns/op
Iteration   3: 10799.555 ns/op
Iteration   4: 10829.735 ns/op
Iteration   5: 10891.844 ns/op
Iteration   6: 11220.686 ns/op
Iteration   7: 11444.363 ns/op
Iteration   8: 11283.402 ns/op
Iteration   9: 11206.220 ns/op
Iteration  10: 11163.789 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  11193.212 ?(99.9%) 197.053 ns/op [Average]
  (min, avg, max) = (10799.555, 11193.212, 12276.360), stdev = 294.939
  CI (99.9%): [10996.160, 11390.265] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 512)

# Run progress: 64.29% complete, ETA 00:05:14
# Fork: 1 of 3
# Warmup Iteration   1: 3627.173 ns/op
# Warmup Iteration   2: 4196.510 ns/op
# Warmup Iteration   3: 3200.638 ns/op
# Warmup Iteration   4: 4086.014 ns/op
# Warmup Iteration   5: 3994.356 ns/op
# Warmup Iteration   6: 3959.363 ns/op
# Warmup Iteration   7: 4203.218 ns/op
# Warmup Iteration   8: 4046.890 ns/op
# Warmup Iteration   9: 3968.463 ns/op
# Warmup Iteration  10: 3012.631 ns/op
Iteration   1: 3000.603 ns/op
Iteration   2: 2998.036 ns/op
Iteration   3: 2983.099 ns/op
Iteration   4: 2991.244 ns/op
Iteration   5: 2997.143 ns/op
Iteration   6: 3077.378 ns/op
Iteration   7: 3122.359 ns/op
Iteration   8: 3091.360 ns/op
Iteration   9: 3127.516 ns/op
Iteration  10: 3109.661 ns/op

# Run progress: 65.48% complete, ETA 00:05:03
# Fork: 2 of 3
# Warmup Iteration   1: 3492.830 ns/op
# Warmup Iteration   2: 4059.554 ns/op
# Warmup Iteration   3: 3173.803 ns/op
# Warmup Iteration   4: 3837.429 ns/op
# Warmup Iteration   5: 3804.372 ns/op
# Warmup Iteration   6: 3759.826 ns/op
# Warmup Iteration   7: 3860.921 ns/op
# Warmup Iteration   8: 3775.802 ns/op
# Warmup Iteration   9: 3816.181 ns/op
# Warmup Iteration  10: 2809.110 ns/op
Iteration   1: 2799.282 ns/op
Iteration   2: 2822.944 ns/op
Iteration   3: 2820.442 ns/op
Iteration   4: 2801.420 ns/op
Iteration   5: 2798.625 ns/op
Iteration   6: 2900.416 ns/op
Iteration   7: 2904.702 ns/op
Iteration   8: 2921.288 ns/op
Iteration   9: 2887.661 ns/op
Iteration  10: 2928.718 ns/op

# Run progress: 66.67% complete, ETA 00:04:53
# Fork: 3 of 3
# Warmup Iteration   1: 3631.585 ns/op
# Warmup Iteration   2: 4237.025 ns/op
# Warmup Iteration   3: 3173.084 ns/op
# Warmup Iteration   4: 3916.382 ns/op
# Warmup Iteration   5: 3895.940 ns/op
# Warmup Iteration   6: 3848.179 ns/op
# Warmup Iteration   7: 3845.879 ns/op
# Warmup Iteration   8: 3849.513 ns/op
# Warmup Iteration   9: 3873.165 ns/op
# Warmup Iteration  10: 2990.531 ns/op
Iteration   1: 2996.021 ns/op
Iteration   2: 2995.289 ns/op
Iteration   3: 3006.391 ns/op
Iteration   4: 3006.051 ns/op
Iteration   5: 3012.556 ns/op
Iteration   6: 3067.065 ns/op
Iteration   7: 3118.446 ns/op
Iteration   8: 3280.964 ns/op
Iteration   9: 3126.310 ns/op
Iteration  10: 3100.495 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  2993.116 ?(99.9%) 79.159 ns/op [Average]
  (min, avg, max) = (2798.625, 2993.116, 3280.964), stdev = 118.482
  CI (99.9%): [2913.957, 3072.275] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 2048)

# Run progress: 67.86% complete, ETA 00:04:43
# Fork: 1 of 3
# Warmup Iteration   1: 1334.005 ns/op
# Warmup Iteration   2: 1076.288 ns/op
# Warmup Iteration   3: 774.020 ns/op
# Warmup Iteration   4: 1071.051 ns/op
# Warmup Iteration   5: 1061.022 ns/op
# Warmup Iteration   6: 1064.288 ns/op
# Warmup Iteration   7: 1060.222 ns/op
# Warmup Iteration   8: 1059.507 ns/op
# Warmup Iteration   9: 1069.863 ns/op
# Warmup Iteration  10: 728.870 ns/op
Iteration   1: 726.786 ns/op
Iteration   2: 722.822 ns/op
Iteration   3: 735.768 ns/op
Iteration   4: 718.979 ns/op
Iteration   5: 728.883 ns/op
Iteration   6: 737.871 ns/op
Iteration   7: 745.559 ns/op
Iteration   8: 742.403 ns/op
Iteration   9: 741.530 ns/op
Iteration  10: 745.531 ns/op

# Run progress: 69.05% complete, ETA 00:04:32
# Fork: 2 of 3
# Warmup Iteration   1: 1457.633 ns/op
# Warmup Iteration   2: 1079.259 ns/op
# Warmup Iteration   3: 770.332 ns/op
# Warmup Iteration   4: 1065.559 ns/op
# Warmup Iteration   5: 1062.851 ns/op
# Warmup Iteration   6: 1060.527 ns/op
# Warmup Iteration   7: 1057.854 ns/op
# Warmup Iteration   8: 1067.550 ns/op
# Warmup Iteration   9: 1071.907 ns/op
# Warmup Iteration  10: 721.212 ns/op
Iteration   1: 724.178 ns/op
Iteration   2: 721.765 ns/op
Iteration   3: 723.789 ns/op
Iteration   4: 721.606 ns/op
Iteration   5: 727.996 ns/op
Iteration   6: 740.184 ns/op
Iteration   7: 749.788 ns/op
Iteration   8: 751.580 ns/op
Iteration   9: 747.098 ns/op
Iteration  10: 752.569 ns/op

# Run progress: 70.24% complete, ETA 00:04:22
# Fork: 3 of 3
# Warmup Iteration   1: 1320.692 ns/op
# Warmup Iteration   2: 999.164 ns/op
# Warmup Iteration   3: 773.403 ns/op
# Warmup Iteration   4: 998.129 ns/op
# Warmup Iteration   5: 994.993 ns/op
# Warmup Iteration   6: 1001.478 ns/op
# Warmup Iteration   7: 990.722 ns/op
# Warmup Iteration   8: 1024.891 ns/op
# Warmup Iteration   9: 997.286 ns/op
# Warmup Iteration  10: 730.735 ns/op
Iteration   1: 728.672 ns/op
Iteration   2: 725.350 ns/op
Iteration   3: 729.132 ns/op
Iteration   4: 727.167 ns/op
Iteration   5: 728.937 ns/op
Iteration   6: 745.805 ns/op
Iteration   7: 753.412 ns/op
Iteration   8: 756.743 ns/op
Iteration   9: 753.739 ns/op
Iteration  10: 751.167 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  736.894 ?(99.9%) 8.002 ns/op [Average]
  (min, avg, max) = (718.979, 736.894, 756.743), stdev = 11.976
  CI (99.9%): [728.892, 744.895] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2
# Parameters: (inputStreamSize = 1000000, skipLength = 8192)

# Run progress: 71.43% complete, ETA 00:04:11
# Fork: 1 of 3
# Warmup Iteration   1: 824.218 ns/op
# Warmup Iteration   2: 558.402 ns/op
# Warmup Iteration   3: 455.710 ns/op
# Warmup Iteration   4: 595.549 ns/op
# Warmup Iteration   5: 597.424 ns/op
# Warmup Iteration   6: 607.381 ns/op
# Warmup Iteration   7: 567.484 ns/op
# Warmup Iteration   8: 572.725 ns/op
# Warmup Iteration   9: 576.511 ns/op
# Warmup Iteration  10: 444.320 ns/op
Iteration   1: 440.230 ns/op
Iteration   2: 441.965 ns/op
Iteration   3: 442.892 ns/op
Iteration   4: 441.011 ns/op
Iteration   5: 445.897 ns/op
Iteration   6: 450.682 ns/op
Iteration   7: 456.058 ns/op
Iteration   8: 455.945 ns/op
Iteration   9: 454.806 ns/op
Iteration  10: 454.402 ns/op

# Run progress: 72.62% complete, ETA 00:04:01
# Fork: 2 of 3
# Warmup Iteration   1: 813.629 ns/op
# Warmup Iteration   2: 562.192 ns/op
# Warmup Iteration   3: 445.881 ns/op
# Warmup Iteration   4: 563.452 ns/op
# Warmup Iteration   5: 567.429 ns/op
# Warmup Iteration   6: 563.228 ns/op
# Warmup Iteration   7: 560.503 ns/op
# Warmup Iteration   8: 563.675 ns/op
# Warmup Iteration   9: 556.744 ns/op
# Warmup Iteration  10: 442.848 ns/op
Iteration   1: 436.955 ns/op
Iteration   2: 439.168 ns/op
Iteration   3: 441.501 ns/op
Iteration   4: 445.505 ns/op
Iteration   5: 442.725 ns/op
Iteration   6: 447.179 ns/op
Iteration   7: 450.441 ns/op
Iteration   8: 457.027 ns/op
Iteration   9: 454.359 ns/op
Iteration  10: 453.202 ns/op

# Run progress: 73.81% complete, ETA 00:03:50
# Fork: 3 of 3
# Warmup Iteration   1: 720.621 ns/op
# Warmup Iteration   2: 563.623 ns/op
# Warmup Iteration   3: 445.686 ns/op
# Warmup Iteration   4: 567.224 ns/op
# Warmup Iteration   5: 564.950 ns/op
# Warmup Iteration   6: 557.819 ns/op
# Warmup Iteration   7: 562.175 ns/op
# Warmup Iteration   8: 560.725 ns/op
# Warmup Iteration   9: 558.889 ns/op
# Warmup Iteration  10: 440.788 ns/op
Iteration   1: 440.845 ns/op
Iteration   2: 440.017 ns/op
Iteration   3: 442.510 ns/op
Iteration   4: 447.888 ns/op
Iteration   5: 440.780 ns/op
Iteration   6: 450.577 ns/op
Iteration   7: 454.286 ns/op
Iteration   8: 451.147 ns/op
Iteration   9: 453.044 ns/op
Iteration  10: 453.127 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip2":
  447.539 ?(99.9%) 4.169 ns/op [Average]
  (min, avg, max) = (436.955, 447.539, 457.027), stdev = 6.240
  CI (99.9%): [443.370, 451.708] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 1)

# Run progress: 75.00% complete, ETA 00:03:40
# Fork: 1 of 3
# Warmup Iteration   1: 2151264.017 ns/op
# Warmup Iteration   2: 2091483.607 ns/op
# Warmup Iteration   3: 2108069.456 ns/op
# Warmup Iteration   4: 2135040.496 ns/op
# Warmup Iteration   5: 2114271.849 ns/op
# Warmup Iteration   6: 2107860.924 ns/op
# Warmup Iteration   7: 2121736.975 ns/op
# Warmup Iteration   8: 2104463.673 ns/op
# Warmup Iteration   9: 2098269.167 ns/op
# Warmup Iteration  10: 2130394.215 ns/op
Iteration   1: 2134304.661 ns/op
Iteration   2: 2102452.301 ns/op
Iteration   3: 2114667.089 ns/op
Iteration   4: 2132030.085 ns/op
Iteration   5: 2125000.000 ns/op
Iteration   6: 2188356.522 ns/op
Iteration   7: 2204782.906 ns/op
Iteration   8: 2187722.034 ns/op
Iteration   9: 2177151.477 ns/op
Iteration  10: 2238603.111 ns/op

# Run progress: 76.19% complete, ETA 00:03:29
# Fork: 2 of 3
# Warmup Iteration   1: 2141472.996 ns/op
# Warmup Iteration   2: 2148505.858 ns/op
# Warmup Iteration   3: 2092496.266 ns/op
# Warmup Iteration   4: 2105840.756 ns/op
# Warmup Iteration   5: 2126346.414 ns/op
# Warmup Iteration   6: 2102201.250 ns/op
# Warmup Iteration   7: 2112762.185 ns/op
# Warmup Iteration   8: 2096674.895 ns/op
# Warmup Iteration   9: 2096281.667 ns/op
# Warmup Iteration  10: 2103689.167 ns/op
Iteration   1: 2107954.098 ns/op
Iteration   2: 2099919.665 ns/op
Iteration   3: 2120199.578 ns/op
Iteration   4: 2114721.008 ns/op
Iteration   5: 2110401.681 ns/op
Iteration   6: 2134220.851 ns/op
Iteration   7: 2160903.433 ns/op
Iteration   8: 2160135.897 ns/op
Iteration   9: 2160875.536 ns/op
Iteration  10: 2170838.235 ns/op

# Run progress: 77.38% complete, ETA 00:03:19
# Fork: 3 of 3
# Warmup Iteration   1: 2158338.197 ns/op
# Warmup Iteration   2: 2123724.481 ns/op
# Warmup Iteration   3: 2111551.029 ns/op
# Warmup Iteration   4: 2112030.864 ns/op
# Warmup Iteration   5: 2111053.689 ns/op
# Warmup Iteration   6: 2106363.525 ns/op
# Warmup Iteration   7: 2124271.488 ns/op
# Warmup Iteration   8: 2113309.426 ns/op
# Warmup Iteration   9: 2127532.922 ns/op
# Warmup Iteration  10: 2110577.366 ns/op
Iteration   1: 2109472.951 ns/op
Iteration   2: 2108497.531 ns/op
Iteration   3: 2111459.426 ns/op
Iteration   4: 2114813.169 ns/op
Iteration   5: 2122864.050 ns/op
Iteration   6: 2186059.565 ns/op
Iteration   7: 2188020.763 ns/op
Iteration   8: 2192549.573 ns/op
Iteration   9: 2182645.763 ns/op
Iteration  10: 2229974.667 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  2149719.921 ?(99.9%) 26904.372 ns/op [Average]
  (min, avg, max) = (2099919.665, 2149719.921, 2238603.111), stdev = 40269.200
  CI (99.9%): [2122815.549, 2176624.293] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 8)

# Run progress: 78.57% complete, ETA 00:03:08
# Fork: 1 of 3
# Warmup Iteration   1: 295206.357 ns/op
# Warmup Iteration   2: 288737.514 ns/op
# Warmup Iteration   3: 287841.074 ns/op
# Warmup Iteration   4: 288508.632 ns/op
# Warmup Iteration   5: 288937.254 ns/op
# Warmup Iteration   6: 290307.014 ns/op
# Warmup Iteration   7: 291715.718 ns/op
# Warmup Iteration   8: 287861.440 ns/op
# Warmup Iteration   9: 287635.014 ns/op
# Warmup Iteration  10: 286926.448 ns/op
Iteration   1: 291699.773 ns/op
Iteration   2: 290060.000 ns/op
Iteration   3: 290343.115 ns/op
Iteration   4: 289737.902 ns/op
Iteration   5: 290821.210 ns/op
Iteration   6: 296109.225 ns/op
Iteration   7: 297473.449 ns/op
Iteration   8: 296435.524 ns/op
Iteration   9: 299668.126 ns/op
Iteration  10: 297757.366 ns/op

# Run progress: 79.76% complete, ETA 00:02:58
# Fork: 2 of 3
# Warmup Iteration   1: 292720.117 ns/op
# Warmup Iteration   2: 287366.330 ns/op
# Warmup Iteration   3: 288332.606 ns/op
# Warmup Iteration   4: 287722.750 ns/op
# Warmup Iteration   5: 288975.449 ns/op
# Warmup Iteration   6: 290271.574 ns/op
# Warmup Iteration   7: 287073.717 ns/op
# Warmup Iteration   8: 288264.759 ns/op
# Warmup Iteration   9: 287718.772 ns/op
# Warmup Iteration  10: 292462.514 ns/op
Iteration   1: 288938.249 ns/op
Iteration   2: 290590.967 ns/op
Iteration   3: 291416.450 ns/op
Iteration   4: 290155.537 ns/op
Iteration   5: 294176.655 ns/op
Iteration   6: 297428.969 ns/op
Iteration   7: 301755.006 ns/op
Iteration   8: 301400.841 ns/op
Iteration   9: 304305.744 ns/op
Iteration  10: 302343.923 ns/op

# Run progress: 80.95% complete, ETA 00:02:47
# Fork: 3 of 3
# Warmup Iteration   1: 294299.824 ns/op
# Warmup Iteration   2: 288862.706 ns/op
# Warmup Iteration   3: 289214.840 ns/op
# Warmup Iteration   4: 288548.092 ns/op
# Warmup Iteration   5: 293010.917 ns/op
# Warmup Iteration   6: 288856.475 ns/op
# Warmup Iteration   7: 289040.751 ns/op
# Warmup Iteration   8: 296619.734 ns/op
# Warmup Iteration   9: 289214.277 ns/op
# Warmup Iteration  10: 289155.805 ns/op
Iteration   1: 290487.387 ns/op
Iteration   2: 292652.107 ns/op
Iteration   3: 290565.796 ns/op
Iteration   4: 289851.493 ns/op
Iteration   5: 294712.428 ns/op
Iteration   6: 296299.076 ns/op
Iteration   7: 299780.443 ns/op
Iteration   8: 304877.087 ns/op
Iteration   9: 301733.724 ns/op
Iteration  10: 300310.117 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  295462.923 ?(99.9%) 3348.567 ns/op [Average]
  (min, avg, max) = (288938.249, 295462.923, 304877.087), stdev = 5011.978
  CI (99.9%): [292114.356, 298811.490] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 32)

# Run progress: 82.14% complete, ETA 00:02:37
# Fork: 1 of 3
# Warmup Iteration   1: 74205.474 ns/op
# Warmup Iteration   2: 72484.277 ns/op
# Warmup Iteration   3: 72627.193 ns/op
# Warmup Iteration   4: 72268.177 ns/op
# Warmup Iteration   5: 72507.259 ns/op
# Warmup Iteration   6: 71965.050 ns/op
# Warmup Iteration   7: 72317.000 ns/op
# Warmup Iteration   8: 72528.571 ns/op
# Warmup Iteration   9: 72324.891 ns/op
# Warmup Iteration  10: 72270.898 ns/op
Iteration   1: 73137.755 ns/op
Iteration   2: 72636.504 ns/op
Iteration   3: 72544.377 ns/op
Iteration   4: 72890.367 ns/op
Iteration   5: 71977.649 ns/op
Iteration   6: 75580.836 ns/op
Iteration   7: 62740.359 ns/op
Iteration   8: 63025.782 ns/op
Iteration   9: 63422.797 ns/op
Iteration  10: 63263.635 ns/op

# Run progress: 83.33% complete, ETA 00:02:26
# Fork: 2 of 3
# Warmup Iteration   1: 74258.183 ns/op
# Warmup Iteration   2: 72499.688 ns/op
# Warmup Iteration   3: 72002.665 ns/op
# Warmup Iteration   4: 72308.821 ns/op
# Warmup Iteration   5: 72288.280 ns/op
# Warmup Iteration   6: 71948.497 ns/op
# Warmup Iteration   7: 71781.919 ns/op
# Warmup Iteration   8: 71946.673 ns/op
# Warmup Iteration   9: 72023.721 ns/op
# Warmup Iteration  10: 72337.598 ns/op
Iteration   1: 72735.704 ns/op
Iteration   2: 72157.002 ns/op
Iteration   3: 71936.263 ns/op
Iteration   4: 72446.360 ns/op
Iteration   5: 72198.099 ns/op
Iteration   6: 75459.968 ns/op
Iteration   7: 62039.026 ns/op
Iteration   8: 63940.868 ns/op
Iteration   9: 62451.320 ns/op
Iteration  10: 62916.340 ns/op

# Run progress: 84.52% complete, ETA 00:02:16
# Fork: 3 of 3
# Warmup Iteration   1: 73518.951 ns/op
# Warmup Iteration   2: 72061.340 ns/op
# Warmup Iteration   3: 71869.858 ns/op
# Warmup Iteration   4: 72758.799 ns/op
# Warmup Iteration   5: 72052.488 ns/op
# Warmup Iteration   6: 71907.394 ns/op
# Warmup Iteration   7: 71694.248 ns/op
# Warmup Iteration   8: 71721.536 ns/op
# Warmup Iteration   9: 71846.036 ns/op
# Warmup Iteration  10: 71808.350 ns/op
Iteration   1: 72275.141 ns/op
Iteration   2: 72038.608 ns/op
Iteration   3: 72485.698 ns/op
Iteration   4: 71819.194 ns/op
Iteration   5: 71975.039 ns/op
Iteration   6: 75114.835 ns/op
Iteration   7: 62332.874 ns/op
Iteration   8: 61923.235 ns/op
Iteration   9: 61839.263 ns/op
Iteration  10: 62020.109 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  68777.500 ?(99.9%) 3462.224 ns/op [Average]
  (min, avg, max) = (61839.263, 68777.500, 75580.836), stdev = 5182.095
  CI (99.9%): [65315.276, 72239.725] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 128)

# Run progress: 85.71% complete, ETA 00:02:05
# Fork: 1 of 3
# Warmup Iteration   1: 18500.336 ns/op
# Warmup Iteration   2: 17966.643 ns/op
# Warmup Iteration   3: 17977.566 ns/op
# Warmup Iteration   4: 18461.775 ns/op
# Warmup Iteration   5: 15027.872 ns/op
# Warmup Iteration   6: 14998.325 ns/op
# Warmup Iteration   7: 15023.523 ns/op
# Warmup Iteration   8: 15096.244 ns/op
# Warmup Iteration   9: 15021.257 ns/op
# Warmup Iteration  10: 15147.752 ns/op
Iteration   1: 15127.995 ns/op
Iteration   2: 15061.841 ns/op
Iteration   3: 15083.656 ns/op
Iteration   4: 15124.732 ns/op
Iteration   5: 15113.727 ns/op
Iteration   6: 15529.731 ns/op
Iteration   7: 15859.323 ns/op
Iteration   8: 15876.106 ns/op
Iteration   9: 15812.514 ns/op
Iteration  10: 15885.430 ns/op

# Run progress: 86.90% complete, ETA 00:01:55
# Fork: 2 of 3
# Warmup Iteration   1: 18517.760 ns/op
# Warmup Iteration   2: 18050.839 ns/op
# Warmup Iteration   3: 18022.544 ns/op
# Warmup Iteration   4: 18245.477 ns/op
# Warmup Iteration   5: 15010.995 ns/op
# Warmup Iteration   6: 15170.064 ns/op
# Warmup Iteration   7: 15116.491 ns/op
# Warmup Iteration   8: 15161.010 ns/op
# Warmup Iteration   9: 14933.679 ns/op
# Warmup Iteration  10: 15099.744 ns/op
Iteration   1: 14962.255 ns/op
Iteration   2: 14968.321 ns/op
Iteration   3: 14956.298 ns/op
Iteration   4: 14906.940 ns/op
Iteration   5: 14984.987 ns/op
Iteration   6: 15314.264 ns/op
Iteration   7: 15591.719 ns/op
Iteration   8: 15463.564 ns/op
Iteration   9: 15460.417 ns/op
Iteration  10: 15996.101 ns/op

# Run progress: 88.10% complete, ETA 00:01:44
# Fork: 3 of 3
# Warmup Iteration   1: 19410.756 ns/op
# Warmup Iteration   2: 18139.345 ns/op
# Warmup Iteration   3: 18072.425 ns/op
# Warmup Iteration   4: 18256.003 ns/op
# Warmup Iteration   5: 15097.702 ns/op
# Warmup Iteration   6: 15111.088 ns/op
# Warmup Iteration   7: 15105.294 ns/op
# Warmup Iteration   8: 15129.039 ns/op
# Warmup Iteration   9: 15087.252 ns/op
# Warmup Iteration  10: 15285.062 ns/op
Iteration   1: 15116.062 ns/op
Iteration   2: 15090.017 ns/op
Iteration   3: 15224.712 ns/op
Iteration   4: 15058.380 ns/op
Iteration   5: 15076.827 ns/op
Iteration   6: 15380.568 ns/op
Iteration   7: 15704.807 ns/op
Iteration   8: 15543.588 ns/op
Iteration   9: 15571.549 ns/op
Iteration  10: 15606.498 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  15348.431 ?(99.9%) 223.267 ns/op [Average]
  (min, avg, max) = (14906.940, 15348.431, 15996.101), stdev = 334.175
  CI (99.9%): [15125.164, 15571.698] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 512)

# Run progress: 89.29% complete, ETA 00:01:34
# Fork: 1 of 3
# Warmup Iteration   1: 4384.250 ns/op
# Warmup Iteration   2: 4804.444 ns/op
# Warmup Iteration   3: 4189.041 ns/op
# Warmup Iteration   4: 4956.598 ns/op
# Warmup Iteration   5: 4861.888 ns/op
# Warmup Iteration   6: 4876.798 ns/op
# Warmup Iteration   7: 4862.325 ns/op
# Warmup Iteration   8: 4882.423 ns/op
# Warmup Iteration   9: 4885.435 ns/op
# Warmup Iteration  10: 4467.235 ns/op
Iteration   1: 4491.859 ns/op
Iteration   2: 4456.160 ns/op
Iteration   3: 4378.937 ns/op
Iteration   4: 4377.863 ns/op
Iteration   5: 4398.866 ns/op
Iteration   6: 4480.645 ns/op
Iteration   7: 4608.981 ns/op
Iteration   8: 4509.917 ns/op
Iteration   9: 4540.754 ns/op
Iteration  10: 4519.374 ns/op

# Run progress: 90.48% complete, ETA 00:01:23
# Fork: 2 of 3
# Warmup Iteration   1: 4417.332 ns/op
# Warmup Iteration   2: 4837.993 ns/op
# Warmup Iteration   3: 4208.248 ns/op
# Warmup Iteration   4: 4963.647 ns/op
# Warmup Iteration   5: 4927.073 ns/op
# Warmup Iteration   6: 4887.792 ns/op
# Warmup Iteration   7: 4867.574 ns/op
# Warmup Iteration   8: 4874.402 ns/op
# Warmup Iteration   9: 4862.645 ns/op
# Warmup Iteration  10: 4518.698 ns/op
Iteration   1: 4458.527 ns/op
Iteration   2: 4468.361 ns/op
Iteration   3: 4364.901 ns/op
Iteration   4: 4359.978 ns/op
Iteration   5: 4338.498 ns/op
Iteration   6: 4455.835 ns/op
Iteration   7: 4522.034 ns/op
Iteration   8: 4484.659 ns/op
Iteration   9: 4494.817 ns/op
Iteration  10: 4495.097 ns/op

# Run progress: 91.67% complete, ETA 00:01:13
# Fork: 3 of 3
# Warmup Iteration   1: 4436.282 ns/op
# Warmup Iteration   2: 4877.135 ns/op
# Warmup Iteration   3: 4234.073 ns/op
# Warmup Iteration   4: 4940.780 ns/op
# Warmup Iteration   5: 4904.392 ns/op
# Warmup Iteration   6: 4899.234 ns/op
# Warmup Iteration   7: 4901.496 ns/op
# Warmup Iteration   8: 4891.757 ns/op
# Warmup Iteration   9: 4887.062 ns/op
# Warmup Iteration  10: 4486.050 ns/op
Iteration   1: 4483.435 ns/op
Iteration   2: 4456.642 ns/op
Iteration   3: 4370.796 ns/op
Iteration   4: 4359.803 ns/op
Iteration   5: 4351.001 ns/op
Iteration   6: 4461.781 ns/op
Iteration   7: 4540.268 ns/op
Iteration   8: 4532.157 ns/op
Iteration   9: 4552.617 ns/op
Iteration  10: 4521.549 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  4461.204 ?(99.9%) 47.803 ns/op [Average]
  (min, avg, max) = (4338.498, 4461.204, 4608.981), stdev = 71.549
  CI (99.9%): [4413.401, 4509.007] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 2048)

# Run progress: 92.86% complete, ETA 00:01:02
# Fork: 1 of 3
# Warmup Iteration   1: 1511.050 ns/op
# Warmup Iteration   2: 1203.845 ns/op
# Warmup Iteration   3: 1051.855 ns/op
# Warmup Iteration   4: 1190.308 ns/op
# Warmup Iteration   5: 1186.287 ns/op
# Warmup Iteration   6: 1186.647 ns/op
# Warmup Iteration   7: 1183.675 ns/op
# Warmup Iteration   8: 1190.586 ns/op
# Warmup Iteration   9: 1197.796 ns/op
# Warmup Iteration  10: 1094.721 ns/op
Iteration   1: 1075.206 ns/op
Iteration   2: 1083.123 ns/op
Iteration   3: 1071.874 ns/op
Iteration   4: 1089.103 ns/op
Iteration   5: 1074.778 ns/op
Iteration   6: 1110.394 ns/op
Iteration   7: 1116.813 ns/op
Iteration   8: 1127.129 ns/op
Iteration   9: 1121.170 ns/op
Iteration  10: 1121.581 ns/op

# Run progress: 94.05% complete, ETA 00:00:52
# Fork: 2 of 3
# Warmup Iteration   1: 1636.268 ns/op
# Warmup Iteration   2: 1245.983 ns/op
# Warmup Iteration   3: 1045.910 ns/op
# Warmup Iteration   4: 1195.748 ns/op
# Warmup Iteration   5: 1190.069 ns/op
# Warmup Iteration   6: 1192.905 ns/op
# Warmup Iteration   7: 1203.243 ns/op
# Warmup Iteration   8: 1195.721 ns/op
# Warmup Iteration   9: 1200.174 ns/op
# Warmup Iteration  10: 1043.114 ns/op
Iteration   1: 1044.396 ns/op
Iteration   2: 1046.994 ns/op
Iteration   3: 1039.387 ns/op
Iteration   4: 1044.145 ns/op
Iteration   5: 1124.766 ns/op
Iteration   6: 1081.636 ns/op
Iteration   7: 1114.180 ns/op
Iteration   8: 1121.581 ns/op
Iteration   9: 1088.910 ns/op
Iteration  10: 1089.093 ns/op

# Run progress: 95.24% complete, ETA 00:00:41
# Fork: 3 of 3
# Warmup Iteration   1: 1530.958 ns/op
# Warmup Iteration   2: 1233.515 ns/op
# Warmup Iteration   3: 1043.386 ns/op
# Warmup Iteration   4: 1197.501 ns/op
# Warmup Iteration   5: 1193.354 ns/op
# Warmup Iteration   6: 1187.717 ns/op
# Warmup Iteration   7: 1209.913 ns/op
# Warmup Iteration   8: 1184.168 ns/op
# Warmup Iteration   9: 1205.299 ns/op
# Warmup Iteration  10: 1078.936 ns/op
Iteration   1: 1091.636 ns/op
Iteration   2: 1074.592 ns/op
Iteration   3: 1086.118 ns/op
Iteration   4: 1077.098 ns/op
Iteration   5: 1078.045 ns/op
Iteration   6: 1113.701 ns/op
Iteration   7: 1124.583 ns/op
Iteration   8: 1130.463 ns/op
Iteration   9: 1122.005 ns/op
Iteration  10: 1131.845 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  1093.878 ?(99.9%) 18.836 ns/op [Average]
  (min, avg, max) = (1039.387, 1093.878, 1131.845), stdev = 28.192
  CI (99.9%): [1075.042, 1112.714] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3
# Parameters: (inputStreamSize = 1000000, skipLength = 8192)

# Run progress: 96.43% complete, ETA 00:00:31
# Fork: 1 of 3
# Warmup Iteration   1: 862.256 ns/op
# Warmup Iteration   2: 589.408 ns/op
# Warmup Iteration   3: 536.517 ns/op
# Warmup Iteration   4: 586.005 ns/op
# Warmup Iteration   5: 579.866 ns/op
# Warmup Iteration   6: 580.350 ns/op
# Warmup Iteration   7: 578.639 ns/op
# Warmup Iteration   8: 580.218 ns/op
# Warmup Iteration   9: 581.047 ns/op
# Warmup Iteration  10: 534.851 ns/op
Iteration   1: 533.743 ns/op
Iteration   2: 534.777 ns/op
Iteration   3: 540.328 ns/op
Iteration   4: 537.531 ns/op
Iteration   5: 539.491 ns/op
Iteration   6: 546.376 ns/op
Iteration   7: 558.525 ns/op
Iteration   8: 561.100 ns/op
Iteration   9: 556.636 ns/op
Iteration  10: 558.412 ns/op

# Run progress: 97.62% complete, ETA 00:00:20
# Fork: 2 of 3
# Warmup Iteration   1: 826.456 ns/op
# Warmup Iteration   2: 587.213 ns/op
# Warmup Iteration   3: 540.019 ns/op
# Warmup Iteration   4: 590.900 ns/op
# Warmup Iteration   5: 581.237 ns/op
# Warmup Iteration   6: 584.115 ns/op
# Warmup Iteration   7: 577.480 ns/op
# Warmup Iteration   8: 581.162 ns/op
# Warmup Iteration   9: 580.742 ns/op
# Warmup Iteration  10: 535.249 ns/op
Iteration   1: 535.045 ns/op
Iteration   2: 536.905 ns/op
Iteration   3: 535.945 ns/op
Iteration   4: 535.661 ns/op
Iteration   5: 540.646 ns/op
Iteration   6: 546.533 ns/op
Iteration   7: 556.958 ns/op
Iteration   8: 554.579 ns/op
Iteration   9: 554.086 ns/op
Iteration  10: 553.856 ns/op

# Run progress: 98.81% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 763.465 ns/op
# Warmup Iteration   2: 580.260 ns/op
# Warmup Iteration   3: 541.448 ns/op
# Warmup Iteration   4: 583.521 ns/op
# Warmup Iteration   5: 586.102 ns/op
# Warmup Iteration   6: 584.882 ns/op
# Warmup Iteration   7: 582.433 ns/op
# Warmup Iteration   8: 586.619 ns/op
# Warmup Iteration   9: 581.809 ns/op
# Warmup Iteration  10: 544.865 ns/op
Iteration   1: 536.932 ns/op
Iteration   2: 534.487 ns/op
Iteration   3: 537.681 ns/op
Iteration   4: 534.289 ns/op
Iteration   5: 548.063 ns/op
Iteration   6: 550.755 ns/op
Iteration   7: 560.138 ns/op
Iteration   8: 556.991 ns/op
Iteration   9: 561.591 ns/op
Iteration  10: 558.184 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip3":
  546.542 ?(99.9%) 6.780 ns/op [Average]
  (min, avg, max) = (533.743, 546.542, 561.591), stdev = 10.148
  CI (99.9%): [539.762, 553.322] (assumes normal distribution)


# Run complete. Total time: 00:14:39

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.

Benchmark                           (inputStreamSize)  (skipLength)  Mode  Cnt        Score       Error  Units
InputStreamSkipBenchmark.testSkip0            1000000             1  avgt   30  2457834.694 ? 33354.477  ns/op
InputStreamSkipBenchmark.testSkip0            1000000             8  avgt   30   324485.546 ?  9594.651  ns/op
InputStreamSkipBenchmark.testSkip0            1000000            32  avgt   30   120446.761 ?  2038.143  ns/op
InputStreamSkipBenchmark.testSkip0            1000000           128  avgt   30    78981.218 ?  1455.232  ns/op
InputStreamSkipBenchmark.testSkip0            1000000           512  avgt   30    88417.914 ?  1324.450  ns/op
InputStreamSkipBenchmark.testSkip0            1000000          2048  avgt   30    81705.707 ?   920.354  ns/op
InputStreamSkipBenchmark.testSkip0            1000000          8192  avgt   30    20579.287 ?   260.370  ns/op
InputStreamSkipBenchmark.testSkip1            1000000             1  avgt   30  1525217.235 ? 27978.461  ns/op
InputStreamSkipBenchmark.testSkip1            1000000             8  avgt   30   191228.879 ?  2728.044  ns/op
InputStreamSkipBenchmark.testSkip1            1000000            32  avgt   30    48150.083 ?  1148.057  ns/op
InputStreamSkipBenchmark.testSkip1            1000000           128  avgt   30    11815.100 ?   161.631  ns/op
InputStreamSkipBenchmark.testSkip1            1000000           512  avgt   30     2957.656 ?    41.162  ns/op
InputStreamSkipBenchmark.testSkip1            1000000          2048  avgt   30      830.994 ?    13.880  ns/op
InputStreamSkipBenchmark.testSkip1            1000000          8192  avgt   30      462.193 ?     6.262  ns/op
InputStreamSkipBenchmark.testSkip2            1000000             1  avgt   30  1537556.494 ? 21742.419  ns/op
InputStreamSkipBenchmark.testSkip2            1000000             8  avgt   30   189332.207 ?  3247.491  ns/op
InputStreamSkipBenchmark.testSkip2            1000000            32  avgt   30    48486.593 ?  2287.385  ns/op
InputStreamSkipBenchmark.testSkip2            1000000           128  avgt   30    11193.212 ?   197.053  ns/op
InputStreamSkipBenchmark.testSkip2            1000000           512  avgt   30     2993.116 ?    79.159  ns/op
InputStreamSkipBenchmark.testSkip2            1000000          2048  avgt   30      736.894 ?     8.002  ns/op
InputStreamSkipBenchmark.testSkip2            1000000          8192  avgt   30      447.539 ?     4.169  ns/op
InputStreamSkipBenchmark.testSkip3            1000000             1  avgt   30  2149719.921 ? 26904.372  ns/op
InputStreamSkipBenchmark.testSkip3            1000000             8  avgt   30   295462.923 ?  3348.567  ns/op
InputStreamSkipBenchmark.testSkip3            1000000            32  avgt   30    68777.500 ?  3462.224  ns/op
InputStreamSkipBenchmark.testSkip3            1000000           128  avgt   30    15348.431 ?   223.267  ns/op
InputStreamSkipBenchmark.testSkip3            1000000           512  avgt   30     4461.204 ?    47.803  ns/op
InputStreamSkipBenchmark.testSkip3            1000000          2048  avgt   30     1093.878 ?    18.836  ns/op
InputStreamSkipBenchmark.testSkip3            1000000          8192  avgt   30      546.542 ?     6.780  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From naoto at openjdk.java.net  Wed Apr 13 22:08:00 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Apr 2022 22:08:00 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v6]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <Maz8TWgJBAWu0YaefxGxryaSziC-9WRh7xC5HRn7ODk=.c4c04fc0-ccd0-493d-8cc4-a49f0bf0a51a@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Modified class desc of `IsoFields`

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/7f596789..474dc85a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=04-05

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From duke at openjdk.java.net  Wed Apr 13 22:10:09 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 22:10:09 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v17]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <3_faiutX4epQEXucP2z6IcaH5QLh4py7mqmuvYeUZTs=.9604e1eb-dd98-44fe-955b-d08966a78ba1@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  Copyright latest year to 2022

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/2f5617bb..4476c761

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=15-16

  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From bpb at openjdk.java.net  Wed Apr 13 22:15:15 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 13 Apr 2022 22:15:15 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <bqVpACr36Y57HyfkdPhkky31heyeGtVmHiuq7sImIdU=.bafb68b4-23f1-483e-a1ae-3852d9852c7f@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

Expect the Unexpeted.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8231

From duke at openjdk.java.net  Wed Apr 13 22:20:14 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 22:20:14 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  update LastModified

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/4476c761..d110ecfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=16-17

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr 13 22:20:15 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 13 Apr 2022 22:20:15 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
 <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>
Message-ID: <aeAmEgTYdl1ETRnV2HJMmWJzm3Po_la_JMlHSRxjV6w=.c416dccb-e233-4bca-b3d3-98af298ec2fd@github.com>

On Wed, 13 Apr 2022 20:06:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in:
>>   src/java.desktop
>>   src/java.management
>>   src/jdk.internal.vm.ci
>>   src/jdk.jfr
>>   src/jdk.management.jfr
>>   src/jdk.management
>>   src/utils/IdealGraphVisualizer
>
> Looks good for changes in i18n related call sites, assuming that the copyright years will be updated.
> 
> Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`?

@naotoj @JoeWang-Java copyright updated to 2022. LastModified updated to 2022.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr 13 22:44:19 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 22:44:19 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
Message-ID: <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

src/java.base/share/classes/java/lang/Character.java line 8574:

> 8572:         private static final HashMap<String, Character.UnicodeScript> aliases;
> 8573:         static {
> 8574:             aliases = HashMap.newHashMap(162);

@naotoj Seems like this magic number is likely to go out of date. Should there be a test for it like the one you updated for NUM_ENTITIES? [JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From cjplummer at openjdk.java.net  Wed Apr 13 22:45:18 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 13 Apr 2022 22:45:18 GMT
Subject: RFR: 8284853: Fix varios 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <QJCzMs3gkj9ursFFOEjh83AzGXE69C_m2I8N0rj-RKc=.a5484f8c-880b-4f18-b0c1-3db360b5b66d@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

test/jdk/java/lang/StackWalker/StackStreamTest.java line 218:

> 216:     private static <T> void equalsOrThrow(String label, List<T> list, List<T> expected) {
> 217:         System.out.println("List:     " + list);
> 218:         System.out.println("Expected: " + list);

I think there is a per-existing bug here. Shouldn't the second println print `expected` instead of `list`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231

From naoto at openjdk.java.net  Wed Apr 13 22:56:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Apr 2022 22:56:31 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>
Message-ID: <uNsLbPcKwzq-jlie7JtG8BbwMtMYJ-hTH1h4SD9aybo=.8acf4bf4-4cb7-4b8d-9261-4e29e6ba3ed2@github.com>

On Wed, 13 Apr 2022 22:40:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update LastModified
>
> src/java.base/share/classes/java/lang/Character.java line 8574:
> 
>> 8572:         private static final HashMap<String, Character.UnicodeScript> aliases;
>> 8573:         static {
>> 8574:             aliases = HashMap.newHashMap(162);
> 
> @naotoj Seems like this magic number is likely to go out of date. Should there be a test for it like the one you updated for NUM_ENTITIES? [JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465).

Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr 13 23:01:16 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 23:01:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
Message-ID: <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 171:

> 169:         _current = 0;
> 170:         _size  = size;
> 171:         _references = HashMap.newHashMap(_size);

Not `_size+2` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Wed Apr 13 23:04:14 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 13 Apr 2022 23:04:14 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
Message-ID: <Uj8JrQyYkThjoKzfdhwCw7pjXvFtme8GRjk5zYlHMZI=.75e1ba4c-bc6f-49f2-a040-e11bf7dff7ef@github.com>

On Wed, 13 Apr 2022 21:58:06 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jmh

test/micro/org/openjdk/bench/java/io/InputStreamSkipBenchmark.java line 54:

> 52:     @Benchmark
> 53:     public long testSkip0(Data data) throws IOException {
> 54:         TestBaseInputStream0 testBaseInputStream = new TestBaseInputStream0(data.inputStreamSize);

Instead of creating 3 methods with identical bodies, I recommend using an enum to represent the type of buffers. An example at https://github.com/openjdk/jdk/blob/7a9844cb1cd18c18ce097741cba7db1148c83de0/test/micro/org/openjdk/bench/java/util/HashMapBench.java#L65-L71

For enum values, you can name them like `LOCAL_VARIABLE`, `FIELD`, `SOFT_REFERENCE`, which is more descriptive than current "0, 1, 2," etc.

test/micro/org/openjdk/bench/java/io/InputStreamSkipBenchmark.java line 127:

> 125: 
> 126:         @Override
> 127:         public int read(byte[] b, int off, int len) throws IOException {

I suggest we actually write into the byte array to better simulate overheads (maybe by generating a number with `ThreadLocalRandom`). Otherwise, the benchmark may have exaggerated the performance gains of large skips.

To simulate overhead on each read call, you can perform some extra activity consumed by the blackhole (possibly pass jmh blackhole through input stream constructor)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From smarks at openjdk.java.net  Wed Apr 13 23:06:16 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 23:06:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
Message-ID: <llN0hu4w8KoDvGAH7i0cILjDW8fM8cRbpWT5pS0GMzA=.7831e7a1-e074-4bad-b5d9-c153d535bef2@github.com>

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java line 1819:

> 1817:     Map<String, OneAttr> items;
> 1818:     LargeContainer(int size) {
> 1819:         items = HashMap.newHashMap(size*2+1);

I'm wondering if we should change this to just `newHashMap(size)` since it looks like this container is intended to hold up to `size` items. @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr 13 23:29:19 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 23:29:19 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
Message-ID: <xKjqLHNKD27oflyQv-JEVlumtfbMxbXoAETc84R4PcU=.1f7cb340-1bc8-476d-852b-05bfbd0b3444@github.com>

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 102:

> 100:     /* Only for use by Runtime.exec(...String[]envp...) */
> 101:     static Map<String,String> emptyEnvironment(int capacity) {
> 102:         return new StringEnvironment(HashMap.newHashMap(capacity));

This change is correct, since this is called with the length of an array that's used to populate the environment. It really should be named `size` instead of `capacity`. However the windows version of this code simply calls `super(capacity)` as it's a subclass of `HashMap`, which is wrong. Well, probably not worth changing this now. We may need to revisit this later to do some cleaning up. (And also the strange computation in the static initializer at line 71.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From smarks at openjdk.java.net  Wed Apr 13 23:51:16 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 13 Apr 2022 23:51:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
 <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>
Message-ID: <vEz7aCqZt0iNT81M6eQknpR097fgnYuwt83OkZ9Sv0U=.70cc6cdb-b842-437a-97fb-87f82c0b3ec6@github.com>

On Wed, 13 Apr 2022 20:06:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in:
>>   src/java.desktop
>>   src/java.management
>>   src/jdk.internal.vm.ci
>>   src/jdk.jfr
>>   src/jdk.management.jfr
>>   src/jdk.management
>>   src/utils/IdealGraphVisualizer
>
> Looks good for changes in i18n related call sites, assuming that the copyright years will be updated.
> 
> Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`?

@naotoj wrote:

> Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`?

The only thing that uses this utility now is `test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java`, which is on the problem list. The cleanup is covered by [JDK-8282120](https://bugs.openjdk.java.net/browse/JDK-8282120). After this PR gets integrated, the Enum ConstantDirectory will be initialized with `HashMap.newHashMap(universe.length)` so the OptimalCapacity test won't really be testing anything. I'll take another look at it and the library utility, but I suspect the cleanup may simply be removing them entirely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From naoto at openjdk.java.net  Thu Apr 14 00:32:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 00:32:19 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <vEz7aCqZt0iNT81M6eQknpR097fgnYuwt83OkZ9Sv0U=.70cc6cdb-b842-437a-97fb-87f82c0b3ec6@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
 <qpvhWVidYy6h6EC2eMfJeqkwifiWrFOVFPZljfEjimg=.f39246a8-4e98-4969-a0ef-7a8943bebec2@github.com>
 <vEz7aCqZt0iNT81M6eQknpR097fgnYuwt83OkZ9Sv0U=.70cc6cdb-b842-437a-97fb-87f82c0b3ec6@github.com>
Message-ID: <_7xS1jx8qIo088_W_yOC8VCiUgRyl4eWXrNSWSa6OPY=.e8d5bdd1-91bb-4eb7-8043-20197415e5d8@github.com>

On Wed, 13 Apr 2022 23:48:06 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> but I suspect the cleanup may simply be removing them entirely.

+1 for removing it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 01:18:10 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 01:18:10 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>
Message-ID: <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>

On Wed, 13 Apr 2022 22:57:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Not `_size+2` ?

I don't have a idea here why he original use the + 2.
Is there any guy more familiar with this code tell me why?
Thanks!

> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings.

I looked the codes and don't think so..
If I'm wrong, I'm glad to fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From bpb at openjdk.java.net  Thu Apr 14 01:49:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Apr 2022 01:49:33 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
Message-ID: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>

Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

-------------

Commit messages:
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

Changes: https://git.openjdk.java.net/jdk/pull/8235/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6478546
  Stats: 93 lines in 2 files changed: 52 ins; 8 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.java.net/jdk/pull/8235

From bpb at openjdk.java.net  Thu Apr 14 01:49:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 14 Apr 2022 01:49:33 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <LxzkVI7H3jEsfS5uEt55GsCqMSDKidbnk7OcNex4Muc=.b89742f1-68fc-4fb7-bef3-196d89ea1bfe@github.com>

On Thu, 14 Apr 2022 01:40:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

Currently for `java.io.FileInputStream.read(byte[],int,int)` and `java.io.FileOutputStream.write(byte[],int,int)`, for example, if the number of bytes respectively to be read or written exceeds 8192, an array of the total length of the read or write is allocated. For large reads or writes this could be significant. It is proposed to limit the maximum allocation size to 1 MB and perform the read or write by looping with this buffer. For reading or writing less than 1 MB, there is no effective change in the implementation.

This change both saves off-heap memory and increases throughput. An allocation of 1  MB is only 0.42% the size of the buffer in the JBS issue, 501 x 501 x 501 x 2 (= 251,503,002), so for this case the memory reduction is drastic. Reading throughput is almost doubled and writing throughput improved by about 50%. As measured on macOS, the throughput of the methods mentioned above before the change was:


Benchmark         Mode  Cnt   Score   Error  Units
ReadWrite.read   thrpt    5  10.108 ? 0.264  ops/s
ReadWrite.write  thrpt    5   7.188 ? 0.431  ops/s

and that after is:

Benchmark         Mode  Cnt   Score   Error  Units
ReadWrite.read   thrpt    5  20.112 ? 0.262  ops/s
ReadWrite.write  thrpt    5  10.644 ? 4.568  ops/s

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From vromero at openjdk.java.net  Thu Apr 14 02:10:13 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 14 Apr 2022 02:10:13 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <oYmclgQ1fYcZTautz92dpD-XsnP69uLmHItYoAuF0cs=.318afb6b-2c77-4de5-87f0-382d32045ad7@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 242:

> 240:         PATTERN_SWITCH(JDK17, Fragments.FeaturePatternSwitch, DiagKind.PLURAL),
> 241:         REDUNDANT_STRICTFP(JDK17),
> 242:         TOTAL_PATTERN_IN_INSTACEOF(JDK17, Fragments.FeatureTotalPatternsInInstanceof, DiagKind.PLURAL),

shouldn't be JDK19?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From ecki at zusammenkunft.net  Thu Apr 14 02:19:42 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 14 Apr 2022 02:19:42 +0000
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <rJTc8DtyHXr8x0Z0U15AAcB-ihSb5ibwP05T2NUhxEg=.08f07667-9550-4256-a57f-278c6367eea4@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <sAiKYsfPHyfQncDmad44DeOC6MKMz7mzdmg3Ho70qdg=.48de2c94-9a36-4d01-8381-33e48649ad38@github.com>
 <fGaE8cDxdXuvRVY4fpeYjknmL1sYQ5zbDBCQfzpmHgo=.12be505c-4ad8-42c2-a0b4-f0ec8960fdbf@github.com>
 <84YsekICpjY77dhw3Tx9QLKlO1EHQ01kuIlZEXKgTXQ=.e3692542-d8bb-49e2-9949-6a1ff292e9a5@github.com>
 <rJTc8DtyHXr8x0Z0U15AAcB-ihSb5ibwP05T2NUhxEg=.08f07667-9550-4256-a57f-278c6367eea4@github.com>
Message-ID: <AM9P193MB114234E0B5EF379BC114384FFFEF9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

If you consider doing benchmarks in detail maybe consider a static buffer, too? (Especially if it can be used in multiple implementations?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von XenoAmess <duke at openjdk.java.net>
Gesendet: Wednesday, April 13, 2022 11:58:06 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Betreff: Re: RFR: 8284638: store skip buffers in InputStream Object [v2]

On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman You are correct about this. But I wonder if this be a problem, why Reader class can afford store a skip buffer for each Reader.
>>>
>>> Is there anything different in the situations about skipBuffer in Reader and InputStream?
>>
>> Maybe the skip buffer in Reader should be looked at too, esp. as it couldpotentially grow to 16k bytes. The concern with changing InputStream.skip is that there may be a lot more input streams than readers in use, esp. if there is an input stream for every socket connection.
>
>> @AlanBateman Is the concern about holding more memory sufficient to retain the buffer using a SoftReference so it can be freed eagerly?
>> These buffers are never read from, so are quite a waste, but at least they are only used when
>> the underlying stream overrides skip.
>
> Maybe but I think it needs some benchmarks to know if caching a byte[] will help or just bloat memory. If the InputStream is to a file or socket then maybe skip is dominated by the I/O rather than the array allocation and zero'ing.

@AlanBateman jmh test added

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From jpai at openjdk.java.net  Thu Apr 14 03:17:17 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 14 Apr 2022 03:17:17 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v7]
In-Reply-To: <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
Message-ID: <t3ekrJ3dCpZU9ch6qfb9LA_KULtOk68ct3u4-gKWOWg=.94f921fd-0f69-4771-9038-d9a9178bbe18@github.com>

On Wed, 13 Apr 2022 17:42:57 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @LanceAndersen's review

Marked as reviewed by jpai (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From joehw at openjdk.java.net  Thu Apr 14 03:31:15 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 14 Apr 2022 03:31:15 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>
 <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>
Message-ID: <BNmV2tQmiQBFjvZ_vxRdfPyqy79igTcftERt5Lsy1QM=.c053d883-e793-4183-b525-b645a96294e1@github.com>

On Thu, 14 Apr 2022 01:15:05 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 171:
>> 
>>> 169:         _current = 0;
>>> 170:         _size  = size;
>>> 171:         _references = HashMap.newHashMap(_size);
>> 
>> Not `_size+2` ?
>
>> Not `_size+2` ?
> 
> I don't have a idea here why he original use the + 2.
> Is there any guy more familiar with this code tell me why?
> Thanks!

size, not size + 2, same situation as size*2+1 below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From joehw at openjdk.java.net  Thu Apr 14 03:42:16 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 14 Apr 2022 03:42:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>
 <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>
Message-ID: <TeeKCwr29XOequYIh4iw9_YGqyOWx1r0YwqTP64VgZ8=.f1094640-6f9c-4c2c-9120-f0c6c0031f79@github.com>

On Thu, 14 Apr 2022 01:13:18 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java line 1819:
>> 
>>> 1817:     Map<String, OneAttr> items;
>>> 1818:     LargeContainer(int size) {
>>> 1819:         items = HashMap.newHashMap(size*2+1);
>> 
>> I'm wondering if we should change this to just `newHashMap(size)` since it looks like this container is intended to hold up to `size` items. @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings.
>
>> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings.
> 
> I looked the codes and don't think so..
> If I'm wrong, I'm glad to fix.

Stuart's right, I looked at the code, it's as you said a failed attempt, "size" would be good. So HashMap.newHashMap(size) would actually be a small improvement.

It's an interesting impl the way it used HashMap, but it's 20 year code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 04:13:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 04:13:13 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <AM9P193MB114234E0B5EF379BC114384FFFEF9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <AM9P193MB114234E0B5EF379BC114384FFFEF9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <Hew3ht7BGWgZ15pB6QlPudaPeLXK02N3NkXtCV2sxFI=.2b4e5135-59af-4a18-800b-3d6ae0d74c2f@github.com>

On Thu, 14 Apr 2022 02:21:23 GMT, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

> If you consider doing benchmarks in detail maybe consider a static buffer, too? (Especially if it can be used in multiple implementations?)

Why as it already be a unacceptable option for security reason?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From djelinski at openjdk.java.net  Thu Apr 14 06:01:15 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 14 Apr 2022 06:01:15 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <PQLG32LE0dPgWyqG2MrICHNy6yFEi5Xqo38MEh-XBfw=.36114622-1ff5-40e9-ae8a-c5aa9701139e@github.com>

On Thu, 14 Apr 2022 01:40:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

The benchmark results are quite unexpected. Would we benefit from reducing the buffer size even further?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From alanb at openjdk.java.net  Thu Apr 14 06:27:05 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 14 Apr 2022 06:27:05 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <NZjD51lFkj2RsYCCT6lSL4fNoCMnyLiAxDtXAPIIn80=.b8789d0c-5e92-4d4d-8d94-833ca4c947af@github.com>

On Thu, 14 Apr 2022 01:40:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

src/java.base/share/native/libjava/io_util.c line 133:

> 131:             if (nread == 0)
> 132:                 nread = -1;
> 133:             break;

Can you prototype doing the loop in Java rather than in native code so that there is less native code to maintain?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From dfuchs at openjdk.java.net  Thu Apr 14 08:45:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 14 Apr 2022 08:45:19 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16]
In-Reply-To: <tyREZE5_pIE3fSFQ00_rWQqm3PuMcbtv5HpmUnHebkk=.9779c0a0-a489-4dd0-a5db-dbf3cfd5ef74@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <alykClXOoxLuAX40wiHjq9twn9rXyA67_epbYmb3s08=.0dd97e53-bd41-4513-b615-97796830eb4a@github.com>
 <tyREZE5_pIE3fSFQ00_rWQqm3PuMcbtv5HpmUnHebkk=.9779c0a0-a489-4dd0-a5db-dbf3cfd5ef74@github.com>
Message-ID: <je65Tw3mTsl11lY5ckAzBxC6cOOZ71S1EK8EGCgWqTg=.4bf8d576-0773-4067-a773-84a70fb9a578@github.com>

On Wed, 13 Apr 2022 19:28:08 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

Changes to `java.net.http` look good to me. I haven't spotted anything obviously wrong in the rest, but should defer to reviewers of these areas.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 08:53:10 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 14 Apr 2022 08:53:10 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 177:

> 175:         allowPatternSwitch = (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH)) &&
> 176:                              Feature.PATTERN_SWITCH.allowedInSource(source);
> 177:         allowTotalPatternsInstance = (preview.isEnabled() || !preview.isPreview(Feature.TOTAL_PATTERN_IN_INSTACEOF)) &&

BTW, do we need to rename total -> unconditional with the recent update in the spec?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1349:

> 1347:     public static PatternPrimaryType primaryPatternType(JCTree pat) {
> 1348:         return switch (pat.getTag()) {
> 1349:             case BINDINGPATTERN -> new PatternPrimaryType(((JCBindingPattern) pat).type);

Cast may be redundant here since the signature of primaryPatternType changed to access JCTrees

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1377:

> 1375:         }
> 1376:         JCExpression guard = ((JCPattern) cse).guard;
> 1377:         if (guard != null && guard.type.hasTag(BOOLEAN)) {

In the spec we see the following:

> A pattern case element is said to be unrefined if either (i) it has no associated when expression, or (ii) it has an associated when expression that is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with value true. A case element is unrefined if it is not a pattern case element or it is an unrefined pattern case element.

However, in the definition of `unconditional` I don't see the part for the constant expression.

I wonder if the spec should be updated or the code at this point

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From aturbanov at openjdk.java.net  Thu Apr 14 09:28:17 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 09:28:17 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8284853: Fix various 'expected' typo
  improve test log

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8231/files
  - new: https://git.openjdk.java.net/jdk/pull/8231/files/fe6d9890..9fc75e89

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231

PR: https://git.openjdk.java.net/jdk/pull/8231

From stuefe at openjdk.java.net  Thu Apr 14 09:39:38 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 14 Apr 2022 09:39:38 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to describe
 zombie problem
Message-ID: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>

ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.

Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.

-------------

Commit messages:
 - add comment

Changes: https://git.openjdk.java.net/jdk/pull/8240/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8240&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284874
  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8240/head:pull/8240

PR: https://git.openjdk.java.net/jdk/pull/8240

From stuefe at openjdk.java.net  Thu Apr 14 09:49:58 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 14 Apr 2022 09:49:58 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v2]
In-Reply-To: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
Message-ID: <JQlJrMz3_dZCfykD7tyZ5XgF-xcULsKRm2UJ3utpbTo=.85712f61-30fe-4148-96e9-cf995b95b322@github.com>

> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
> 
> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  modify comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8240/files
  - new: https://git.openjdk.java.net/jdk/pull/8240/files/d893438b..aac07eaf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8240&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8240&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8240/head:pull/8240

PR: https://git.openjdk.java.net/jdk/pull/8240

From yyang at openjdk.java.net  Thu Apr 14 10:42:11 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 14 Apr 2022 10:42:11 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
Message-ID: <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>

On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284853: Fix various 'expected' typo
>   improve test log

I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231

From redestad at openjdk.java.net  Thu Apr 14 11:26:27 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 14 Apr 2022 11:26:27 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables
Message-ID: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>

This patch examines and optimizes `Wrapper` lookups.

First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  

Micros show benefits across the board for warmed up case:


Baseline, OOTB
Benchmark                  Mode  Cnt   Score   Error  Units
Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op

Patch, OOTB
Benchmark                  Mode  Cnt   Score   Error  Units
Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op


For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:


Baseline, -Xint
Benchmark                  Mode  Cnt     Score     Error  Units
Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op

Patch, -Xint
Benchmark                  Mode  Cnt     Score     Error  Units
Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op

-------------

Commit messages:
 - Revert accidental changes to MethodType
 - Fix typo
 - Missed some changes refactoring, import DontInline
 - Merge branch 'master' into wrappers
 - Cleanup, use mask instead of modulo
 - Cleanup, add forPrimitiveType micro, reinstantiate char hashing
 - Add required add-exports to BuildMicrobenchmark.gmk
 - Fix imports
 - Tune sun.invoke.util.Wrapper accessors

Changes: https://git.openjdk.java.net/jdk/pull/8242/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8242&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284880
  Stats: 256 lines in 3 files changed: 157 ins; 59 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8242/head:pull/8242

PR: https://git.openjdk.java.net/jdk/pull/8242

From duke at openjdk.java.net  Thu Apr 14 11:37:51 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 14 Apr 2022 11:37:51 GMT
Subject: RFR: 8284866: Add test to JDK-8273056
Message-ID: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>

Hello,
this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.

-------------

Commit messages:
 - 8284866: Add test to JDK-8273056

Changes: https://git.openjdk.java.net/jdk/pull/8243/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8243&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284866
  Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8243/head:pull/8243

PR: https://git.openjdk.java.net/jdk/pull/8243

From jlaskey at openjdk.java.net  Thu Apr 14 11:52:14 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 14 Apr 2022 11:52:14 GMT
Subject: RFR: 8284866: Add test to JDK-8273056
In-Reply-To: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
References: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
Message-ID: <PMNPG9qqarR_NZSImf5wwJTFlFRt-UA_7PD_qI9PUkM=.84f9f2d9-cf3d-407b-93c1-f711b49ceb43@github.com>

On Thu, 14 Apr 2022 11:31:03 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Hello,
> this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8243

From mcimadamore at openjdk.java.net  Thu Apr 14 12:01:30 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 14 Apr 2022 12:01:30 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v30]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <Ih20Rak2R5bagEZyZh6qOR17fk4C2CB066iBvD1bUvQ=.b6ec97c5-55e1-40ed-a9aa-e044531f9d4a@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with four additional commits since the last revision:

 - Add ValueLayout changes
 - Tweak support for array element var handle
 - Add @see
 - Initial push

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/8637379e..2e3d57a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=29
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=28-29

  Stats: 129 lines in 4 files changed: 97 ins; 25 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From erikj at openjdk.java.net  Thu Apr 14 12:48:15 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 12:48:15 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables
In-Reply-To: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
Message-ID: <pTSP3ltginxypML8zdjbwTwl-t5MpFPoaiKAVdR85Oo=.cb22ed9d-5bd6-4ab2-94cf-e826481841f5@github.com>

On Thu, 14 Apr 2022 11:19:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch examines and optimizes `Wrapper` lookups.
> 
> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
> 
> Micros show benefits across the board for warmed up case:
> 
> 
> Baseline, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
> 
> Patch, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
> 
> 
> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
> 
> 
> Baseline, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
> 
> Patch, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op

Build change looks ok.

make/test/BuildMicrobenchmark.gmk line 97:

> 95:     SRC := $(MICROBENCHMARK_SRC), \
> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --add-exports java.base/sun.invoke.util=ALL-UNNAMED, \

Suggestion:

    JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
        --add-exports java.base/sun.invoke.util=ALL-UNNAMED, \

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8242

From ihse at openjdk.java.net  Thu Apr 14 13:13:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 13:13:15 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
Message-ID: <X-2el87FZNWkIJqRe20t_Bl9wIiXf3fwfEt1TELtIZk=.a3adafdc-952b-4f8b-a0be-fa4415426f06@github.com>

On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284853: Fix various 'expected' typo
>   improve test log

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8231

From redestad at openjdk.java.net  Thu Apr 14 13:59:57 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 14 Apr 2022 13:59:57 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables [v2]
In-Reply-To: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
Message-ID: <FVsH-TlrmXY54QTyEtA0Z1OG4h2C56NCVlWGbeymUEs=.4c9a27a1-a17f-4118-8dc0-6a42df808152@github.com>

> This patch examines and optimizes `Wrapper` lookups.
> 
> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
> 
> Micros show benefits across the board for warmed up case:
> 
> 
> Baseline, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
> 
> Patch, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
> 
> 
> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
> 
> 
> Baseline, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
> 
> Patch, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add line break in make/test/BuildMicrobenchmark.gmk
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8242/files
  - new: https://git.openjdk.java.net/jdk/pull/8242/files/d21330bb..97eec9d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8242&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8242&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8242/head:pull/8242

PR: https://git.openjdk.java.net/jdk/pull/8242

From rriggs at openjdk.java.net  Thu Apr 14 14:59:27 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 14 Apr 2022 14:59:27 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v2]
In-Reply-To: <JQlJrMz3_dZCfykD7tyZ5XgF-xcULsKRm2UJ3utpbTo=.85712f61-30fe-4148-96e9-cf995b95b322@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
 <JQlJrMz3_dZCfykD7tyZ5XgF-xcULsKRm2UJ3utpbTo=.85712f61-30fe-4148-96e9-cf995b95b322@github.com>
Message-ID: <cgfGe0Dx9WzJTL-LFzlQ172L7bLVVr9IibikyNLg-n4=.37678afd-7e88-4ba5-86b5-06eba1c70e7e@github.com>

On Thu, 14 Apr 2022 09:49:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
>> 
>> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modify comment

Please update the copyright date.
Thanks for including the explanation in the test.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8240

From duke at openjdk.java.net  Thu Apr 14 15:34:23 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 14 Apr 2022 15:34:23 GMT
Subject: RFR: 8284866: Add test to JDK-8273056 [v2]
In-Reply-To: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
References: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
Message-ID: <MPhhfeGFbSVmc5ZPp5v5as3B1uNVWmWPcWwvXE0g2Is=.d164de0a-caba-49cb-83ef-0194b62d6f70@github.com>

> Hello,
> this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8284866: Add test to JDK-8273056
  
  Added copyright notice.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8243/files
  - new: https://git.openjdk.java.net/jdk/pull/8243/files/7ef3969d..792b5bab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8243&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8243&range=00-01

  Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8243/head:pull/8243

PR: https://git.openjdk.java.net/jdk/pull/8243

From jlaskey at openjdk.java.net  Thu Apr 14 15:34:23 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 14 Apr 2022 15:34:23 GMT
Subject: RFR: 8284866: Add test to JDK-8273056 [v2]
In-Reply-To: <MPhhfeGFbSVmc5ZPp5v5as3B1uNVWmWPcWwvXE0g2Is=.d164de0a-caba-49cb-83ef-0194b62d6f70@github.com>
References: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
 <MPhhfeGFbSVmc5ZPp5v5as3B1uNVWmWPcWwvXE0g2Is=.d164de0a-caba-49cb-83ef-0194b62d6f70@github.com>
Message-ID: <8Ul5EnfCZzHAojAV0EB_zU8vWLj1jtMmwXnGWkh8GdU=.5cb82d00-8baf-4b35-877b-21ead9575be1@github.com>

On Thu, 14 Apr 2022 15:30:47 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284866: Add test to JDK-8273056
>   
>   Added copyright notice.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8243

From jlaskey at openjdk.java.net  Thu Apr 14 15:34:24 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 14 Apr 2022 15:34:24 GMT
Subject: RFR: 8284866: Add test to JDK-8273056
In-Reply-To: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
References: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
Message-ID: <K2_v-6txCTNm5bJiUY1P_KiUPAOCsr5IHV8FjyrLl-Y=.529d5a2d-6336-4e1b-9d31-5059f4d1d8a2@github.com>

On Thu, 14 Apr 2022 11:31:03 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Hello,
> this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.

Hold off on sponsoring - the copyright needs to be updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/8243

From rriggs at openjdk.java.net  Thu Apr 14 15:39:30 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 14 Apr 2022 15:39:30 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <Hew3ht7BGWgZ15pB6QlPudaPeLXK02N3NkXtCV2sxFI=.2b4e5135-59af-4a18-800b-3d6ae0d74c2f@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <AM9P193MB114234E0B5EF379BC114384FFFEF9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <Hew3ht7BGWgZ15pB6QlPudaPeLXK02N3NkXtCV2sxFI=.2b4e5135-59af-4a18-800b-3d6ae0d74c2f@github.com>
Message-ID: <MjT-ERUr89SPREgf_CO35EAS4M3DmYvm-s5u4X1SmPg=.02c74011-f760-4003-92ef-7e88addf27fb@github.com>

On Thu, 14 Apr 2022 04:09:48 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> Why as it already be a unacceptable option for security reason?

A shared (static) buffer would be visible to application controlled subclasses when the `read(buffer, 0, len)` method is called.
The subclass could examine the buffer and see data read from another stream or thread.
The JDK takes care not to allow this kind of exposure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Thu Apr 14 15:39:30 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 14 Apr 2022 15:39:30 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
Message-ID: <H4J9l_GAn-4w2sQr1TjgIcnBdSg9FsHDmhV8undKNSo=.7ef88fc7-8a66-4da9-8682-4030f9b3e5df@github.com>

On Wed, 13 Apr 2022 21:58:06 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jmh

Can you summarize the performance results and implications.  Including the whole jmh run isn't necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 15:41:31 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 14 Apr 2022 15:41:31 GMT
Subject: Integrated: 8284866: Add test to JDK-8273056
In-Reply-To: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
References: <WRxBz0K2R9MT6PSckpCNsRjWaZjQ_PjtUQl76eq9Qqs=.8f556eef-4d7d-4151-9571-5664c27da4ae@github.com>
Message-ID: <6iZ4Ck9boB0ldTGxf7-jJjyXVQSi6N_eGqyweerckvU=.bc80ea9d-7483-4005-91ca-2596f96a63b7@github.com>

On Thu, 14 Apr 2022 11:31:03 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Hello,
> this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results.

This pull request has now been integrated.

Changeset: 3ffec3a5
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3ffec3a50b70051eba3fc7cd816e49811870f5d4
Stats:     58 lines in 1 file changed: 58 ins; 0 del; 0 mod

8284866: Add test to JDK-8273056

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.java.net/jdk/pull/8243

From chegar at openjdk.java.net  Thu Apr 14 15:55:35 2022
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 14 Apr 2022 15:55:35 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
Message-ID: <4BdteSngv9Euudaha21kOdmSYZicJ6L7jWT-emmUqTk=.4a13e3b2-b75f-4c42-b5bd-f839b5cf898d@github.com>

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

LGTM.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

From ihse at openjdk.java.net  Thu Apr 14 16:12:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 16:12:27 GMT
Subject: RFR: 8284891: Fix typos in build system files
Message-ID: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>

I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.

(Due to false positives this can unfortunately not be run automatically) 

Most of the fixes are in comments. A few are in messages aimed at the user.

-------------

Commit messages:
 - 8284891: Fix typos in build system files

Changes: https://git.openjdk.java.net/jdk/pull/8246/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8246&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284891
  Stats: 72 lines in 46 files changed: 0 ins; 0 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8246.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8246/head:pull/8246

PR: https://git.openjdk.java.net/jdk/pull/8246

From psandoz at openjdk.java.net  Thu Apr 14 16:23:37 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 14 Apr 2022 16:23:37 GMT
Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and
 IteratorSpliterator when size is unknown [v5]
In-Reply-To: <MugeTr9kNjL0Dbx2yDPoKtbZnRjLhocnkLUDBk5mbW4=.6528ec6a-7770-4844-a2d4-c59fa5514ee3@github.com>
References: <ACrivRBSVWKN3Bj8nEdHL0veR6cRyU8ElDfNwB5P55A=.31830fd1-2c64-44c2-bcbc-26e5180faf08@github.com>
 <MugeTr9kNjL0Dbx2yDPoKtbZnRjLhocnkLUDBk5mbW4=.6528ec6a-7770-4844-a2d4-c59fa5514ee3@github.com>
Message-ID: <PeTAzw2vRLoneuZ-j4mYCZO-tyThlsoAjQO1mlAgDP0=.ffd749fe-370d-4db0-b0a6-01d6963fa3d1@github.com>

On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> See the bug description for details.
>> 
>> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable.
>> 
>> No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes.
>> 
>> I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome.
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Cosmetic fixes

Getting back to this after much delay! Approving. But, i would like to try and document this design decision in comments, and maybe in implementation notes. We can do that as a follow on PR.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7279

From erikj at openjdk.java.net  Thu Apr 14 16:29:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 16:29:40 GMT
Subject: RFR: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <eOghGOYfVNtq52tpdDhCbiKEXTUC49ROtX8_2BfvTV8=.e21f3899-eab3-4c74-8328-e2e5ca85102f@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8246

From duke at openjdk.java.net  Thu Apr 14 16:50:35 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 16:50:35 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <H4J9l_GAn-4w2sQr1TjgIcnBdSg9FsHDmhV8undKNSo=.7ef88fc7-8a66-4da9-8682-4030f9b3e5df@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
 <H4J9l_GAn-4w2sQr1TjgIcnBdSg9FsHDmhV8undKNSo=.7ef88fc7-8a66-4da9-8682-4030f9b3e5df@github.com>
Message-ID: <2txOQ87fZ6Siban1KmF7eY9lbNVr7CFXpTDgWkZX96A=.b40ba102-86a0-480c-87c4-48693111b496@github.com>

On Thu, 14 Apr 2022 15:36:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Can you summarize the performance results and implications. Including the whole jmh run isn't necessary.

@RogerRiggs

In short, making such a cache can help performance, and the larger int skip length people call `skip()`, the larger difference.

And adding SoftReference mechanism have a little acceptable performance cost.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 16:50:35 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 16:50:35 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object
In-Reply-To: <MjT-ERUr89SPREgf_CO35EAS4M3DmYvm-s5u4X1SmPg=.02c74011-f760-4003-92ef-7e88addf27fb@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <AM9P193MB114234E0B5EF379BC114384FFFEF9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <Hew3ht7BGWgZ15pB6QlPudaPeLXK02N3NkXtCV2sxFI=.2b4e5135-59af-4a18-800b-3d6ae0d74c2f@github.com>
 <MjT-ERUr89SPREgf_CO35EAS4M3DmYvm-s5u4X1SmPg=.02c74011-f760-4003-92ef-7e88addf27fb@github.com>
Message-ID: <wsO3X-vH51piAUHwoD9lkOz0fzVnf4aYwiLlSOKftsU=.dcb3ef69-8a11-4e19-becd-fdca8c2cf40d@github.com>

On Thu, 14 Apr 2022 15:33:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Why as it already be a unacceptable option for security reason?
> 
> A shared (static) buffer would be visible to application controlled subclasses when the `read(buffer, 0, len)` method is called. The subclass could examine the buffer and see data read from another stream or thread. The JDK takes care not to allow this kind of exposure.

Yes and this is why I don't want to waste time on a static buffer test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 16:58:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 16:58:40 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v19]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <P631sogg9J48Hw0iIQpn49QSTlKzE72T2FcLRVP0AmM=.d66c9f4f-8a11-401f-b6ea-6de553cb86a3@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  fix usage in XSAttributeChecker

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/d110ecfd..5603f193

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 16:58:42 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 16:58:42 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <TeeKCwr29XOequYIh4iw9_YGqyOWx1r0YwqTP64VgZ8=.f1094640-6f9c-4c2c-9120-f0c6c0031f79@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <LB4oSepLE4LT6GAsXsA-_xNXy2jposq81LCvYPfuqAU=.6995b657-48e3-4da1-b2b9-ad3edf91d3eb@github.com>
 <UIxbDGH3RZVwDMUQ9SRhvenKjBbdb1XpyUfb0hmGMUM=.a82a0603-32a6-40a2-b9e9-2ce23b3e1a70@github.com>
 <TeeKCwr29XOequYIh4iw9_YGqyOWx1r0YwqTP64VgZ8=.f1094640-6f9c-4c2c-9120-f0c6c0031f79@github.com>
Message-ID: <TiKzQTj-W4CZ5N9lNjgq-J53-4ZNoMuobFXWxvs2X78=.e926a732-4332-4f90-bfe2-e1fd27ed545c@github.com>

On Thu, 14 Apr 2022 03:38:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

>>> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings.
>> 
>> I looked the codes and don't think so..
>> If I'm wrong, I'm glad to fix.
>
> Stuart's right, I looked at the code, it's as you said a failed attempt, "size" would be good. So HashMap.newHashMap(size) would actually be a small improvement.
> 
> It's an interesting impl the way it used HashMap, but it's 20 year code.

@JoeWang-Java @stuart-marks got it. done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 17:05:42 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:05:42 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <xKjqLHNKD27oflyQv-JEVlumtfbMxbXoAETc84R4PcU=.1f7cb340-1bc8-476d-852b-05bfbd0b3444@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <xKjqLHNKD27oflyQv-JEVlumtfbMxbXoAETc84R4PcU=.1f7cb340-1bc8-476d-852b-05bfbd0b3444@github.com>
Message-ID: <74mi18QF7mCaY5H_LJgOl47cqfoEB3WEmOVtfsv6v2A=.901a9ead-673e-4948-89a8-3f1dbfacbf8a@github.com>

On Wed, 13 Apr 2022 23:25:47 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update LastModified
>
> src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 102:
> 
>> 100:     /* Only for use by Runtime.exec(...String[]envp...) */
>> 101:     static Map<String,String> emptyEnvironment(int capacity) {
>> 102:         return new StringEnvironment(HashMap.newHashMap(capacity));
> 
> This change is correct, since this is called with the length of an array that's used to populate the environment. It really should be named `size` instead of `capacity`. However the windows version of this code simply calls `super(capacity)` as it's a subclass of `HashMap`, which is wrong. Well, probably not worth changing this now. We may need to revisit this later to do some cleaning up. (And also the strange computation in the static initializer at line 71.)

@stuart-marks OK, changes on this class reverted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 17:05:39 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:05:39 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <tZp1Atbba9bPIrj2dkj0JHzXRr9eBIS6ooY0xgQEaCI=.d89f7b10-637c-4147-af70-fad81da2e08d@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  revert changes on ProcessEnvironment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/5603f193..5b437dab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=18-19

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 17:10:36 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:10:36 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <uNsLbPcKwzq-jlie7JtG8BbwMtMYJ-hTH1h4SD9aybo=.8acf4bf4-4cb7-4b8d-9261-4e29e6ba3ed2@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>
 <uNsLbPcKwzq-jlie7JtG8BbwMtMYJ-hTH1h4SD9aybo=.8acf4bf4-4cb7-4b8d-9261-4e29e6ba3ed2@github.com>
Message-ID: <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com>

On Wed, 13 Apr 2022 22:53:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856

@stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 17:13:32 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:13:32 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <0OY6BtovHw8z0yusyf484Pz3_ccQlHuFMBOZlHuy4JI=.3c4b2e6e-81b6-40a8-8bd3-d8da73c344b9@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <CaueBjVcwIHP3N8jZls5hr7XsHQntW9hOdbf2raFbdU=.7166b232-370c-49b3-8d60-79556fa30e2c@github.com>
 <2xES9jigvF0ivIVUD1HXcAlossmqheUNqdSmq182gtY=.7ad297e2-2b43-439b-9e7c-7f498fb49468@github.com>
 <V_MarhNci1Egr98YnzDcY0UDiuz5enHmMPopygD7iQo=.25f53e36-5bee-4b1c-9274-04ad29ba1ad8@github.com>
 <5tRQ_2sELwPc2JTp4WuzjRiVruJrNEzXywlTrD1LyYM=.8099a189-04ec-4c71-a09c-1c3efcf6fdbe@github.com>
 <34q8_XQ_BBKfo2zCyjeyp2LCYFO9HN5fxs3uPBdKxMU=.d7b6b2e0-9a6e-490d-906b-9d1f8142eec4@github.com>
 <4-6eOb0t6ADsm-cMG0mhFsO4TnFGRogaNetyxFHRxfo=.50b8bdc3-1392-4c04-a090-17b84de1109c@github.com>
 <6Tln1ANYAHCYKrzJHhXb1BZPQ7vHRHLzbICt3BE70zc=.55bbbce7-3c22-4219-b24a-e5a94bc9cb0b@github.com>
 <G7Nr8fxfAfLlscCDgo4yv4J8CFu9BjxlAJ41bL4C2p4=.ce332653-5b02-4399-9b5f-dd16f4f0b7b8@github.com>
 <z-WRw8K4f1dxxtyUCOWsNwytXLtaDk8PWsCC7Oyg488=.7f17a235-f396-4703-b7b2-3b0b67ae3508@github.com>
 <OSvxeFmVfX1uW9NmyOWNl8LhKtZEaKex7J0
 2v8ypc68=.06560466-66e9-4ca2-b784-cfcd52f1d3d0@github.com>
 <0OY6BtovHw8z0yusyf484Pz3_ccQlHuFMBOZlHuy4JI=.3c4b2e6e-81b6-40a8-8bd3-d8da73c344b9@github.com>
Message-ID: <R0mnnjSZ-GOmhZ3JaGy7sxnAr6tOk__16PyOitP20tI=.1c625882-d8a5-45ca-a586-ad3a356fb4a5@github.com>

On Tue, 12 Apr 2022 23:35:06 GMT, liach <duke at openjdk.java.net> wrote:

> Shouldn't be too problematic, as most skip usages in JDK as I see are skipping small number of bytes like 2 or 4, or like skipping over attributes of Java class files. A minimum skip buffer size isn't that helpful, as I don't think we often see skip calls with slowly incremental sizes.

Yep usually people skip for fixed length... It is rare to see people skip larger and larger...

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 17:21:30 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:21:30 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v2]
In-Reply-To: <uRuoimTA6vMHIoJIpQRT-bikknb3fqHrzkCZYaDBbDU=.a78e97ea-6fcd-4775-aa27-c15ff9dbd4a9@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <WEcBnV1wubfeyhS8lTf-rG4sAs9ltNArOTn7RS5aZR4=.cc4bc893-af17-4577-85cf-c33896264558@github.com>
 <8IUH8A8fQ260w01BAyj-xuqJ1o86NvY2adq6UrSYBek=.a1ffaff1-5412-45cb-9f87-8103f07dd807@github.com>
 <T_5fwWoKV92ygXqbpu-qhwlh6cAmZk-QUvZsyyabAB4=.9d1cf67a-7487-489c-9d2c-cf1a73a3dcda@github.com>
 <P3EmxpkdszNaxYRDZOfTmsyidB_BC18lGEmjPU-_Ai4=.5902e387-4a79-4b5d-b1d3-af20ccdb186c@github.com>
 <oMOMN3qsMhMiLdtbrbu70hwFfCAtOxapurUDvTA7G9o=.a2120008-d90b-40a6-806f-de6c7a4c9c28@github.com>
 <uRuoimTA6vMHIoJIpQRT-bikknb3fqHrzkCZYaDBbDU=.a78e97ea-6fcd-4775-aa27-c15ff9dbd4a9@github.com>
Message-ID: <Jtn44IgtuHhImVJNYMZDzOQG_QfYmOyIUKYVfbrdAMc=.16743b0e-2815-48bf-8ede-31608bd628ac@github.com>

On Wed, 13 Apr 2022 15:09:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> I recommend moving `nr` declaration from the beginning of the method to where it's actually used (here)
>> 
>> @liach done.
>
> Sorry, I misunderstood your earlier comment: "Sounds reasonable and applied"
> as concurring with not re-allocating to avoid the overhead of gc and wasting the smaller buffer.
> The code can be harder to understand because `size` and `skipBuffer.length` may be different.

@RogerRiggs
Rethink of this, I kind of prefer the soft reference plan @liach shown....

> The code can be harder to understand because `size` and `skipBuffer.length` may be different.

yes...

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 17:21:30 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:21:30 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <Uj8JrQyYkThjoKzfdhwCw7pjXvFtme8GRjk5zYlHMZI=.75e1ba4c-bc6f-49f2-a040-e11bf7dff7ef@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
 <Uj8JrQyYkThjoKzfdhwCw7pjXvFtme8GRjk5zYlHMZI=.75e1ba4c-bc6f-49f2-a040-e11bf7dff7ef@github.com>
Message-ID: <16bOmLtC0VXirnoUpnR4Ri6JcquQn9xyA7QvjMAXZc4=.2d01b542-2dfe-4afa-aa36-d5d6931b47e3@github.com>

On Wed, 13 Apr 2022 22:53:11 GMT, liach <duke at openjdk.java.net> wrote:

> I suggest we actually write into the byte array to better simulate overheads (maybe by generating a number with `ThreadLocalRandom`).

This sounds reasonable, as each InputStream implementation always need to copy it.

> To simulate overhead on each read call, you can perform some extra activity consumed by the blackhole (possibly pass jmh blackhole through input stream constructor)

This one not, as each InputStream implementation have different read cost, and there is no way to simulate a good value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From joehw at openjdk.java.net  Thu Apr 14 17:26:48 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 14 Apr 2022 17:26:48 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20]
In-Reply-To: <tZp1Atbba9bPIrj2dkj0JHzXRr9eBIS6ooY0xgQEaCI=.d89f7b10-637c-4147-af70-fad81da2e08d@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <tZp1Atbba9bPIrj2dkj0JHzXRr9eBIS6ooY0xgQEaCI=.d89f7b10-637c-4147-af70-fad81da2e08d@github.com>
Message-ID: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com>

On Thu, 14 Apr 2022 17:05:39 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes on ProcessEnvironment

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3:

> 1: /*
> 2:  * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved.
> 3:  */

The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 17:41:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 17:41:38 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v5]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <yhy3gRN4c35aXnslLyUvdFXQEJlOofQJRp4O2pmYEj4=.99e02759-ad4c-4e1c-b5f1-fa9accd18a59@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  refine jmh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/7a9844cb..738991c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=03-04

  Stats: 76 lines in 1 file changed: 35 ins; 37 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 18:01:35 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 18:01:35 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v4]
In-Reply-To: <Uj8JrQyYkThjoKzfdhwCw7pjXvFtme8GRjk5zYlHMZI=.75e1ba4c-bc6f-49f2-a040-e11bf7dff7ef@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <zy7V8yqHXueIvrI4x-zK4BW0ZUOKJJfLXxoly89nyLk=.02cd681b-1cde-46bc-a0f1-12f884b67294@github.com>
 <Uj8JrQyYkThjoKzfdhwCw7pjXvFtme8GRjk5zYlHMZI=.75e1ba4c-bc6f-49f2-a040-e11bf7dff7ef@github.com>
Message-ID: <jU8o7e6_rzzbSZ4OPcXF75hsHIVTYUgqA4ul0isBkkA=.797b708d-7535-4b28-b8a5-160538af27f7@github.com>

On Wed, 13 Apr 2022 22:59:13 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add jmh
>
> test/micro/org/openjdk/bench/java/io/InputStreamSkipBenchmark.java line 54:
> 
>> 52:     @Benchmark
>> 53:     public long testSkip0(Data data) throws IOException {
>> 54:         TestBaseInputStream0 testBaseInputStream = new TestBaseInputStream0(data.inputStreamSize);
> 
> Instead of creating 3 methods with identical bodies, I recommend using an enum to represent the type of buffers. An example at https://github.com/openjdk/jdk/blob/7a9844cb1cd18c18ce097741cba7db1148c83de0/test/micro/org/openjdk/bench/java/util/HashMapBench.java#L65-L71
> 
> For enum values, you can name them like `LOCAL_VARIABLE`, `FIELD`, `SOFT_REFERENCE`, which is more descriptive than current "0, 1, 2," etc.

@liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From aturbanov at openjdk.java.net  Thu Apr 14 18:09:37 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 18:09:37 GMT
Subject: Integrated: 8284853: Fix various 'expected' typo
In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
Message-ID: <EazeFRrVhzLud87RZyQuAAcvVVGBXgS_8bvUToeijvA=.6d3c58fc-5c53-4e82-8166-8ce446c200c6@github.com>

On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc.

This pull request has now been integrated.

Changeset: 48c75498
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48c75498060f076287d3d44c49934db9ac70887b
Stats:     65 lines in 28 files changed: 0 ins; 0 del; 65 mod

8284853: Fix various 'expected' typo

Reviewed-by: bpb, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231

From aturbanov at openjdk.java.net  Thu Apr 14 18:09:34 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 14 Apr 2022 18:09:34 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
 <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
Message-ID: <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>

On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang <yyang at openjdk.org> wrote:

>I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks.

I think it deserves a separate ticket. BTW there are a lot of other typos in JDK, especially in comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231

From duke at openjdk.java.net  Thu Apr 14 18:10:28 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 18:10:28 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add `@LastModified: Apr 2022` to DocumentCache

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/5b437dab..71b7dba3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=19-20

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 18:10:29 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 18:10:29 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20]
In-Reply-To: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <tZp1Atbba9bPIrj2dkj0JHzXRr9eBIS6ooY0xgQEaCI=.d89f7b10-637c-4147-af70-fad81da2e08d@github.com>
 <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com>
Message-ID: <tSlLBxAsXHwrFHMk90N9XOgDE1CKTMywSUnzq-Ob60o=.08c584cc-cc32-4a57-995e-8b6eeeac5463@github.com>

On Thu, 14 Apr 2022 17:23:42 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes on ProcessEnvironment
>
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved.
>> 3:  */
> 
> The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks.

@JoeWang-Java done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From joehw at openjdk.java.net  Thu Apr 14 18:25:32 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 14 Apr 2022 18:25:32 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
Message-ID: <QJcLACbJeGjhzbnkc__febfL9ySxRjUphCeI7-qCPUw=.317b4810-f00c-4552-86dc-d5d78b1e66f9@github.com>

On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add `@LastModified: Apr 2022` to DocumentCache

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From joehw at openjdk.java.net  Thu Apr 14 18:25:32 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 14 Apr 2022 18:25:32 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20]
In-Reply-To: <tSlLBxAsXHwrFHMk90N9XOgDE1CKTMywSUnzq-Ob60o=.08c584cc-cc32-4a57-995e-8b6eeeac5463@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <tZp1Atbba9bPIrj2dkj0JHzXRr9eBIS6ooY0xgQEaCI=.d89f7b10-637c-4147-af70-fad81da2e08d@github.com>
 <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com>
 <tSlLBxAsXHwrFHMk90N9XOgDE1CKTMywSUnzq-Ob60o=.08c584cc-cc32-4a57-995e-8b6eeeac5463@github.com>
Message-ID: <1RTVIryM7sFw60Su-rO3CRvJh7c3O-F9cpIqVAg5etw=.31126d2c-6643-4e4a-865a-0579cd35616b@github.com>

On Thu, 14 Apr 2022 18:05:48 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved.
>>> 3:  */
>> 
>> The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks.
>
> @JoeWang-Java done.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From stuefe at openjdk.java.net  Thu Apr 14 18:29:21 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 14 Apr 2022 18:29:21 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v3]
In-Reply-To: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
Message-ID: <SF-JRSPe_Hk8O_VqWH7aPbmp9YIIQd6kcj7sYdrFbzk=.2f8d57d4-d2aa-4478-86fc-c0cd98e86d62@github.com>

> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
> 
> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8240/files
  - new: https://git.openjdk.java.net/jdk/pull/8240/files/aac07eaf..e8f672c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8240&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8240&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8240/head:pull/8240

PR: https://git.openjdk.java.net/jdk/pull/8240

From stuefe at openjdk.java.net  Thu Apr 14 18:29:22 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 14 Apr 2022 18:29:22 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v2]
In-Reply-To: <cgfGe0Dx9WzJTL-LFzlQ172L7bLVVr9IibikyNLg-n4=.37678afd-7e88-4ba5-86b5-06eba1c70e7e@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
 <JQlJrMz3_dZCfykD7tyZ5XgF-xcULsKRm2UJ3utpbTo=.85712f61-30fe-4148-96e9-cf995b95b322@github.com>
 <cgfGe0Dx9WzJTL-LFzlQ172L7bLVVr9IibikyNLg-n4=.37678afd-7e88-4ba5-86b5-06eba1c70e7e@github.com>
Message-ID: <N-tRhGzenY8Oy_OQArJv4BnqC_LPoS9D_GdDy7mkXTA=.13822464-1ecf-458f-871c-b2712019030c@github.com>

On Thu, 14 Apr 2022 14:56:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Please update the copyright date. Thanks for including the explanation in the test.

Thank you @RogerRiggs! Would I need a second Reviewer?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8240

From naoto at openjdk.java.net  Thu Apr 14 18:35:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 18:35:34 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>
 <uNsLbPcKwzq-jlie7JtG8BbwMtMYJ-hTH1h4SD9aybo=.8acf4bf4-4cb7-4b8d-9261-4e29e6ba3ed2@github.com>
 <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com>
Message-ID: <xr_Oxv8hC520hKGE0ZZGlje1WFwE2ganf__RB_l_x_Y=.db498695-3f47-49a0-8fe4-001fe9fb7b67@github.com>

On Thu, 14 Apr 2022 17:06:53 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>
>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
> 
> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this.

Thanks. Will fix it myself, as I want to eliminate that immediate value in the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 18:52:25 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 18:52:25 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v6]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <ee9hku95IwMoM8qWNtOOFbN-Ml6Z-FJVDi7idbo68mI=.3f48c952-638c-41ac-9045-51f891579e00@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  refine jmh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/738991c0..1f6e0eb7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Thu Apr 14 18:52:26 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 18:52:26 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v5]
In-Reply-To: <yhy3gRN4c35aXnslLyUvdFXQEJlOofQJRp4O2pmYEj4=.99e02759-ad4c-4e1c-b5f1-fa9accd18a59@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <yhy3gRN4c35aXnslLyUvdFXQEJlOofQJRp4O2pmYEj4=.99e02759-ad4c-4e1c-b5f1-fa9accd18a59@github.com>
Message-ID: <JG58_aJbHp7krA93gwF_RULyESbGxXd_929lylmmVQc=.9980280c-7b07-4370-acc9-baee267010f4@github.com>

On Thu, 14 Apr 2022 17:41:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine jmh

<details>
<summary>Jmh Result</summary>
<p>

# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 1)

# Run progress: 0.00% complete, ETA 00:14:00
# Fork: 1 of 3
# Warmup Iteration   1: 7942173.846 ns/op
# Warmup Iteration   2: 4922276.699 ns/op
# Warmup Iteration   3: 4902600.000 ns/op
# Warmup Iteration   4: 4922498.058 ns/op
# Warmup Iteration   5: 4774963.551 ns/op
# Warmup Iteration   6: 4770013.889 ns/op
# Warmup Iteration   7: 4949664.423 ns/op
# Warmup Iteration   8: 4795128.037 ns/op
# Warmup Iteration   9: 4945577.670 ns/op
# Warmup Iteration  10: 4765298.148 ns/op
Iteration   1: 4844866.038 ns/op
Iteration   2: 4854815.094 ns/op
Iteration   3: 5023470.588 ns/op
Iteration   4: 4921953.846 ns/op
Iteration   5: 5050374.257 ns/op
Iteration   6: 4748347.222 ns/op
Iteration   7: 5062756.436 ns/op
Iteration   8: 4888359.048 ns/op
Iteration   9: 4760139.815 ns/op
Iteration  10: 4754050.000 ns/op

# Run progress: 1.19% complete, ETA 00:15:00
# Fork: 2 of 3
# Warmup Iteration   1: 6271537.037 ns/op
# Warmup Iteration   2: 4901734.951 ns/op
# Warmup Iteration   3: 4771166.355 ns/op
# Warmup Iteration   4: 4916378.095 ns/op
# Warmup Iteration   5: 4788584.112 ns/op
# Warmup Iteration   6: 4877893.396 ns/op
# Warmup Iteration   7: 4775457.944 ns/op
# Warmup Iteration   8: 4910870.476 ns/op
# Warmup Iteration   9: 4822129.907 ns/op
# Warmup Iteration  10: 4896441.346 ns/op
Iteration   1: 4729921.101 ns/op
Iteration   2: 4807608.411 ns/op
Iteration   3: 4738549.541 ns/op
Iteration   4: 4746007.407 ns/op
Iteration   5: 4970233.010 ns/op
Iteration   6: 4881390.476 ns/op
Iteration   7: 4889175.238 ns/op
Iteration   8: 4927417.308 ns/op
Iteration   9: 4730544.954 ns/op
Iteration  10: 4873010.577 ns/op

# Run progress: 2.38% complete, ETA 00:14:37
# Fork: 3 of 3
# Warmup Iteration   1: 6957454.054 ns/op
# Warmup Iteration   2: 4864516.346 ns/op
# Warmup Iteration   3: 4893289.524 ns/op
# Warmup Iteration   4: 4767729.630 ns/op
# Warmup Iteration   5: 4968900.000 ns/op
# Warmup Iteration   6: 4812798.131 ns/op
# Warmup Iteration   7: 4883357.143 ns/op
# Warmup Iteration   8: 4726568.807 ns/op
# Warmup Iteration   9: 4816854.206 ns/op
# Warmup Iteration  10: 4774020.755 ns/op
Iteration   1: 4839433.019 ns/op
Iteration   2: 4795008.491 ns/op
Iteration   3: 4895861.905 ns/op
Iteration   4: 4757087.037 ns/op
Iteration   5: 4802707.477 ns/op
Iteration   6: 4854249.524 ns/op
Iteration   7: 4792616.822 ns/op
Iteration   8: 4768653.704 ns/op
Iteration   9: 4722782.407 ns/op
Iteration  10: 5051006.863 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  4849413.254 ?(99.9%) 69038.211 ns/op [Average]
  (min, avg, max) = (4722782.407, 4849413.254, 5062756.436), stdev = 103333.152
  CI (99.9%): [4780375.043, 4918451.465] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 8)

# Run progress: 3.57% complete, ETA 00:14:23
# Fork: 1 of 3
# Warmup Iteration   1: 981066.922 ns/op
# Warmup Iteration   2: 747661.267 ns/op
# Warmup Iteration   3: 721590.832 ns/op
# Warmup Iteration   4: 725520.550 ns/op
# Warmup Iteration   5: 723312.676 ns/op
# Warmup Iteration   6: 739232.133 ns/op
# Warmup Iteration   7: 717477.731 ns/op
# Warmup Iteration   8: 761306.696 ns/op
# Warmup Iteration   9: 743272.052 ns/op
# Warmup Iteration  10: 756751.032 ns/op
Iteration   1: 727964.356 ns/op
Iteration   2: 725621.246 ns/op
Iteration   3: 729149.504 ns/op
Iteration   4: 770425.904 ns/op
Iteration   5: 779490.152 ns/op
Iteration   6: 725880.966 ns/op
Iteration   7: 722240.311 ns/op
Iteration   8: 731829.143 ns/op
Iteration   9: 716433.054 ns/op
Iteration  10: 720150.070 ns/op

# Run progress: 4.76% complete, ETA 00:14:10
# Fork: 2 of 3
# Warmup Iteration   1: 1115962.361 ns/op
# Warmup Iteration   2: 800383.516 ns/op
# Warmup Iteration   3: 786476.876 ns/op
# Warmup Iteration   4: 786971.472 ns/op
# Warmup Iteration   5: 797605.296 ns/op
# Warmup Iteration   6: 789334.823 ns/op
# Warmup Iteration   7: 795008.037 ns/op
# Warmup Iteration   8: 772586.165 ns/op
# Warmup Iteration   9: 783481.707 ns/op
# Warmup Iteration  10: 779335.410 ns/op
Iteration   1: 785926.260 ns/op
Iteration   2: 795268.075 ns/op
Iteration   3: 795524.651 ns/op
Iteration   4: 771994.286 ns/op
Iteration   5: 787574.613 ns/op
Iteration   6: 815270.240 ns/op
Iteration   7: 797273.953 ns/op
Iteration   8: 797636.025 ns/op
Iteration   9: 792095.342 ns/op
Iteration  10: 799684.953 ns/op

# Run progress: 5.95% complete, ETA 00:13:58
# Fork: 3 of 3
# Warmup Iteration   1: 1247392.402 ns/op
# Warmup Iteration   2: 751027.422 ns/op
# Warmup Iteration   3: 725690.409 ns/op
# Warmup Iteration   4: 734950.286 ns/op
# Warmup Iteration   5: 722868.503 ns/op
# Warmup Iteration   6: 718645.098 ns/op
# Warmup Iteration   7: 720812.500 ns/op
# Warmup Iteration   8: 727900.566 ns/op
# Warmup Iteration   9: 714242.399 ns/op
# Warmup Iteration  10: 720480.337 ns/op
Iteration   1: 731617.286 ns/op
Iteration   2: 715114.067 ns/op
Iteration   3: 731984.979 ns/op
Iteration   4: 723065.449 ns/op
Iteration   5: 729012.465 ns/op
Iteration   6: 722958.014 ns/op
Iteration   7: 740044.317 ns/op
Iteration   8: 798105.124 ns/op
Iteration   9: 769114.887 ns/op
Iteration  10: 730445.377 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  755963.169 ?(99.9%) 22429.963 ns/op [Average]
  (min, avg, max) = (715114.067, 755963.169, 815270.240), stdev = 33572.115
  CI (99.9%): [733533.206, 778393.132] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 32)

# Run progress: 7.14% complete, ETA 00:13:47
# Fork: 1 of 3
# Warmup Iteration   1: 365339.172 ns/op
# Warmup Iteration   2: 255568.898 ns/op
# Warmup Iteration   3: 266635.371 ns/op
# Warmup Iteration   4: 252336.824 ns/op
# Warmup Iteration   5: 248787.821 ns/op
# Warmup Iteration   6: 254361.169 ns/op
# Warmup Iteration   7: 248130.958 ns/op
# Warmup Iteration   8: 252737.032 ns/op
# Warmup Iteration   9: 248345.300 ns/op
# Warmup Iteration  10: 248215.905 ns/op
Iteration   1: 248318.692 ns/op
Iteration   2: 246642.809 ns/op
Iteration   3: 245900.431 ns/op
Iteration   4: 254614.427 ns/op
Iteration   5: 246205.967 ns/op
Iteration   6: 254173.281 ns/op
Iteration   7: 247281.419 ns/op
Iteration   8: 247882.265 ns/op
Iteration   9: 245820.783 ns/op
Iteration  10: 246980.943 ns/op

# Run progress: 8.33% complete, ETA 00:13:36
# Fork: 2 of 3
# Warmup Iteration   1: 401677.681 ns/op
# Warmup Iteration   2: 249510.025 ns/op
# Warmup Iteration   3: 250569.204 ns/op
# Warmup Iteration   4: 252656.869 ns/op
# Warmup Iteration   5: 254595.978 ns/op
# Warmup Iteration   6: 245286.320 ns/op
# Warmup Iteration   7: 250192.345 ns/op
# Warmup Iteration   8: 245022.312 ns/op
# Warmup Iteration   9: 252732.167 ns/op
# Warmup Iteration  10: 246054.480 ns/op
Iteration   1: 254355.550 ns/op
Iteration   2: 246817.425 ns/op
Iteration   3: 250327.859 ns/op
Iteration   4: 249676.931 ns/op
Iteration   5: 245556.549 ns/op
Iteration   6: 246081.193 ns/op
Iteration   7: 247709.347 ns/op
Iteration   8: 245333.413 ns/op
Iteration   9: 259142.864 ns/op
Iteration  10: 244605.391 ns/op

# Run progress: 9.52% complete, ETA 00:13:25
# Fork: 3 of 3
# Warmup Iteration   1: 382746.889 ns/op
# Warmup Iteration   2: 251222.887 ns/op
# Warmup Iteration   3: 249605.894 ns/op
# Warmup Iteration   4: 251588.037 ns/op
# Warmup Iteration   5: 247652.842 ns/op
# Warmup Iteration   6: 246400.336 ns/op
# Warmup Iteration   7: 246700.436 ns/op
# Warmup Iteration   8: 250645.974 ns/op
# Warmup Iteration   9: 245546.875 ns/op
# Warmup Iteration  10: 264809.599 ns/op
Iteration   1: 247062.120 ns/op
Iteration   2: 268563.733 ns/op
Iteration   3: 246480.355 ns/op
Iteration   4: 250256.471 ns/op
Iteration   5: 245111.365 ns/op
Iteration   6: 250733.087 ns/op
Iteration   7: 250447.297 ns/op
Iteration   8: 258326.577 ns/op
Iteration   9: 248101.694 ns/op
Iteration  10: 261175.980 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  249989.541 ?(99.9%) 3752.365 ns/op [Average]
  (min, avg, max) = (244605.391, 249989.541, 268563.733), stdev = 5616.363
  CI (99.9%): [246237.176, 253741.905] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 128)

# Run progress: 10.71% complete, ETA 00:13:13
# Fork: 1 of 3
# Warmup Iteration   1: 165288.685 ns/op
# Warmup Iteration   2: 102710.221 ns/op
# Warmup Iteration   3: 111176.421 ns/op
# Warmup Iteration   4: 107099.708 ns/op
# Warmup Iteration   5: 123149.637 ns/op
# Warmup Iteration   6: 162177.915 ns/op
# Warmup Iteration   7: 126545.042 ns/op
# Warmup Iteration   8: 158954.815 ns/op
# Warmup Iteration   9: 102227.652 ns/op
# Warmup Iteration  10: 104569.165 ns/op
Iteration   1: 104293.606 ns/op
Iteration   2: 99736.023 ns/op
Iteration   3: 103647.284 ns/op
Iteration   4: 100737.439 ns/op
Iteration   5: 107515.557 ns/op
Iteration   6: 99290.041 ns/op
Iteration   7: 101567.869 ns/op
Iteration   8: 98818.049 ns/op
Iteration   9: 100406.641 ns/op
Iteration  10: 99359.036 ns/op

# Run progress: 11.90% complete, ETA 00:13:03
# Fork: 2 of 3
# Warmup Iteration   1: 152641.009 ns/op
# Warmup Iteration   2: 107852.365 ns/op
# Warmup Iteration   3: 101772.145 ns/op
# Warmup Iteration   4: 103918.674 ns/op
# Warmup Iteration   5: 101783.287 ns/op
# Warmup Iteration   6: 104464.008 ns/op
# Warmup Iteration   7: 98886.800 ns/op
# Warmup Iteration   8: 108000.253 ns/op
# Warmup Iteration   9: 101115.762 ns/op
# Warmup Iteration  10: 103578.072 ns/op
Iteration   1: 101643.021 ns/op
Iteration   2: 103417.312 ns/op
Iteration   3: 101943.267 ns/op
Iteration   4: 100598.491 ns/op
Iteration   5: 100915.522 ns/op
Iteration   6: 103676.227 ns/op
Iteration   7: 101246.398 ns/op
Iteration   8: 100235.407 ns/op
Iteration   9: 102958.765 ns/op
Iteration  10: 102774.649 ns/op

# Run progress: 13.10% complete, ETA 00:12:52
# Fork: 3 of 3
# Warmup Iteration   1: 154157.464 ns/op
# Warmup Iteration   2: 101104.025 ns/op
# Warmup Iteration   3: 104743.021 ns/op
# Warmup Iteration   4: 98901.406 ns/op
# Warmup Iteration   5: 100323.314 ns/op
# Warmup Iteration   6: 100725.020 ns/op
# Warmup Iteration   7: 102849.479 ns/op
# Warmup Iteration   8: 98587.486 ns/op
# Warmup Iteration   9: 104073.405 ns/op
# Warmup Iteration  10: 99799.221 ns/op
Iteration   1: 104367.087 ns/op
Iteration   2: 98411.552 ns/op
Iteration   3: 103047.491 ns/op
Iteration   4: 101594.836 ns/op
Iteration   5: 103596.004 ns/op
Iteration   6: 100870.538 ns/op
Iteration   7: 102451.816 ns/op
Iteration   8: 100978.348 ns/op
Iteration   9: 101741.966 ns/op
Iteration  10: 99138.271 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  101699.284 ?(99.9%) 1335.823 ns/op [Average]
  (min, avg, max) = (98411.552, 101699.284, 107515.557), stdev = 1999.397
  CI (99.9%): [100363.461, 103035.107] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 512)

# Run progress: 14.29% complete, ETA 00:12:41
# Fork: 1 of 3
# Warmup Iteration   1: 149302.642 ns/op
# Warmup Iteration   2: 112726.441 ns/op
# Warmup Iteration   3: 103518.939 ns/op
# Warmup Iteration   4: 111268.381 ns/op
# Warmup Iteration   5: 103675.771 ns/op
# Warmup Iteration   6: 108417.437 ns/op
# Warmup Iteration   7: 108587.862 ns/op
# Warmup Iteration   8: 105314.092 ns/op
# Warmup Iteration   9: 107894.342 ns/op
# Warmup Iteration  10: 106785.240 ns/op
Iteration   1: 104839.267 ns/op
Iteration   2: 109840.908 ns/op
Iteration   3: 104027.628 ns/op
Iteration   4: 108387.693 ns/op
Iteration   5: 106561.294 ns/op
Iteration   6: 106347.317 ns/op
Iteration   7: 108601.716 ns/op
Iteration   8: 107226.170 ns/op
Iteration   9: 103378.124 ns/op
Iteration  10: 108701.055 ns/op

# Run progress: 15.48% complete, ETA 00:12:30
# Fork: 2 of 3
# Warmup Iteration   1: 145419.571 ns/op
# Warmup Iteration   2: 107572.513 ns/op
# Warmup Iteration   3: 107850.189 ns/op
# Warmup Iteration   4: 102801.243 ns/op
# Warmup Iteration   5: 109842.738 ns/op
# Warmup Iteration   6: 104075.826 ns/op
# Warmup Iteration   7: 109465.819 ns/op
# Warmup Iteration   8: 104959.508 ns/op
# Warmup Iteration   9: 105647.494 ns/op
# Warmup Iteration  10: 109539.395 ns/op
Iteration   1: 105867.599 ns/op
Iteration   2: 106379.395 ns/op
Iteration   3: 107375.650 ns/op
Iteration   4: 106530.643 ns/op
Iteration   5: 106783.818 ns/op
Iteration   6: 107126.086 ns/op
Iteration   7: 105889.093 ns/op
Iteration   8: 107774.280 ns/op
Iteration   9: 105290.622 ns/op
Iteration  10: 106250.937 ns/op

# Run progress: 16.67% complete, ETA 00:12:20
# Fork: 3 of 3
# Warmup Iteration   1: 151497.965 ns/op
# Warmup Iteration   2: 107686.238 ns/op
# Warmup Iteration   3: 112992.602 ns/op
# Warmup Iteration   4: 105094.285 ns/op
# Warmup Iteration   5: 106743.017 ns/op
# Warmup Iteration   6: 105176.256 ns/op
# Warmup Iteration   7: 102030.654 ns/op
# Warmup Iteration   8: 110387.016 ns/op
# Warmup Iteration   9: 102537.867 ns/op
# Warmup Iteration  10: 106633.927 ns/op
Iteration   1: 105633.214 ns/op
Iteration   2: 108186.815 ns/op
Iteration   3: 107049.114 ns/op
Iteration   4: 104119.672 ns/op
Iteration   5: 104809.898 ns/op
Iteration   6: 106164.691 ns/op
Iteration   7: 105229.753 ns/op
Iteration   8: 103203.168 ns/op
Iteration   9: 108872.170 ns/op
Iteration  10: 102054.285 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  106283.402 ?(99.9%) 1224.006 ns/op [Average]
  (min, avg, max) = (102054.285, 106283.402, 109840.908), stdev = 1832.035
  CI (99.9%): [105059.396, 107507.409] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 2048)

# Run progress: 17.86% complete, ETA 00:12:09
# Fork: 1 of 3
# Warmup Iteration   1: 132149.587 ns/op
# Warmup Iteration   2: 97839.494 ns/op
# Warmup Iteration   3: 101032.465 ns/op
# Warmup Iteration   4: 97759.085 ns/op
# Warmup Iteration   5: 98726.900 ns/op
# Warmup Iteration   6: 100416.894 ns/op
# Warmup Iteration   7: 99082.941 ns/op
# Warmup Iteration   8: 99055.923 ns/op
# Warmup Iteration   9: 99574.148 ns/op
# Warmup Iteration  10: 99178.995 ns/op
Iteration   1: 100956.552 ns/op
Iteration   2: 99578.362 ns/op
Iteration   3: 98696.578 ns/op
Iteration   4: 101347.473 ns/op
Iteration   5: 98802.843 ns/op
Iteration   6: 99534.071 ns/op
Iteration   7: 101512.060 ns/op
Iteration   8: 98751.470 ns/op
Iteration   9: 101432.582 ns/op
Iteration  10: 100343.750 ns/op

# Run progress: 19.05% complete, ETA 00:11:58
# Fork: 2 of 3
# Warmup Iteration   1: 146600.455 ns/op
# Warmup Iteration   2: 101130.016 ns/op
# Warmup Iteration   3: 97227.801 ns/op
# Warmup Iteration   4: 99085.472 ns/op
# Warmup Iteration   5: 97391.372 ns/op
# Warmup Iteration   6: 95389.574 ns/op
# Warmup Iteration   7: 100311.776 ns/op
# Warmup Iteration   8: 94719.054 ns/op
# Warmup Iteration   9: 99663.645 ns/op
# Warmup Iteration  10: 98388.717 ns/op
Iteration   1: 99592.943 ns/op
Iteration   2: 97447.423 ns/op
Iteration   3: 100451.974 ns/op
Iteration   4: 94278.769 ns/op
Iteration   5: 101987.779 ns/op
Iteration   6: 95874.294 ns/op
Iteration   7: 99358.380 ns/op
Iteration   8: 102284.072 ns/op
Iteration   9: 98850.512 ns/op
Iteration  10: 97914.668 ns/op

# Run progress: 20.24% complete, ETA 00:11:48
# Fork: 3 of 3
# Warmup Iteration   1: 128316.592 ns/op
# Warmup Iteration   2: 101155.571 ns/op
# Warmup Iteration   3: 98113.881 ns/op
# Warmup Iteration   4: 99157.977 ns/op
# Warmup Iteration   5: 97914.601 ns/op
# Warmup Iteration   6: 97760.369 ns/op
# Warmup Iteration   7: 97614.500 ns/op
# Warmup Iteration   8: 102350.773 ns/op
# Warmup Iteration   9: 96847.407 ns/op
# Warmup Iteration  10: 98163.749 ns/op
Iteration   1: 99383.055 ns/op
Iteration   2: 98981.060 ns/op
Iteration   3: 97509.627 ns/op
Iteration   4: 99296.797 ns/op
Iteration   5: 94173.867 ns/op
Iteration   6: 103569.243 ns/op
Iteration   7: 94864.943 ns/op
Iteration   8: 100548.683 ns/op
Iteration   9: 96250.589 ns/op
Iteration  10: 99937.442 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  99117.062 ?(99.9%) 1551.095 ns/op [Average]
  (min, avg, max) = (94173.867, 99117.062, 103569.243), stdev = 2321.606
  CI (99.9%): [97565.967, 100668.157] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = LOCAL_VARIABLE, skipLength = 8192)

# Run progress: 21.43% complete, ETA 00:11:37
# Fork: 1 of 3
# Warmup Iteration   1: 42118.135 ns/op
# Warmup Iteration   2: 28235.661 ns/op
# Warmup Iteration   3: 28708.498 ns/op
# Warmup Iteration   4: 27451.396 ns/op
# Warmup Iteration   5: 27888.473 ns/op
# Warmup Iteration   6: 27972.128 ns/op
# Warmup Iteration   7: 28549.234 ns/op
# Warmup Iteration   8: 27089.977 ns/op
# Warmup Iteration   9: 28255.297 ns/op
# Warmup Iteration  10: 27272.702 ns/op
Iteration   1: 28501.888 ns/op
Iteration   2: 27405.286 ns/op
Iteration   3: 27621.708 ns/op
Iteration   4: 28251.638 ns/op
Iteration   5: 28475.902 ns/op
Iteration   6: 27961.553 ns/op
Iteration   7: 28603.136 ns/op
Iteration   8: 27626.399 ns/op
Iteration   9: 28763.255 ns/op
Iteration  10: 27153.940 ns/op

# Run progress: 22.62% complete, ETA 00:11:26
# Fork: 2 of 3
# Warmup Iteration   1: 40045.367 ns/op
# Warmup Iteration   2: 29179.500 ns/op
# Warmup Iteration   3: 27172.163 ns/op
# Warmup Iteration   4: 28956.061 ns/op
# Warmup Iteration   5: 27128.494 ns/op
# Warmup Iteration   6: 28735.609 ns/op
# Warmup Iteration   7: 28056.643 ns/op
# Warmup Iteration   8: 27523.382 ns/op
# Warmup Iteration   9: 27368.156 ns/op
# Warmup Iteration  10: 28497.055 ns/op
Iteration   1: 26753.183 ns/op
Iteration   2: 29474.020 ns/op
Iteration   3: 26525.500 ns/op
Iteration   4: 28330.856 ns/op
Iteration   5: 28097.912 ns/op
Iteration   6: 27059.851 ns/op
Iteration   7: 29475.552 ns/op
Iteration   8: 27664.278 ns/op
Iteration   9: 27388.079 ns/op
Iteration  10: 28028.744 ns/op

# Run progress: 23.81% complete, ETA 00:11:16
# Fork: 3 of 3
# Warmup Iteration   1: 40927.031 ns/op
# Warmup Iteration   2: 28721.257 ns/op
# Warmup Iteration   3: 28457.852 ns/op
# Warmup Iteration   4: 26915.538 ns/op
# Warmup Iteration   5: 30599.774 ns/op
# Warmup Iteration   6: 27511.328 ns/op
# Warmup Iteration   7: 29463.369 ns/op
# Warmup Iteration   8: 28482.049 ns/op
# Warmup Iteration   9: 29140.920 ns/op
# Warmup Iteration  10: 28526.827 ns/op
Iteration   1: 28758.689 ns/op
Iteration   2: 27050.276 ns/op
Iteration   3: 29089.424 ns/op
Iteration   4: 27139.788 ns/op
Iteration   5: 29477.391 ns/op
Iteration   6: 27276.189 ns/op
Iteration   7: 28570.904 ns/op
Iteration   8: 27789.775 ns/op
Iteration   9: 27912.251 ns/op
Iteration  10: 27254.448 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  27982.727 ?(99.9%) 547.113 ns/op [Average]
  (min, avg, max) = (26525.500, 27982.727, 29477.391), stdev = 818.893
  CI (99.9%): [27435.614, 28529.840] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 1)

# Run progress: 25.00% complete, ETA 00:11:05
# Fork: 1 of 3
# Warmup Iteration   1: 4172710.744 ns/op
# Warmup Iteration   2: 4110213.008 ns/op
# Warmup Iteration   3: 4118395.082 ns/op
# Warmup Iteration   4: 4107880.800 ns/op
# Warmup Iteration   5: 4077857.143 ns/op
# Warmup Iteration   6: 4115018.400 ns/op
# Warmup Iteration   7: 4084461.905 ns/op
# Warmup Iteration   8: 4199907.377 ns/op
# Warmup Iteration   9: 4095044.000 ns/op
# Warmup Iteration  10: 4142297.581 ns/op
Iteration   1: 4096507.258 ns/op
Iteration   2: 4222863.934 ns/op
Iteration   3: 4147548.387 ns/op
Iteration   4: 4201018.852 ns/op
Iteration   5: 4123302.419 ns/op
Iteration   6: 4079606.349 ns/op
Iteration   7: 4170826.829 ns/op
Iteration   8: 4085847.619 ns/op
Iteration   9: 4096068.800 ns/op
Iteration  10: 4289935.000 ns/op

# Run progress: 26.19% complete, ETA 00:10:54
# Fork: 2 of 3
# Warmup Iteration   1: 4243903.390 ns/op
# Warmup Iteration   2: 4109142.742 ns/op
# Warmup Iteration   3: 4210051.639 ns/op
# Warmup Iteration   4: 4043072.441 ns/op
# Warmup Iteration   5: 4063223.016 ns/op
# Warmup Iteration   6: 4054135.714 ns/op
# Warmup Iteration   7: 4065455.556 ns/op
# Warmup Iteration   8: 4057824.603 ns/op
# Warmup Iteration   9: 4085935.714 ns/op
# Warmup Iteration  10: 4074050.394 ns/op
Iteration   1: 4183209.016 ns/op
Iteration   2: 4251055.372 ns/op
Iteration   3: 4190836.066 ns/op
Iteration   4: 4074050.000 ns/op
Iteration   5: 4128512.097 ns/op
Iteration   6: 4130584.000 ns/op
Iteration   7: 4220910.656 ns/op
Iteration   8: 4081989.600 ns/op
Iteration   9: 4094964.286 ns/op
Iteration  10: 4094932.258 ns/op

# Run progress: 27.38% complete, ETA 00:10:44
# Fork: 3 of 3
# Warmup Iteration   1: 4226806.557 ns/op
# Warmup Iteration   2: 4065576.000 ns/op
# Warmup Iteration   3: 4076239.200 ns/op
# Warmup Iteration   4: 4155647.581 ns/op
# Warmup Iteration   5: 4127070.161 ns/op
# Warmup Iteration   6: 4107573.016 ns/op
# Warmup Iteration   7: 4176109.756 ns/op
# Warmup Iteration   8: 4198212.295 ns/op
# Warmup Iteration   9: 4078206.349 ns/op
# Warmup Iteration  10: 4088768.254 ns/op
Iteration   1: 4107084.800 ns/op
Iteration   2: 4163699.187 ns/op
Iteration   3: 4104680.000 ns/op
Iteration   4: 4225113.333 ns/op
Iteration   5: 4154228.226 ns/op
Iteration   6: 4091599.200 ns/op
Iteration   7: 4155692.742 ns/op
Iteration   8: 4216645.902 ns/op
Iteration   9: 4121784.800 ns/op
Iteration  10: 4144682.927 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  4148325.997 ?(99.9%) 38671.881 ns/op [Average]
  (min, avg, max) = (4074050.000, 4148325.997, 4289935.000), stdev = 57882.255
  CI (99.9%): [4109654.116, 4186997.878] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 8)

# Run progress: 28.57% complete, ETA 00:10:33
# Fork: 1 of 3
# Warmup Iteration   1: 687452.674 ns/op
# Warmup Iteration   2: 666745.132 ns/op
# Warmup Iteration   3: 664428.590 ns/op
# Warmup Iteration   4: 658665.256 ns/op
# Warmup Iteration   5: 667336.883 ns/op
# Warmup Iteration   6: 661257.662 ns/op
# Warmup Iteration   7: 656735.678 ns/op
# Warmup Iteration   8: 669152.094 ns/op
# Warmup Iteration   9: 673725.722 ns/op
# Warmup Iteration  10: 668745.904 ns/op
Iteration   1: 679203.963 ns/op
Iteration   2: 661719.588 ns/op
Iteration   3: 678442.536 ns/op
Iteration   4: 664302.461 ns/op
Iteration   5: 662414.323 ns/op
Iteration   6: 665286.770 ns/op
Iteration   7: 679035.781 ns/op
Iteration   8: 661366.237 ns/op
Iteration   9: 656082.270 ns/op
Iteration  10: 660885.696 ns/op

# Run progress: 29.76% complete, ETA 00:10:22
# Fork: 2 of 3
# Warmup Iteration   1: 673135.072 ns/op
# Warmup Iteration   2: 685271.525 ns/op
# Warmup Iteration   3: 657745.174 ns/op
# Warmup Iteration   4: 662601.804 ns/op
# Warmup Iteration   5: 659995.725 ns/op
# Warmup Iteration   6: 661659.588 ns/op
# Warmup Iteration   7: 667466.060 ns/op
# Warmup Iteration   8: 683072.437 ns/op
# Warmup Iteration   9: 678198.419 ns/op
# Warmup Iteration  10: 667075.357 ns/op
Iteration   1: 666959.221 ns/op
Iteration   2: 666023.087 ns/op
Iteration   3: 659752.842 ns/op
Iteration   4: 685701.736 ns/op
Iteration   5: 676494.055 ns/op
Iteration   6: 673590.327 ns/op
Iteration   7: 662341.753 ns/op
Iteration   8: 671087.744 ns/op
Iteration   9: 661111.469 ns/op
Iteration  10: 665688.787 ns/op

# Run progress: 30.95% complete, ETA 00:10:12
# Fork: 3 of 3
# Warmup Iteration   1: 678643.607 ns/op
# Warmup Iteration   2: 649840.665 ns/op
# Warmup Iteration   3: 659106.033 ns/op
# Warmup Iteration   4: 647341.846 ns/op
# Warmup Iteration   5: 653224.715 ns/op
# Warmup Iteration   6: 666146.304 ns/op
# Warmup Iteration   7: 648594.325 ns/op
# Warmup Iteration   8: 661817.397 ns/op
# Warmup Iteration   9: 662967.185 ns/op
# Warmup Iteration  10: 653530.102 ns/op
Iteration   1: 653434.733 ns/op
Iteration   2: 656848.399 ns/op
Iteration   3: 647594.332 ns/op
Iteration   4: 645313.871 ns/op
Iteration   5: 648910.340 ns/op
Iteration   6: 660091.003 ns/op
Iteration   7: 657536.654 ns/op
Iteration   8: 660350.708 ns/op
Iteration   9: 647090.025 ns/op
Iteration  10: 648938.628 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  662786.645 ?(99.9%) 6926.035 ns/op [Average]
  (min, avg, max) = (645313.871, 662786.645, 685701.736), stdev = 10366.564
  CI (99.9%): [655860.609, 669712.680] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 32)

# Run progress: 32.14% complete, ETA 00:10:01
# Fork: 1 of 3
# Warmup Iteration   1: 212126.625 ns/op
# Warmup Iteration   2: 209874.274 ns/op
# Warmup Iteration   3: 208057.852 ns/op
# Warmup Iteration   4: 211987.993 ns/op
# Warmup Iteration   5: 207147.530 ns/op
# Warmup Iteration   6: 210121.367 ns/op
# Warmup Iteration   7: 213728.939 ns/op
# Warmup Iteration   8: 206857.903 ns/op
# Warmup Iteration   9: 205770.739 ns/op
# Warmup Iteration  10: 208121.057 ns/op
Iteration   1: 209932.747 ns/op
Iteration   2: 206367.658 ns/op
Iteration   3: 219227.362 ns/op
Iteration   4: 210645.905 ns/op
Iteration   5: 210656.094 ns/op
Iteration   6: 209865.353 ns/op
Iteration   7: 211575.218 ns/op
Iteration   8: 209854.802 ns/op
Iteration   9: 211078.509 ns/op
Iteration  10: 217672.166 ns/op

# Run progress: 33.33% complete, ETA 00:09:50
# Fork: 2 of 3
# Warmup Iteration   1: 215677.471 ns/op
# Warmup Iteration   2: 213585.924 ns/op
# Warmup Iteration   3: 206196.010 ns/op
# Warmup Iteration   4: 209594.674 ns/op
# Warmup Iteration   5: 214934.545 ns/op
# Warmup Iteration   6: 207119.513 ns/op
# Warmup Iteration   7: 209260.294 ns/op
# Warmup Iteration   8: 206768.538 ns/op
# Warmup Iteration   9: 215572.903 ns/op
# Warmup Iteration  10: 207501.573 ns/op
Iteration   1: 217023.139 ns/op
Iteration   2: 216482.083 ns/op
Iteration   3: 208852.140 ns/op
Iteration   4: 212532.050 ns/op
Iteration   5: 211061.209 ns/op
Iteration   6: 212107.937 ns/op
Iteration   7: 209455.488 ns/op
Iteration   8: 217230.499 ns/op
Iteration   9: 207166.224 ns/op
Iteration  10: 214691.513 ns/op

# Run progress: 34.52% complete, ETA 00:09:40
# Fork: 3 of 3
# Warmup Iteration   1: 213393.275 ns/op
# Warmup Iteration   2: 210616.936 ns/op
# Warmup Iteration   3: 208820.685 ns/op
# Warmup Iteration   4: 213023.365 ns/op
# Warmup Iteration   5: 206969.333 ns/op
# Warmup Iteration   6: 211580.463 ns/op
# Warmup Iteration   7: 207594.355 ns/op
# Warmup Iteration   8: 206641.343 ns/op
# Warmup Iteration   9: 217376.279 ns/op
# Warmup Iteration  10: 213462.388 ns/op
Iteration   1: 214032.470 ns/op
Iteration   2: 212223.627 ns/op
Iteration   3: 206950.785 ns/op
Iteration   4: 207734.269 ns/op
Iteration   5: 210250.546 ns/op
Iteration   6: 209270.334 ns/op
Iteration   7: 206864.102 ns/op
Iteration   8: 208164.387 ns/op
Iteration   9: 208932.384 ns/op
Iteration  10: 211452.588 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  211311.786 ?(99.9%) 2321.234 ns/op [Average]
  (min, avg, max) = (206367.658, 211311.786, 219227.362), stdev = 3474.315
  CI (99.9%): [208990.552, 213633.021] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 128)

# Run progress: 35.71% complete, ETA 00:09:29
# Fork: 1 of 3
# Warmup Iteration   1: 77026.840 ns/op
# Warmup Iteration   2: 75002.097 ns/op
# Warmup Iteration   3: 75284.380 ns/op
# Warmup Iteration   4: 73862.473 ns/op
# Warmup Iteration   5: 74679.099 ns/op
# Warmup Iteration   6: 74107.532 ns/op
# Warmup Iteration   7: 74484.433 ns/op
# Warmup Iteration   8: 73843.839 ns/op
# Warmup Iteration   9: 76222.404 ns/op
# Warmup Iteration  10: 76069.703 ns/op
Iteration   1: 74416.785 ns/op
Iteration   2: 76219.264 ns/op
Iteration   3: 74009.896 ns/op
Iteration   4: 75607.449 ns/op
Iteration   5: 74585.502 ns/op
Iteration   6: 76796.035 ns/op
Iteration   7: 84353.951 ns/op
Iteration   8: 74931.188 ns/op
Iteration   9: 74574.174 ns/op
Iteration  10: 78442.200 ns/op

# Run progress: 36.90% complete, ETA 00:09:19
# Fork: 2 of 3
# Warmup Iteration   1: 75711.381 ns/op
# Warmup Iteration   2: 75780.313 ns/op
# Warmup Iteration   3: 75037.655 ns/op
# Warmup Iteration   4: 73814.401 ns/op
# Warmup Iteration   5: 75037.880 ns/op
# Warmup Iteration   6: 75013.508 ns/op
# Warmup Iteration   7: 74659.208 ns/op
# Warmup Iteration   8: 73596.853 ns/op
# Warmup Iteration   9: 74839.511 ns/op
# Warmup Iteration  10: 75125.592 ns/op
Iteration   1: 74411.798 ns/op
Iteration   2: 74871.155 ns/op
Iteration   3: 75034.588 ns/op
Iteration   4: 76676.544 ns/op
Iteration   5: 77212.261 ns/op
Iteration   6: 79002.848 ns/op
Iteration   7: 84543.930 ns/op
Iteration   8: 75422.972 ns/op
Iteration   9: 77267.630 ns/op
Iteration  10: 75718.628 ns/op

# Run progress: 38.10% complete, ETA 00:09:08
# Fork: 3 of 3
# Warmup Iteration   1: 75909.552 ns/op
# Warmup Iteration   2: 74101.646 ns/op
# Warmup Iteration   3: 74210.366 ns/op
# Warmup Iteration   4: 73785.639 ns/op
# Warmup Iteration   5: 74271.711 ns/op
# Warmup Iteration   6: 73554.847 ns/op
# Warmup Iteration   7: 73997.763 ns/op
# Warmup Iteration   8: 74909.243 ns/op
# Warmup Iteration   9: 74570.632 ns/op
# Warmup Iteration  10: 74773.114 ns/op
Iteration   1: 74631.437 ns/op
Iteration   2: 74744.802 ns/op
Iteration   3: 75347.745 ns/op
Iteration   4: 76212.988 ns/op
Iteration   5: 76092.085 ns/op
Iteration   6: 74951.227 ns/op
Iteration   7: 73893.414 ns/op
Iteration   8: 75537.179 ns/op
Iteration   9: 76794.947 ns/op
Iteration  10: 78089.322 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  76346.465 ?(99.9%) 1710.117 ns/op [Average]
  (min, avg, max) = (73893.414, 76346.465, 84543.930), stdev = 2559.623
  CI (99.9%): [74636.348, 78056.582] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 512)

# Run progress: 39.29% complete, ETA 00:08:57
# Fork: 1 of 3
# Warmup Iteration   1: 39541.592 ns/op
# Warmup Iteration   2: 38981.458 ns/op
# Warmup Iteration   3: 38472.241 ns/op
# Warmup Iteration   4: 38434.260 ns/op
# Warmup Iteration   5: 39119.119 ns/op
# Warmup Iteration   6: 38544.452 ns/op
# Warmup Iteration   7: 38879.788 ns/op
# Warmup Iteration   8: 38527.047 ns/op
# Warmup Iteration   9: 31785.659 ns/op
# Warmup Iteration  10: 28511.289 ns/op
Iteration   1: 28040.173 ns/op
Iteration   2: 28768.052 ns/op
Iteration   3: 28725.478 ns/op
Iteration   4: 28219.426 ns/op
Iteration   5: 28225.290 ns/op
Iteration   6: 28186.711 ns/op
Iteration   7: 28663.280 ns/op
Iteration   8: 28490.466 ns/op
Iteration   9: 28611.037 ns/op
Iteration  10: 28144.033 ns/op

# Run progress: 40.48% complete, ETA 00:08:47
# Fork: 2 of 3
# Warmup Iteration   1: 39564.923 ns/op
# Warmup Iteration   2: 38862.211 ns/op
# Warmup Iteration   3: 39067.047 ns/op
# Warmup Iteration   4: 38908.774 ns/op
# Warmup Iteration   5: 38712.096 ns/op
# Warmup Iteration   6: 40380.591 ns/op
# Warmup Iteration   7: 38718.956 ns/op
# Warmup Iteration   8: 38886.658 ns/op
# Warmup Iteration   9: 31820.087 ns/op
# Warmup Iteration  10: 28362.596 ns/op
Iteration   1: 28222.462 ns/op
Iteration   2: 28461.685 ns/op
Iteration   3: 28349.964 ns/op
Iteration   4: 28340.839 ns/op
Iteration   5: 27984.485 ns/op
Iteration   6: 29287.134 ns/op
Iteration   7: 28164.697 ns/op
Iteration   8: 28189.950 ns/op
Iteration   9: 28572.791 ns/op
Iteration  10: 28223.992 ns/op

# Run progress: 41.67% complete, ETA 00:08:36
# Fork: 3 of 3
# Warmup Iteration   1: 39805.841 ns/op
# Warmup Iteration   2: 38874.018 ns/op
# Warmup Iteration   3: 38936.428 ns/op
# Warmup Iteration   4: 38843.230 ns/op
# Warmup Iteration   5: 39563.020 ns/op
# Warmup Iteration   6: 38971.592 ns/op
# Warmup Iteration   7: 38115.945 ns/op
# Warmup Iteration   8: 38547.483 ns/op
# Warmup Iteration   9: 30694.893 ns/op
# Warmup Iteration  10: 28175.346 ns/op
Iteration   1: 28263.034 ns/op
Iteration   2: 28145.054 ns/op
Iteration   3: 29031.228 ns/op
Iteration   4: 28198.863 ns/op
Iteration   5: 28858.899 ns/op
Iteration   6: 28451.605 ns/op
Iteration   7: 28200.521 ns/op
Iteration   8: 28166.723 ns/op
Iteration   9: 28582.813 ns/op
Iteration  10: 28083.324 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  28395.134 ?(99.9%) 207.285 ns/op [Average]
  (min, avg, max) = (27984.485, 28395.134, 29287.134), stdev = 310.255
  CI (99.9%): [28187.848, 28602.419] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 2048)

# Run progress: 42.86% complete, ETA 00:08:26
# Fork: 1 of 3
# Warmup Iteration   1: 15268.620 ns/op
# Warmup Iteration   2: 14659.401 ns/op
# Warmup Iteration   3: 14970.337 ns/op
# Warmup Iteration   4: 12334.160 ns/op
# Warmup Iteration   5: 14176.499 ns/op
# Warmup Iteration   6: 14273.818 ns/op
# Warmup Iteration   7: 15298.963 ns/op
# Warmup Iteration   8: 19146.678 ns/op
# Warmup Iteration   9: 15706.385 ns/op
# Warmup Iteration  10: 14386.257 ns/op
Iteration   1: 14534.487 ns/op
Iteration   2: 16411.376 ns/op
Iteration   3: 18104.296 ns/op
Iteration   4: 14177.461 ns/op
Iteration   5: 17653.094 ns/op
Iteration   6: 16078.409 ns/op
Iteration   7: 17211.244 ns/op
Iteration   8: 16584.661 ns/op
Iteration   9: 14047.188 ns/op
Iteration  10: 14563.787 ns/op

# Run progress: 44.05% complete, ETA 00:08:15
# Fork: 2 of 3
# Warmup Iteration   1: 15065.465 ns/op
# Warmup Iteration   2: 14274.983 ns/op
# Warmup Iteration   3: 14618.957 ns/op
# Warmup Iteration   4: 12200.602 ns/op
# Warmup Iteration   5: 13189.343 ns/op
# Warmup Iteration   6: 14738.811 ns/op
# Warmup Iteration   7: 14128.445 ns/op
# Warmup Iteration   8: 14221.000 ns/op
# Warmup Iteration   9: 13734.523 ns/op
# Warmup Iteration  10: 13189.996 ns/op
Iteration   1: 12810.965 ns/op
Iteration   2: 13680.689 ns/op
Iteration   3: 13821.647 ns/op
Iteration   4: 13191.633 ns/op
Iteration   5: 15204.771 ns/op
Iteration   6: 14181.890 ns/op
Iteration   7: 12924.375 ns/op
Iteration   8: 12912.886 ns/op
Iteration   9: 12685.151 ns/op
Iteration  10: 13112.526 ns/op

# Run progress: 45.24% complete, ETA 00:08:05
# Fork: 3 of 3
# Warmup Iteration   1: 14980.122 ns/op
# Warmup Iteration   2: 14389.268 ns/op
# Warmup Iteration   3: 14669.272 ns/op
# Warmup Iteration   4: 12505.022 ns/op
# Warmup Iteration   5: 14109.794 ns/op
# Warmup Iteration   6: 11921.202 ns/op
# Warmup Iteration   7: 13551.249 ns/op
# Warmup Iteration   8: 12950.463 ns/op
# Warmup Iteration   9: 14189.521 ns/op
# Warmup Iteration  10: 12407.588 ns/op
Iteration   1: 13783.154 ns/op
Iteration   2: 14299.741 ns/op
Iteration   3: 17032.654 ns/op
Iteration   4: 12648.109 ns/op
Iteration   5: 12485.937 ns/op
Iteration   6: 13299.241 ns/op
Iteration   7: 14733.628 ns/op
Iteration   8: 12406.244 ns/op
Iteration   9: 14781.128 ns/op
Iteration  10: 12744.686 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  14403.569 ?(99.9%) 1115.338 ns/op [Average]
  (min, avg, max) = (12406.244, 14403.569, 18104.296), stdev = 1669.386
  CI (99.9%): [13288.230, 15518.907] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD, skipLength = 8192)

# Run progress: 46.43% complete, ETA 00:07:54
# Fork: 1 of 3
# Warmup Iteration   1: 15139.578 ns/op
# Warmup Iteration   2: 14297.420 ns/op
# Warmup Iteration   3: 14519.142 ns/op
# Warmup Iteration   4: 15394.533 ns/op
# Warmup Iteration   5: 14614.043 ns/op
# Warmup Iteration   6: 21644.482 ns/op
# Warmup Iteration   7: 20428.118 ns/op
# Warmup Iteration   8: 17633.394 ns/op
# Warmup Iteration   9: 17180.906 ns/op
# Warmup Iteration  10: 17292.910 ns/op
Iteration   1: 19837.398 ns/op
Iteration   2: 18173.538 ns/op
Iteration   3: 16052.340 ns/op
Iteration   4: 14966.054 ns/op
Iteration   5: 15394.434 ns/op
Iteration   6: 19433.924 ns/op
Iteration   7: 16860.154 ns/op
Iteration   8: 19792.516 ns/op
Iteration   9: 15152.334 ns/op
Iteration  10: 16515.010 ns/op

# Run progress: 47.62% complete, ETA 00:07:43
# Fork: 2 of 3
# Warmup Iteration   1: 15178.489 ns/op
# Warmup Iteration   2: 15095.880 ns/op
# Warmup Iteration   3: 14806.198 ns/op
# Warmup Iteration   4: 14509.162 ns/op
# Warmup Iteration   5: 19580.947 ns/op
# Warmup Iteration   6: 17724.069 ns/op
# Warmup Iteration   7: 19694.127 ns/op
# Warmup Iteration   8: 19921.241 ns/op
# Warmup Iteration   9: 20568.910 ns/op
# Warmup Iteration  10: 17302.862 ns/op
Iteration   1: 25063.042 ns/op
Iteration   2: 17090.032 ns/op
Iteration   3: 14816.927 ns/op
Iteration   4: 14627.538 ns/op
Iteration   5: 15465.810 ns/op
Iteration   6: 14592.638 ns/op
Iteration   7: 16957.375 ns/op
Iteration   8: 13732.359 ns/op
Iteration   9: 15121.176 ns/op
Iteration  10: 15248.913 ns/op

# Run progress: 48.81% complete, ETA 00:07:33
# Fork: 3 of 3
# Warmup Iteration   1: 14950.845 ns/op
# Warmup Iteration   2: 14149.100 ns/op
# Warmup Iteration   3: 14474.556 ns/op
# Warmup Iteration   4: 14155.650 ns/op
# Warmup Iteration   5: 13721.272 ns/op
# Warmup Iteration   6: 13248.780 ns/op
# Warmup Iteration   7: 13903.361 ns/op
# Warmup Iteration   8: 13434.912 ns/op
# Warmup Iteration   9: 12020.450 ns/op
# Warmup Iteration  10: 13550.172 ns/op
Iteration   1: 13704.260 ns/op
Iteration   2: 13132.797 ns/op
Iteration   3: 13472.215 ns/op
Iteration   4: 12875.330 ns/op
Iteration   5: 11925.522 ns/op
Iteration   6: 14766.284 ns/op
Iteration   7: 13661.021 ns/op
Iteration   8: 13885.117 ns/op
Iteration   9: 13076.708 ns/op
Iteration  10: 12949.797 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  15611.419 ?(99.9%) 1823.760 ns/op [Average]
  (min, avg, max) = (11925.522, 15611.419, 25063.042), stdev = 2729.718
  CI (99.9%): [13787.659, 17435.179] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 1)

# Run progress: 50.00% complete, ETA 00:07:22
# Fork: 1 of 3
# Warmup Iteration   1: 4589600.893 ns/op
# Warmup Iteration   2: 4668337.273 ns/op
# Warmup Iteration   3: 4507186.842 ns/op
# Warmup Iteration   4: 4684151.376 ns/op
# Warmup Iteration   5: 4508756.140 ns/op
# Warmup Iteration   6: 4555689.381 ns/op
# Warmup Iteration   7: 4504085.841 ns/op
# Warmup Iteration   8: 4590990.179 ns/op
# Warmup Iteration   9: 4484153.509 ns/op
# Warmup Iteration  10: 4618827.027 ns/op
Iteration   1: 4541859.292 ns/op
Iteration   2: 4632869.369 ns/op
Iteration   3: 4566217.857 ns/op
Iteration   4: 4597037.500 ns/op
Iteration   5: 4553918.584 ns/op
Iteration   6: 4610127.928 ns/op
Iteration   7: 4696602.752 ns/op
Iteration   8: 4771069.159 ns/op
Iteration   9: 4616714.414 ns/op
Iteration  10: 4699871.560 ns/op

# Run progress: 51.19% complete, ETA 00:07:12
# Fork: 2 of 3
# Warmup Iteration   1: 4691988.073 ns/op
# Warmup Iteration   2: 4642916.364 ns/op
# Warmup Iteration   3: 4613819.820 ns/op
# Warmup Iteration   4: 4625185.586 ns/op
# Warmup Iteration   5: 4709323.148 ns/op
# Warmup Iteration   6: 4511963.158 ns/op
# Warmup Iteration   7: 4682126.606 ns/op
# Warmup Iteration   8: 4558050.442 ns/op
# Warmup Iteration   9: 4752296.262 ns/op
# Warmup Iteration  10: 4719112.727 ns/op
Iteration   1: 4670831.193 ns/op
Iteration   2: 4619091.892 ns/op
Iteration   3: 4586669.643 ns/op
Iteration   4: 4569682.143 ns/op
Iteration   5: 4592594.643 ns/op
Iteration   6: 4536858.036 ns/op
Iteration   7: 4629602.703 ns/op
Iteration   8: 4751994.444 ns/op
Iteration   9: 4636280.909 ns/op
Iteration  10: 4576020.354 ns/op

# Run progress: 52.38% complete, ETA 00:07:01
# Fork: 3 of 3
# Warmup Iteration   1: 4642500.000 ns/op
# Warmup Iteration   2: 4600095.495 ns/op
# Warmup Iteration   3: 4594150.893 ns/op
# Warmup Iteration   4: 4619104.505 ns/op
# Warmup Iteration   5: 4607160.714 ns/op
# Warmup Iteration   6: 4721025.000 ns/op
# Warmup Iteration   7: 4542098.230 ns/op
# Warmup Iteration   8: 4618477.679 ns/op
# Warmup Iteration   9: 4691558.716 ns/op
# Warmup Iteration  10: 4890939.048 ns/op
Iteration   1: 4706844.037 ns/op
Iteration   2: 4710711.009 ns/op
Iteration   3: 4932221.154 ns/op
Iteration   4: 5692521.348 ns/op
Iteration   5: 5322977.320 ns/op
Iteration   6: 5985659.302 ns/op
Iteration   7: 5868547.674 ns/op
Iteration   8: 6020905.882 ns/op
Iteration   9: 5306402.083 ns/op
Iteration  10: 5249978.351 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  4875089.418 ?(99.9%) 307494.872 ns/op [Average]
  (min, avg, max) = (4536858.036, 4875089.418, 6020905.882), stdev = 460243.883
  CI (99.9%): [4567594.546, 5182584.290] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 8)

# Run progress: 53.57% complete, ETA 00:06:51
# Fork: 1 of 3
# Warmup Iteration   1: 864185.329 ns/op
# Warmup Iteration   2: 824700.816 ns/op
# Warmup Iteration   3: 866293.592 ns/op
# Warmup Iteration   4: 826877.814 ns/op
# Warmup Iteration   5: 852151.907 ns/op
# Warmup Iteration   6: 856770.117 ns/op
# Warmup Iteration   7: 870493.697 ns/op
# Warmup Iteration   8: 847199.174 ns/op
# Warmup Iteration   9: 825374.272 ns/op
# Warmup Iteration  10: 1025605.010 ns/op
Iteration   1: 918678.354 ns/op
Iteration   2: 792910.510 ns/op
Iteration   3: 822424.598 ns/op
Iteration   4: 777001.062 ns/op
Iteration   5: 782761.280 ns/op
Iteration   6: 777100.304 ns/op
Iteration   7: 811415.873 ns/op
Iteration   8: 778969.499 ns/op
Iteration   9: 781594.640 ns/op
Iteration  10: 784508.769 ns/op

# Run progress: 54.76% complete, ETA 00:06:40
# Fork: 2 of 3
# Warmup Iteration   1: 803647.867 ns/op
# Warmup Iteration   2: 777088.957 ns/op
# Warmup Iteration   3: 759445.938 ns/op
# Warmup Iteration   4: 757964.749 ns/op
# Warmup Iteration   5: 774953.776 ns/op
# Warmup Iteration   6: 777970.890 ns/op
# Warmup Iteration   7: 757164.392 ns/op
# Warmup Iteration   8: 774914.048 ns/op
# Warmup Iteration   9: 789694.136 ns/op
# Warmup Iteration  10: 763901.649 ns/op
Iteration   1: 764218.182 ns/op
Iteration   2: 776382.628 ns/op
Iteration   3: 793704.954 ns/op
Iteration   4: 757903.102 ns/op
Iteration   5: 770610.075 ns/op
Iteration   6: 782779.116 ns/op
Iteration   7: 787050.772 ns/op
Iteration   8: 761771.513 ns/op
Iteration   9: 808394.646 ns/op
Iteration  10: 775585.325 ns/op

# Run progress: 55.95% complete, ETA 00:06:30
# Fork: 3 of 3
# Warmup Iteration   1: 792574.646 ns/op
# Warmup Iteration   2: 771029.635 ns/op
# Warmup Iteration   3: 805068.025 ns/op
# Warmup Iteration   4: 772407.402 ns/op
# Warmup Iteration   5: 786889.077 ns/op
# Warmup Iteration   6: 767672.754 ns/op
# Warmup Iteration   7: 783608.689 ns/op
# Warmup Iteration   8: 770103.892 ns/op
# Warmup Iteration   9: 759917.533 ns/op
# Warmup Iteration  10: 778532.979 ns/op
Iteration   1: 781691.324 ns/op
Iteration   2: 760186.716 ns/op
Iteration   3: 762788.906 ns/op
Iteration   4: 776163.885 ns/op
Iteration   5: 767892.932 ns/op
Iteration   6: 768878.378 ns/op
Iteration   7: 767263.976 ns/op
Iteration   8: 754966.365 ns/op
Iteration   9: 771270.376 ns/op
Iteration  10: 758478.487 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  782511.552 ?(99.9%) 20231.298 ns/op [Average]
  (min, avg, max) = (754966.365, 782511.552, 918678.354), stdev = 30281.257
  CI (99.9%): [762280.253, 802742.850] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 32)

# Run progress: 57.14% complete, ETA 00:06:19
# Fork: 1 of 3
# Warmup Iteration   1: 229547.632 ns/op
# Warmup Iteration   2: 229277.532 ns/op
# Warmup Iteration   3: 226831.004 ns/op
# Warmup Iteration   4: 236718.709 ns/op
# Warmup Iteration   5: 221574.558 ns/op
# Warmup Iteration   6: 236596.765 ns/op
# Warmup Iteration   7: 235758.625 ns/op
# Warmup Iteration   8: 226946.045 ns/op
# Warmup Iteration   9: 226931.247 ns/op
# Warmup Iteration  10: 224052.975 ns/op
Iteration   1: 225654.090 ns/op
Iteration   2: 227788.330 ns/op
Iteration   3: 233826.821 ns/op
Iteration   4: 235215.789 ns/op
Iteration   5: 229624.410 ns/op
Iteration   6: 228685.970 ns/op
Iteration   7: 226953.894 ns/op
Iteration   8: 237302.415 ns/op
Iteration   9: 230716.870 ns/op
Iteration  10: 239133.675 ns/op

# Run progress: 58.33% complete, ETA 00:06:08
# Fork: 2 of 3
# Warmup Iteration   1: 241251.270 ns/op
# Warmup Iteration   2: 226970.134 ns/op
# Warmup Iteration   3: 235957.810 ns/op
# Warmup Iteration   4: 226056.297 ns/op
# Warmup Iteration   5: 228355.179 ns/op
# Warmup Iteration   6: 230912.190 ns/op
# Warmup Iteration   7: 235306.916 ns/op
# Warmup Iteration   8: 232808.868 ns/op
# Warmup Iteration   9: 225399.692 ns/op
# Warmup Iteration  10: 222224.805 ns/op
Iteration   1: 227665.603 ns/op
Iteration   2: 222619.574 ns/op
Iteration   3: 236608.682 ns/op
Iteration   4: 232142.442 ns/op
Iteration   5: 226424.613 ns/op
Iteration   6: 235234.867 ns/op
Iteration   7: 231051.247 ns/op
Iteration   8: 222467.057 ns/op
Iteration   9: 222142.298 ns/op
Iteration  10: 229886.523 ns/op

# Run progress: 59.52% complete, ETA 00:05:58
# Fork: 3 of 3
# Warmup Iteration   1: 228994.626 ns/op
# Warmup Iteration   2: 222358.829 ns/op
# Warmup Iteration   3: 225519.324 ns/op
# Warmup Iteration   4: 230838.503 ns/op
# Warmup Iteration   5: 224286.930 ns/op
# Warmup Iteration   6: 235858.138 ns/op
# Warmup Iteration   7: 223732.188 ns/op
# Warmup Iteration   8: 232455.475 ns/op
# Warmup Iteration   9: 237705.432 ns/op
# Warmup Iteration  10: 227969.306 ns/op
Iteration   1: 229932.108 ns/op
Iteration   2: 227752.873 ns/op
Iteration   3: 231782.785 ns/op
Iteration   4: 226202.763 ns/op
Iteration   5: 249918.253 ns/op
Iteration   6: 248444.288 ns/op
Iteration   7: 229840.456 ns/op
Iteration   8: 234292.697 ns/op
Iteration   9: 238696.502 ns/op
Iteration  10: 246562.823 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  232152.357 ?(99.9%) 4758.400 ns/op [Average]
  (min, avg, max) = (222142.298, 232152.357, 249918.253), stdev = 7122.150
  CI (99.9%): [227393.957, 236910.758] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 128)

# Run progress: 60.71% complete, ETA 00:05:47
# Fork: 1 of 3
# Warmup Iteration   1: 87094.172 ns/op
# Warmup Iteration   2: 84167.715 ns/op
# Warmup Iteration   3: 86442.583 ns/op
# Warmup Iteration   4: 84294.308 ns/op
# Warmup Iteration   5: 79107.426 ns/op
# Warmup Iteration   6: 80766.078 ns/op
# Warmup Iteration   7: 83584.016 ns/op
# Warmup Iteration   8: 80292.338 ns/op
# Warmup Iteration   9: 76953.582 ns/op
# Warmup Iteration  10: 91531.587 ns/op
Iteration   1: 92297.214 ns/op
Iteration   2: 98792.046 ns/op
Iteration   3: 82640.000 ns/op
Iteration   4: 77954.855 ns/op
Iteration   5: 77040.765 ns/op
Iteration   6: 78943.883 ns/op
Iteration   7: 77501.552 ns/op
Iteration   8: 77099.804 ns/op
Iteration   9: 76712.678 ns/op
Iteration  10: 77644.132 ns/op

# Run progress: 61.90% complete, ETA 00:05:37
# Fork: 2 of 3
# Warmup Iteration   1: 80403.319 ns/op
# Warmup Iteration   2: 77343.674 ns/op
# Warmup Iteration   3: 77119.750 ns/op
# Warmup Iteration   4: 77117.673 ns/op
# Warmup Iteration   5: 74907.339 ns/op
# Warmup Iteration   6: 76204.556 ns/op
# Warmup Iteration   7: 74927.058 ns/op
# Warmup Iteration   8: 77064.496 ns/op
# Warmup Iteration   9: 78075.263 ns/op
# Warmup Iteration  10: 78197.669 ns/op
Iteration   1: 76160.358 ns/op
Iteration   2: 75561.500 ns/op
Iteration   3: 75998.121 ns/op
Iteration   4: 76828.374 ns/op
Iteration   5: 79552.521 ns/op
Iteration   6: 76711.297 ns/op
Iteration   7: 79136.912 ns/op
Iteration   8: 78688.564 ns/op
Iteration   9: 76757.433 ns/op
Iteration  10: 78465.220 ns/op

# Run progress: 63.10% complete, ETA 00:05:26
# Fork: 3 of 3
# Warmup Iteration   1: 79330.886 ns/op
# Warmup Iteration   2: 77104.872 ns/op
# Warmup Iteration   3: 77373.165 ns/op
# Warmup Iteration   4: 77776.965 ns/op
# Warmup Iteration   5: 75592.950 ns/op
# Warmup Iteration   6: 79521.973 ns/op
# Warmup Iteration   7: 79061.181 ns/op
# Warmup Iteration   8: 80172.390 ns/op
# Warmup Iteration   9: 76822.690 ns/op
# Warmup Iteration  10: 77673.090 ns/op
Iteration   1: 74617.092 ns/op
Iteration   2: 75670.194 ns/op
Iteration   3: 77562.939 ns/op
Iteration   4: 78098.284 ns/op
Iteration   5: 80282.541 ns/op
Iteration   6: 83428.562 ns/op
Iteration   7: 77049.504 ns/op
Iteration   8: 79535.853 ns/op
Iteration   9: 77045.401 ns/op
Iteration  10: 79621.377 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  79113.299 ?(99.9%) 3297.867 ns/op [Average]
  (min, avg, max) = (74617.092, 79113.299, 98792.046), stdev = 4936.092
  CI (99.9%): [75815.432, 82411.166] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 512)

# Run progress: 64.29% complete, ETA 00:05:16
# Fork: 1 of 3
# Warmup Iteration   1: 30886.555 ns/op
# Warmup Iteration   2: 30482.980 ns/op
# Warmup Iteration   3: 29801.259 ns/op
# Warmup Iteration   4: 29570.218 ns/op
# Warmup Iteration   5: 29437.309 ns/op
# Warmup Iteration   6: 30223.247 ns/op
# Warmup Iteration   7: 33695.608 ns/op
# Warmup Iteration   8: 33900.728 ns/op
# Warmup Iteration   9: 34536.805 ns/op
# Warmup Iteration  10: 33901.088 ns/op
Iteration   1: 35528.982 ns/op
Iteration   2: 33690.500 ns/op
Iteration   3: 34312.101 ns/op
Iteration   4: 33791.133 ns/op
Iteration   5: 34442.540 ns/op
Iteration   6: 33741.421 ns/op
Iteration   7: 35612.107 ns/op
Iteration   8: 34801.412 ns/op
Iteration   9: 35418.613 ns/op
Iteration  10: 34435.403 ns/op

# Run progress: 65.48% complete, ETA 00:05:05
# Fork: 2 of 3
# Warmup Iteration   1: 31815.719 ns/op
# Warmup Iteration   2: 29688.304 ns/op
# Warmup Iteration   3: 29947.508 ns/op
# Warmup Iteration   4: 30362.091 ns/op
# Warmup Iteration   5: 29926.179 ns/op
# Warmup Iteration   6: 30351.862 ns/op
# Warmup Iteration   7: 31817.903 ns/op
# Warmup Iteration   8: 34450.606 ns/op
# Warmup Iteration   9: 33839.434 ns/op
# Warmup Iteration  10: 32860.367 ns/op
Iteration   1: 33429.528 ns/op
Iteration   2: 34110.588 ns/op
Iteration   3: 33739.638 ns/op
Iteration   4: 35895.285 ns/op
Iteration   5: 33925.761 ns/op
Iteration   6: 34245.658 ns/op
Iteration   7: 33425.118 ns/op
Iteration   8: 34713.786 ns/op
Iteration   9: 33819.582 ns/op
Iteration  10: 35069.188 ns/op

# Run progress: 66.67% complete, ETA 00:04:55
# Fork: 3 of 3
# Warmup Iteration   1: 32191.275 ns/op
# Warmup Iteration   2: 30100.404 ns/op
# Warmup Iteration   3: 29940.273 ns/op
# Warmup Iteration   4: 29130.010 ns/op
# Warmup Iteration   5: 29647.003 ns/op
# Warmup Iteration   6: 29468.518 ns/op
# Warmup Iteration   7: 33353.413 ns/op
# Warmup Iteration   8: 34226.412 ns/op
# Warmup Iteration   9: 34906.399 ns/op
# Warmup Iteration  10: 34176.116 ns/op
Iteration   1: 33672.918 ns/op
Iteration   2: 34558.311 ns/op
Iteration   3: 34730.313 ns/op
Iteration   4: 33952.789 ns/op
Iteration   5: 37359.682 ns/op
Iteration   6: 34100.740 ns/op
Iteration   7: 33984.499 ns/op
Iteration   8: 34509.703 ns/op
Iteration   9: 35737.996 ns/op
Iteration  10: 34790.303 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  34518.187 ?(99.9%) 587.987 ns/op [Average]
  (min, avg, max) = (33425.118, 34518.187, 37359.682), stdev = 880.071
  CI (99.9%): [33930.200, 35106.173] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 2048)

# Run progress: 67.86% complete, ETA 00:04:44
# Fork: 1 of 3
# Warmup Iteration   1: 17742.769 ns/op
# Warmup Iteration   2: 15047.793 ns/op
# Warmup Iteration   3: 18121.264 ns/op
# Warmup Iteration   4: 14069.837 ns/op
# Warmup Iteration   5: 13476.822 ns/op
# Warmup Iteration   6: 13310.898 ns/op
# Warmup Iteration   7: 13127.929 ns/op
# Warmup Iteration   8: 14278.095 ns/op
# Warmup Iteration   9: 13186.086 ns/op
# Warmup Iteration  10: 13774.003 ns/op
Iteration   1: 12310.718 ns/op
Iteration   2: 12341.653 ns/op
Iteration   3: 12106.385 ns/op
Iteration   4: 12612.694 ns/op
Iteration   5: 12525.568 ns/op
Iteration   6: 12445.325 ns/op
Iteration   7: 12474.602 ns/op
Iteration   8: 12754.113 ns/op
Iteration   9: 12570.176 ns/op
Iteration  10: 12449.047 ns/op

# Run progress: 69.05% complete, ETA 00:04:34
# Fork: 2 of 3
# Warmup Iteration   1: 18217.404 ns/op
# Warmup Iteration   2: 14832.596 ns/op
# Warmup Iteration   3: 12550.672 ns/op
# Warmup Iteration   4: 12710.227 ns/op
# Warmup Iteration   5: 14972.038 ns/op
# Warmup Iteration   6: 15006.349 ns/op
# Warmup Iteration   7: 15419.943 ns/op
# Warmup Iteration   8: 16499.126 ns/op
# Warmup Iteration   9: 15548.434 ns/op
# Warmup Iteration  10: 16889.249 ns/op
Iteration   1: 15771.438 ns/op
Iteration   2: 14536.513 ns/op
Iteration   3: 16799.382 ns/op
Iteration   4: 14477.306 ns/op
Iteration   5: 14265.431 ns/op
Iteration   6: 15155.081 ns/op
Iteration   7: 15416.845 ns/op
Iteration   8: 14626.349 ns/op
Iteration   9: 15039.892 ns/op
Iteration  10: 14602.554 ns/op

# Run progress: 70.24% complete, ETA 00:04:23
# Fork: 3 of 3
# Warmup Iteration   1: 13862.998 ns/op
# Warmup Iteration   2: 12455.950 ns/op
# Warmup Iteration   3: 13392.815 ns/op
# Warmup Iteration   4: 14167.087 ns/op
# Warmup Iteration   5: 15468.941 ns/op
# Warmup Iteration   6: 16158.798 ns/op
# Warmup Iteration   7: 14545.440 ns/op
# Warmup Iteration   8: 13539.412 ns/op
# Warmup Iteration   9: 13643.008 ns/op
# Warmup Iteration  10: 15063.753 ns/op
Iteration   1: 12993.295 ns/op
Iteration   2: 13549.091 ns/op
Iteration   3: 15300.501 ns/op
Iteration   4: 14960.202 ns/op
Iteration   5: 14753.279 ns/op
Iteration   6: 14206.043 ns/op
Iteration   7: 13014.986 ns/op
Iteration   8: 12634.241 ns/op
Iteration   9: 13061.699 ns/op
Iteration  10: 12841.017 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  13753.181 ?(99.9%) 863.523 ns/op [Average]
  (min, avg, max) = (12106.385, 13753.181, 16799.382), stdev = 1292.481
  CI (99.9%): [12889.658, 14616.704] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = FIELD_ONLY_MIN_MAX, skipLength = 8192)

# Run progress: 71.43% complete, ETA 00:04:12
# Fork: 1 of 3
# Warmup Iteration   1: 13798.690 ns/op
# Warmup Iteration   2: 12824.595 ns/op
# Warmup Iteration   3: 13935.202 ns/op
# Warmup Iteration   4: 11477.594 ns/op
# Warmup Iteration   5: 11287.853 ns/op
# Warmup Iteration   6: 11579.672 ns/op
# Warmup Iteration   7: 11427.562 ns/op
# Warmup Iteration   8: 11013.557 ns/op
# Warmup Iteration   9: 11586.374 ns/op
# Warmup Iteration  10: 11243.522 ns/op
Iteration   1: 11186.294 ns/op
Iteration   2: 11075.280 ns/op
Iteration   3: 11174.781 ns/op
Iteration   4: 10731.138 ns/op
Iteration   5: 10866.811 ns/op
Iteration   6: 11494.589 ns/op
Iteration   7: 10802.744 ns/op
Iteration   8: 11273.512 ns/op
Iteration   9: 11718.457 ns/op
Iteration  10: 11624.121 ns/op

# Run progress: 72.62% complete, ETA 00:04:02
# Fork: 2 of 3
# Warmup Iteration   1: 12443.824 ns/op
# Warmup Iteration   2: 12726.156 ns/op
# Warmup Iteration   3: 14247.516 ns/op
# Warmup Iteration   4: 11461.593 ns/op
# Warmup Iteration   5: 11541.076 ns/op
# Warmup Iteration   6: 11719.991 ns/op
# Warmup Iteration   7: 11225.157 ns/op
# Warmup Iteration   8: 11566.838 ns/op
# Warmup Iteration   9: 11336.219 ns/op
# Warmup Iteration  10: 11099.563 ns/op
Iteration   1: 10947.256 ns/op
Iteration   2: 10975.988 ns/op
Iteration   3: 10684.926 ns/op
Iteration   4: 11009.202 ns/op
Iteration   5: 11374.549 ns/op
Iteration   6: 10818.151 ns/op
Iteration   7: 11443.656 ns/op
Iteration   8: 11407.184 ns/op
Iteration   9: 11318.172 ns/op
Iteration  10: 11137.733 ns/op

# Run progress: 73.81% complete, ETA 00:03:51
# Fork: 3 of 3
# Warmup Iteration   1: 13852.639 ns/op
# Warmup Iteration   2: 12678.288 ns/op
# Warmup Iteration   3: 13342.867 ns/op
# Warmup Iteration   4: 17118.955 ns/op
# Warmup Iteration   5: 16889.169 ns/op
# Warmup Iteration   6: 17737.724 ns/op
# Warmup Iteration   7: 21180.099 ns/op
# Warmup Iteration   8: 16515.478 ns/op
# Warmup Iteration   9: 16392.426 ns/op
# Warmup Iteration  10: 17686.927 ns/op
Iteration   1: 16429.107 ns/op
Iteration   2: 18855.561 ns/op
Iteration   3: 15292.832 ns/op
Iteration   4: 15632.575 ns/op
Iteration   5: 15478.359 ns/op
Iteration   6: 15724.600 ns/op
Iteration   7: 15325.077 ns/op
Iteration   8: 14807.992 ns/op
Iteration   9: 13401.561 ns/op
Iteration  10: 12459.535 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  12549.058 ?(99.9%) 1492.673 ns/op [Average]
  (min, avg, max) = (10684.926, 12549.058, 18855.561), stdev = 2234.163
  CI (99.9%): [11056.385, 14041.731] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 1)

# Run progress: 75.00% complete, ETA 00:03:41
# Fork: 1 of 3
# Warmup Iteration   1: 4645240.000 ns/op
# Warmup Iteration   2: 4502412.500 ns/op
# Warmup Iteration   3: 4563814.035 ns/op
# Warmup Iteration   4: 4615777.273 ns/op
# Warmup Iteration   5: 4510962.609 ns/op
# Warmup Iteration   6: 4504808.850 ns/op
# Warmup Iteration   7: 4696508.257 ns/op
# Warmup Iteration   8: 4619838.739 ns/op
# Warmup Iteration   9: 4647225.225 ns/op
# Warmup Iteration  10: 4527340.708 ns/op
Iteration   1: 4725962.385 ns/op
Iteration   2: 4556279.464 ns/op
Iteration   3: 4686529.091 ns/op
Iteration   4: 4590753.571 ns/op
Iteration   5: 4691545.872 ns/op
Iteration   6: 4606041.071 ns/op
Iteration   7: 4721390.741 ns/op
Iteration   8: 4557018.584 ns/op
Iteration   9: 4756233.645 ns/op
Iteration  10: 4553395.575 ns/op

# Run progress: 76.19% complete, ETA 00:03:30
# Fork: 2 of 3
# Warmup Iteration   1: 4749280.189 ns/op
# Warmup Iteration   2: 4691724.771 ns/op
# Warmup Iteration   3: 4623541.818 ns/op
# Warmup Iteration   4: 4752919.444 ns/op
# Warmup Iteration   5: 4534115.044 ns/op
# Warmup Iteration   6: 4642842.342 ns/op
# Warmup Iteration   7: 4651463.964 ns/op
# Warmup Iteration   8: 4646011.818 ns/op
# Warmup Iteration   9: 4650861.818 ns/op
# Warmup Iteration  10: 4525128.319 ns/op
Iteration   1: 4535785.841 ns/op
Iteration   2: 4534507.965 ns/op
Iteration   3: 4595525.000 ns/op
Iteration   4: 4918757.692 ns/op
Iteration   5: 4531776.991 ns/op
Iteration   6: 4631749.550 ns/op
Iteration   7: 4563008.036 ns/op
Iteration   8: 4546403.571 ns/op
Iteration   9: 4577318.750 ns/op
Iteration  10: 4753509.259 ns/op

# Run progress: 77.38% complete, ETA 00:03:20
# Fork: 3 of 3
# Warmup Iteration   1: 4732341.667 ns/op
# Warmup Iteration   2: 4559200.901 ns/op
# Warmup Iteration   3: 4641675.676 ns/op
# Warmup Iteration   4: 4514692.035 ns/op
# Warmup Iteration   5: 4641579.279 ns/op
# Warmup Iteration   6: 4598103.604 ns/op
# Warmup Iteration   7: 4534574.561 ns/op
# Warmup Iteration   8: 4530138.938 ns/op
# Warmup Iteration   9: 4565978.571 ns/op
# Warmup Iteration  10: 4547498.230 ns/op
Iteration   1: 4636624.545 ns/op
Iteration   2: 4511956.140 ns/op
Iteration   3: 4613308.929 ns/op
Iteration   4: 4623689.189 ns/op
Iteration   5: 4594264.286 ns/op
Iteration   6: 4586425.225 ns/op
Iteration   7: 4663278.899 ns/op
Iteration   8: 4556826.549 ns/op
Iteration   9: 4752081.481 ns/op
Iteration  10: 4567110.714 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  4624635.287 ?(99.9%) 61142.285 ns/op [Average]
  (min, avg, max) = (4511956.140, 4624635.287, 4918757.692), stdev = 91514.901
  CI (99.9%): [4563493.002, 4685777.572] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 8)

# Run progress: 78.57% complete, ETA 00:03:09
# Fork: 1 of 3
# Warmup Iteration   1: 760160.270 ns/op
# Warmup Iteration   2: 769419.178 ns/op
# Warmup Iteration   3: 736227.754 ns/op
# Warmup Iteration   4: 720442.194 ns/op
# Warmup Iteration   5: 724672.702 ns/op
# Warmup Iteration   6: 720076.190 ns/op
# Warmup Iteration   7: 726487.394 ns/op
# Warmup Iteration   8: 748311.842 ns/op
# Warmup Iteration   9: 727497.875 ns/op
# Warmup Iteration  10: 751722.108 ns/op
Iteration   1: 724081.497 ns/op
Iteration   2: 751861.842 ns/op
Iteration   3: 735215.540 ns/op
Iteration   4: 739277.155 ns/op
Iteration   5: 733529.471 ns/op
Iteration   6: 754411.226 ns/op
Iteration   7: 734684.835 ns/op
Iteration   8: 731631.054 ns/op
Iteration   9: 728175.461 ns/op
Iteration  10: 724370.580 ns/op

# Run progress: 79.76% complete, ETA 00:02:59
# Fork: 2 of 3
# Warmup Iteration   1: 742504.665 ns/op
# Warmup Iteration   2: 728863.376 ns/op
# Warmup Iteration   3: 732055.983 ns/op
# Warmup Iteration   4: 721962.817 ns/op
# Warmup Iteration   5: 723248.592 ns/op
# Warmup Iteration   6: 723211.955 ns/op
# Warmup Iteration   7: 727953.977 ns/op
# Warmup Iteration   8: 725600.141 ns/op
# Warmup Iteration   9: 728474.929 ns/op
# Warmup Iteration  10: 730879.830 ns/op
Iteration   1: 731573.789 ns/op
Iteration   2: 730150.000 ns/op
Iteration   3: 725122.316 ns/op
Iteration   4: 732807.286 ns/op
Iteration   5: 736512.572 ns/op
Iteration   6: 730395.708 ns/op
Iteration   7: 737716.379 ns/op
Iteration   8: 727317.989 ns/op
Iteration   9: 735907.061 ns/op
Iteration  10: 727022.521 ns/op

# Run progress: 80.95% complete, ETA 00:02:48
# Fork: 3 of 3
# Warmup Iteration   1: 743286.252 ns/op
# Warmup Iteration   2: 724228.326 ns/op
# Warmup Iteration   3: 721644.382 ns/op
# Warmup Iteration   4: 719083.124 ns/op
# Warmup Iteration   5: 728081.108 ns/op
# Warmup Iteration   6: 722122.380 ns/op
# Warmup Iteration   7: 719343.601 ns/op
# Warmup Iteration   8: 722963.752 ns/op
# Warmup Iteration   9: 723504.360 ns/op
# Warmup Iteration  10: 727748.791 ns/op
Iteration   1: 721147.133 ns/op
Iteration   2: 730641.286 ns/op
Iteration   3: 737721.203 ns/op
Iteration   4: 741126.599 ns/op
Iteration   5: 732768.429 ns/op
Iteration   6: 732184.736 ns/op
Iteration   7: 728112.358 ns/op
Iteration   8: 729694.767 ns/op
Iteration   9: 728857.407 ns/op
Iteration  10: 729495.042 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  732783.775 ?(99.9%) 4851.007 ns/op [Average]
  (min, avg, max) = (721147.133, 732783.775, 754411.226), stdev = 7260.759
  CI (99.9%): [727932.768, 737634.782] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 32)

# Run progress: 82.14% complete, ETA 00:02:38
# Fork: 1 of 3
# Warmup Iteration   1: 232404.124 ns/op
# Warmup Iteration   2: 222902.061 ns/op
# Warmup Iteration   3: 228081.128 ns/op
# Warmup Iteration   4: 221963.727 ns/op
# Warmup Iteration   5: 228707.751 ns/op
# Warmup Iteration   6: 222993.967 ns/op
# Warmup Iteration   7: 227090.941 ns/op
# Warmup Iteration   8: 221686.827 ns/op
# Warmup Iteration   9: 225575.766 ns/op
# Warmup Iteration  10: 229420.206 ns/op
Iteration   1: 226140.549 ns/op
Iteration   2: 229477.484 ns/op
Iteration   3: 222882.970 ns/op
Iteration   4: 227880.904 ns/op
Iteration   5: 235971.928 ns/op
Iteration   6: 238027.366 ns/op
Iteration   7: 235070.978 ns/op
Iteration   8: 223264.581 ns/op
Iteration   9: 230853.618 ns/op
Iteration  10: 225400.745 ns/op

# Run progress: 83.33% complete, ETA 00:02:27
# Fork: 2 of 3
# Warmup Iteration   1: 232944.692 ns/op
# Warmup Iteration   2: 231947.715 ns/op
# Warmup Iteration   3: 224823.429 ns/op
# Warmup Iteration   4: 222369.714 ns/op
# Warmup Iteration   5: 227553.233 ns/op
# Warmup Iteration   6: 224569.390 ns/op
# Warmup Iteration   7: 227395.588 ns/op
# Warmup Iteration   8: 224852.661 ns/op
# Warmup Iteration   9: 222720.862 ns/op
# Warmup Iteration  10: 231106.685 ns/op
Iteration   1: 222753.621 ns/op
Iteration   2: 227624.431 ns/op
Iteration   3: 229298.038 ns/op
Iteration   4: 228978.300 ns/op
Iteration   5: 225318.596 ns/op
Iteration   6: 229609.347 ns/op
Iteration   7: 227975.833 ns/op
Iteration   8: 224472.688 ns/op
Iteration   9: 230047.692 ns/op
Iteration  10: 225184.531 ns/op

# Run progress: 84.52% complete, ETA 00:02:16
# Fork: 3 of 3
# Warmup Iteration   1: 240070.876 ns/op
# Warmup Iteration   2: 229093.753 ns/op
# Warmup Iteration   3: 229980.054 ns/op
# Warmup Iteration   4: 228976.127 ns/op
# Warmup Iteration   5: 223590.640 ns/op
# Warmup Iteration   6: 222290.988 ns/op
# Warmup Iteration   7: 227589.609 ns/op
# Warmup Iteration   8: 228535.004 ns/op
# Warmup Iteration   9: 225472.144 ns/op
# Warmup Iteration  10: 233882.540 ns/op
Iteration   1: 230579.793 ns/op
Iteration   2: 228026.688 ns/op
Iteration   3: 227310.221 ns/op
Iteration   4: 227804.863 ns/op
Iteration   5: 224601.700 ns/op
Iteration   6: 225662.720 ns/op
Iteration   7: 228152.193 ns/op
Iteration   8: 224995.370 ns/op
Iteration   9: 226126.248 ns/op
Iteration  10: 223644.590 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  227771.286 ?(99.9%) 2487.671 ns/op [Average]
  (min, avg, max) = (222753.621, 227771.286, 238027.366), stdev = 3723.430
  CI (99.9%): [225283.615, 230258.957] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 128)

# Run progress: 85.71% complete, ETA 00:02:06
# Fork: 1 of 3
# Warmup Iteration   1: 82097.208 ns/op
# Warmup Iteration   2: 80014.643 ns/op
# Warmup Iteration   3: 79875.629 ns/op
# Warmup Iteration   4: 77475.924 ns/op
# Warmup Iteration   5: 77380.453 ns/op
# Warmup Iteration   6: 78031.015 ns/op
# Warmup Iteration   7: 78605.685 ns/op
# Warmup Iteration   8: 78216.662 ns/op
# Warmup Iteration   9: 78454.282 ns/op
# Warmup Iteration  10: 79475.378 ns/op
Iteration   1: 77662.411 ns/op
Iteration   2: 77789.523 ns/op
Iteration   3: 77563.220 ns/op
Iteration   4: 78677.826 ns/op
Iteration   5: 78267.546 ns/op
Iteration   6: 78514.375 ns/op
Iteration   7: 79425.486 ns/op
Iteration   8: 77759.167 ns/op
Iteration   9: 81879.009 ns/op
Iteration  10: 78333.968 ns/op

# Run progress: 86.90% complete, ETA 00:01:55
# Fork: 2 of 3
# Warmup Iteration   1: 82963.291 ns/op
# Warmup Iteration   2: 78967.379 ns/op
# Warmup Iteration   3: 78296.452 ns/op
# Warmup Iteration   4: 79109.977 ns/op
# Warmup Iteration   5: 78291.795 ns/op
# Warmup Iteration   6: 77889.521 ns/op
# Warmup Iteration   7: 77543.192 ns/op
# Warmup Iteration   8: 77930.907 ns/op
# Warmup Iteration   9: 78820.061 ns/op
# Warmup Iteration  10: 78102.925 ns/op
Iteration   1: 78435.625 ns/op
Iteration   2: 78336.538 ns/op
Iteration   3: 78630.588 ns/op
Iteration   4: 78066.672 ns/op
Iteration   5: 78152.667 ns/op
Iteration   6: 78859.010 ns/op
Iteration   7: 80757.669 ns/op
Iteration   8: 76280.793 ns/op
Iteration   9: 77098.958 ns/op
Iteration  10: 76157.602 ns/op

# Run progress: 88.10% complete, ETA 00:01:45
# Fork: 3 of 3
# Warmup Iteration   1: 80476.906 ns/op
# Warmup Iteration   2: 78015.920 ns/op
# Warmup Iteration   3: 77956.575 ns/op
# Warmup Iteration   4: 81008.475 ns/op
# Warmup Iteration   5: 77670.805 ns/op
# Warmup Iteration   6: 79039.830 ns/op
# Warmup Iteration   7: 77327.726 ns/op
# Warmup Iteration   8: 77430.259 ns/op
# Warmup Iteration   9: 78570.988 ns/op
# Warmup Iteration  10: 80369.296 ns/op
Iteration   1: 77875.126 ns/op
Iteration   2: 77925.986 ns/op
Iteration   3: 78753.644 ns/op
Iteration   4: 82094.612 ns/op
Iteration   5: 82096.508 ns/op
Iteration   6: 78362.531 ns/op
Iteration   7: 80033.889 ns/op
Iteration   8: 77775.897 ns/op
Iteration   9: 79076.194 ns/op
Iteration  10: 79349.908 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  78666.432 ?(99.9%) 982.682 ns/op [Average]
  (min, avg, max) = (76157.602, 78666.432, 82096.508), stdev = 1470.832
  CI (99.9%): [77683.749, 79649.114] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 512)

# Run progress: 89.29% complete, ETA 00:01:34
# Fork: 1 of 3
# Warmup Iteration   1: 41535.066 ns/op
# Warmup Iteration   2: 39995.511 ns/op
# Warmup Iteration   3: 40140.223 ns/op
# Warmup Iteration   4: 40548.003 ns/op
# Warmup Iteration   5: 39921.115 ns/op
# Warmup Iteration   6: 40184.095 ns/op
# Warmup Iteration   7: 39842.742 ns/op
# Warmup Iteration   8: 39720.169 ns/op
# Warmup Iteration   9: 39925.837 ns/op
# Warmup Iteration  10: 40030.768 ns/op
Iteration   1: 40106.667 ns/op
Iteration   2: 39900.125 ns/op
Iteration   3: 40374.832 ns/op
Iteration   4: 39723.136 ns/op
Iteration   5: 39906.788 ns/op
Iteration   6: 40004.192 ns/op
Iteration   7: 40273.800 ns/op
Iteration   8: 39553.355 ns/op
Iteration   9: 39804.161 ns/op
Iteration  10: 40019.149 ns/op

# Run progress: 90.48% complete, ETA 00:01:24
# Fork: 2 of 3
# Warmup Iteration   1: 40938.542 ns/op
# Warmup Iteration   2: 39835.997 ns/op
# Warmup Iteration   3: 40175.461 ns/op
# Warmup Iteration   4: 40390.048 ns/op
# Warmup Iteration   5: 39847.892 ns/op
# Warmup Iteration   6: 40084.927 ns/op
# Warmup Iteration   7: 40303.919 ns/op
# Warmup Iteration   8: 39777.292 ns/op
# Warmup Iteration   9: 39986.712 ns/op
# Warmup Iteration  10: 39993.203 ns/op
Iteration   1: 40302.950 ns/op
Iteration   2: 40050.211 ns/op
Iteration   3: 40137.497 ns/op
Iteration   4: 39705.567 ns/op
Iteration   5: 40339.668 ns/op
Iteration   6: 40423.479 ns/op
Iteration   7: 40180.005 ns/op
Iteration   8: 40265.744 ns/op
Iteration   9: 40388.243 ns/op
Iteration  10: 40140.487 ns/op

# Run progress: 91.67% complete, ETA 00:01:13
# Fork: 3 of 3
# Warmup Iteration   1: 41258.712 ns/op
# Warmup Iteration   2: 40111.063 ns/op
# Warmup Iteration   3: 40567.750 ns/op
# Warmup Iteration   4: 40303.066 ns/op
# Warmup Iteration   5: 40234.789 ns/op
# Warmup Iteration   6: 40131.356 ns/op
# Warmup Iteration   7: 39652.854 ns/op
# Warmup Iteration   8: 40148.701 ns/op
# Warmup Iteration   9: 39842.522 ns/op
# Warmup Iteration  10: 39852.504 ns/op
Iteration   1: 40105.391 ns/op
Iteration   2: 39626.704 ns/op
Iteration   3: 39920.629 ns/op
Iteration   4: 39887.758 ns/op
Iteration   5: 39919.253 ns/op
Iteration   6: 40405.253 ns/op
Iteration   7: 40633.055 ns/op
Iteration   8: 40190.343 ns/op
Iteration   9: 40148.449 ns/op
Iteration  10: 39975.281 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  40080.406 ?(99.9%) 172.548 ns/op [Average]
  (min, avg, max) = (39553.355, 40080.406, 40633.055), stdev = 258.262
  CI (99.9%): [39907.858, 40252.954] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 2048)

# Run progress: 92.86% complete, ETA 00:01:03
# Fork: 1 of 3
# Warmup Iteration   1: 18085.389 ns/op
# Warmup Iteration   2: 17645.206 ns/op
# Warmup Iteration   3: 17273.742 ns/op
# Warmup Iteration   4: 15893.231 ns/op
# Warmup Iteration   5: 12847.251 ns/op
# Warmup Iteration   6: 13173.225 ns/op
# Warmup Iteration   7: 13017.642 ns/op
# Warmup Iteration   8: 13543.174 ns/op
# Warmup Iteration   9: 13182.203 ns/op
# Warmup Iteration  10: 14034.042 ns/op
Iteration   1: 13124.540 ns/op
Iteration   2: 13095.865 ns/op
Iteration   3: 12945.764 ns/op
Iteration   4: 12647.354 ns/op
Iteration   5: 12405.439 ns/op
Iteration   6: 12323.713 ns/op
Iteration   7: 12342.357 ns/op
Iteration   8: 13158.512 ns/op
Iteration   9: 12732.139 ns/op
Iteration  10: 12698.753 ns/op

# Run progress: 94.05% complete, ETA 00:00:52
# Fork: 2 of 3
# Warmup Iteration   1: 18569.129 ns/op
# Warmup Iteration   2: 18919.999 ns/op
# Warmup Iteration   3: 17249.809 ns/op
# Warmup Iteration   4: 16505.845 ns/op
# Warmup Iteration   5: 16430.110 ns/op
# Warmup Iteration   6: 15938.378 ns/op
# Warmup Iteration   7: 19115.707 ns/op
# Warmup Iteration   8: 17801.215 ns/op
# Warmup Iteration   9: 19784.629 ns/op
# Warmup Iteration  10: 17539.090 ns/op
Iteration   1: 15805.957 ns/op
Iteration   2: 17611.915 ns/op
Iteration   3: 14460.235 ns/op
Iteration   4: 14572.230 ns/op
Iteration   5: 13403.178 ns/op
Iteration   6: 14284.984 ns/op
Iteration   7: 16458.569 ns/op
Iteration   8: 17018.944 ns/op
Iteration   9: 15061.271 ns/op
Iteration  10: 14659.110 ns/op

# Run progress: 95.24% complete, ETA 00:00:42
# Fork: 3 of 3
# Warmup Iteration   1: 16252.173 ns/op
# Warmup Iteration   2: 14364.799 ns/op
# Warmup Iteration   3: 15410.457 ns/op
# Warmup Iteration   4: 14705.454 ns/op
# Warmup Iteration   5: 17000.865 ns/op
# Warmup Iteration   6: 17987.103 ns/op
# Warmup Iteration   7: 18574.647 ns/op
# Warmup Iteration   8: 16591.094 ns/op
# Warmup Iteration   9: 18382.969 ns/op
# Warmup Iteration  10: 17785.992 ns/op
Iteration   1: 17018.020 ns/op
Iteration   2: 21285.460 ns/op
Iteration   3: 16380.732 ns/op
Iteration   4: 19509.426 ns/op
Iteration   5: 16685.076 ns/op
Iteration   6: 15411.074 ns/op
Iteration   7: 15104.788 ns/op
Iteration   8: 14947.231 ns/op
Iteration   9: 15416.896 ns/op
Iteration  10: 16256.716 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  14960.875 ?(99.9%) 1465.685 ns/op [Average]
  (min, avg, max) = (12323.713, 14960.875, 21285.460), stdev = 2193.769
  CI (99.9%): [13495.190, 16426.560] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native -Xms1g -Xmx1g
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 500 ms each
# Measurement: 10 iterations, 500 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip
# Parameters: (inputStreamSize = 1000000, inputStreamType = SOFT_REFERENCE, skipLength = 8192)

# Run progress: 96.43% complete, ETA 00:00:31
# Fork: 1 of 3
# Warmup Iteration   1: 15361.881 ns/op
# Warmup Iteration   2: 15085.520 ns/op
# Warmup Iteration   3: 16011.315 ns/op
# Warmup Iteration   4: 18083.297 ns/op
# Warmup Iteration   5: 13249.011 ns/op
# Warmup Iteration   6: 14186.862 ns/op
# Warmup Iteration   7: 13768.360 ns/op
# Warmup Iteration   8: 16325.978 ns/op
# Warmup Iteration   9: 15523.017 ns/op
# Warmup Iteration  10: 15628.375 ns/op
Iteration   1: 15959.578 ns/op
Iteration   2: 15681.373 ns/op
Iteration   3: 14843.035 ns/op
Iteration   4: 12931.009 ns/op
Iteration   5: 13071.174 ns/op
Iteration   6: 14184.693 ns/op
Iteration   7: 14848.815 ns/op
Iteration   8: 15237.137 ns/op
Iteration   9: 15604.859 ns/op
Iteration  10: 14932.179 ns/op

# Run progress: 97.62% complete, ETA 00:00:21
# Fork: 2 of 3
# Warmup Iteration   1: 20835.716 ns/op
# Warmup Iteration   2: 17723.204 ns/op
# Warmup Iteration   3: 16149.471 ns/op
# Warmup Iteration   4: 17028.667 ns/op
# Warmup Iteration   5: 13812.809 ns/op
# Warmup Iteration   6: 12943.894 ns/op
# Warmup Iteration   7: 13959.351 ns/op
# Warmup Iteration   8: 14268.782 ns/op
# Warmup Iteration   9: 12109.592 ns/op
# Warmup Iteration  10: 12603.708 ns/op
Iteration   1: 11347.868 ns/op
Iteration   2: 11404.693 ns/op
Iteration   3: 11331.342 ns/op
Iteration   4: 11642.061 ns/op
Iteration   5: 11251.964 ns/op
Iteration   6: 10776.422 ns/op
Iteration   7: 10893.378 ns/op
Iteration   8: 11618.745 ns/op
Iteration   9: 11273.981 ns/op
Iteration  10: 11399.271 ns/op

# Run progress: 98.81% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 18471.849 ns/op
# Warmup Iteration   2: 17926.383 ns/op
# Warmup Iteration   3: 14385.317 ns/op
# Warmup Iteration   4: 14695.128 ns/op
# Warmup Iteration   5: 16797.477 ns/op
# Warmup Iteration   6: 16688.271 ns/op
# Warmup Iteration   7: 16693.575 ns/op
# Warmup Iteration   8: 15288.133 ns/op
# Warmup Iteration   9: 16505.803 ns/op
# Warmup Iteration  10: 17451.850 ns/op
Iteration   1: 17747.763 ns/op
Iteration   2: 19049.295 ns/op
Iteration   3: 17216.138 ns/op
Iteration   4: 14599.923 ns/op
Iteration   5: 16889.695 ns/op
Iteration   6: 17842.919 ns/op
Iteration   7: 15041.770 ns/op
Iteration   8: 17010.571 ns/op
Iteration   9: 15264.114 ns/op
Iteration  10: 15088.660 ns/op


Result "org.openjdk.bench.java.io.InputStreamSkipBenchmark.testSkip":
  14199.481 ?(99.9%) 1637.121 ns/op [Average]
  (min, avg, max) = (10776.422, 14199.481, 19049.295), stdev = 2450.366
  CI (99.9%): [12562.360, 15836.602] (assumes normal distribution)


# Run complete. Total time: 00:14:44

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.

Benchmark                          (inputStreamSize)   (inputStreamType)  (skipLength)  Mode  Cnt        Score        Error  Units
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE             1  avgt   30  4849413.254 ?  69038.211  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE             8  avgt   30   755963.169 ?  22429.963  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE            32  avgt   30   249989.541 ?   3752.365  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE           128  avgt   30   101699.284 ?   1335.823  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE           512  avgt   30   106283.402 ?   1224.006  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE          2048  avgt   30    99117.062 ?   1551.095  ns/op
InputStreamSkipBenchmark.testSkip            1000000      LOCAL_VARIABLE          8192  avgt   30    27982.727 ?    547.113  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD             1  avgt   30  4148325.997 ?  38671.881  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD             8  avgt   30   662786.645 ?   6926.035  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD            32  avgt   30   211311.786 ?   2321.234  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD           128  avgt   30    76346.465 ?   1710.117  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD           512  avgt   30    28395.134 ?    207.285  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD          2048  avgt   30    14403.569 ?   1115.338  ns/op
InputStreamSkipBenchmark.testSkip            1000000               FIELD          8192  avgt   30    15611.419 ?   1823.760  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX             1  avgt   30  4875089.418 ? 307494.872  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX             8  avgt   30   782511.552 ?  20231.298  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX            32  avgt   30   232152.357 ?   4758.400  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX           128  avgt   30    79113.299 ?   3297.867  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX           512  avgt   30    34518.187 ?    587.987  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX          2048  avgt   30    13753.181 ?    863.523  ns/op
InputStreamSkipBenchmark.testSkip            1000000  FIELD_ONLY_MIN_MAX          8192  avgt   30    12549.058 ?   1492.673  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE             1  avgt   30  4624635.287 ?  61142.285  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE             8  avgt   30   732783.775 ?   4851.007  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE            32  avgt   30   227771.286 ?   2487.671  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE           128  avgt   30    78666.432 ?    982.682  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE           512  avgt   30    40080.406 ?    172.548  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE          2048  avgt   30    14960.875 ?   1465.685  ns/op
InputStreamSkipBenchmark.testSkip            1000000      SOFT_REFERENCE          8192  avgt   30    14199.481 ?   1637.121  ns/op


</p>
</details>

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Thu Apr 14 19:07:30 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 14 Apr 2022 19:07:30 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v3]
In-Reply-To: <SF-JRSPe_Hk8O_VqWH7aPbmp9YIIQd6kcj7sYdrFbzk=.2f8d57d4-d2aa-4478-86fc-c0cd98e86d62@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
 <SF-JRSPe_Hk8O_VqWH7aPbmp9YIIQd6kcj7sYdrFbzk=.2f8d57d4-d2aa-4478-86fc-c0cd98e86d62@github.com>
Message-ID: <7oF8zYJwF_OJYN_RFJknAt_JO0vuYMQwek_Zm26vl9Y=.1d46896d-cf69-43f5-b7f6-d3a003990a46@github.com>

On Thu, 14 Apr 2022 18:29:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
>> 
>> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

Marked as reviewed by rriggs (Reviewer).

Core-libs issues only require 1 reviewer; though some more complex issues deserve more than 1.
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8240

From ihse at openjdk.java.net  Thu Apr 14 19:37:06 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 19:37:06 GMT
Subject: RFR: 8284893: Fix typos in java.base
Message-ID: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>

I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.

(Due to false positives this can unfortunately not be run automatically) 

The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.

Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

-------------

Commit messages:
 - Pass #2
 - 8284893: Fix typos in java.base

Changes: https://git.openjdk.java.net/jdk/pull/8250/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284893
  Stats: 268 lines in 180 files changed: 0 ins; 0 del; 268 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250

PR: https://git.openjdk.java.net/jdk/pull/8250

From ihse at openjdk.java.net  Thu Apr 14 19:37:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 14 Apr 2022 19:37:33 GMT
Subject: Integrated: 8284891: Fix typos in build system files
In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com>
Message-ID: <2mF5V7umZUZe-exsy8TAj69oQs5CZ1A41lGknDaoNVc=.bf65fd9f-8851-4626-8bd1-6f23fef1e945@github.com>

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> Most of the fixes are in comments. A few are in messages aimed at the user.

This pull request has now been integrated.

Changeset: 160eb2bd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/160eb2bd392fea29dd690ee9781174d14dc0b659
Stats:     72 lines in 46 files changed: 0 ins; 0 del; 72 mod

8284891: Fix typos in build system files

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/8246

From naoto at openjdk.java.net  Thu Apr 14 19:51:29 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 19:51:29 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <KzD9I_Ll4BSRvfaNeTJE9oFu5c-d-lK14u4cZoycM7M=.b213785f-0bca-42e7-bfd7-756b8a628799@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

src/java.base/share/classes/jdk/internal/icu/impl/NormalizerImpl.java line 2002:

> 2000:                 }
> 2001: 
> 2002:                 // this is where we are right now with all these indices:

Although these are actual typos, they come from upstream ICU code. Changing them locally would make merging complicated, so please exclude ICU related changes from the PR. I guess fixes in other 3rd party libraries are in the same boat.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From wetmore at openjdk.java.net  Thu Apr 14 19:58:48 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 14 Apr 2022 19:58:48 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
Message-ID: <PGqk-qoYHcGMQXeez1FBLcWjDr-YdksvA0ZrUOIbgCs=.d5dcd37c-2412-44ba-9cbc-68eed4b0f5bd@github.com>

On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add `@LastModified: Apr 2022` to DocumentCache

I learned something new about HashMap today...

I looked at java.security.cert and sun.security.* and that part LGTM.

That said, you need to check with @seanjmullan for the java.xml.crypto code.  We try to keep the code in sync with the Apache code.  As this is a new API, we probably can't push this kind of change to Apache as they need to support older releases.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java line 110:

> 108:                 int length = attributes.getLength();
> 109:                 Map<String, String> namespaceMap =
> 110:                         HashMap.newHashMap(length);

Please check these changes with @seanjmullan before integrating.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7928

From mullan at openjdk.java.net  Thu Apr 14 19:58:49 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 14 Apr 2022 19:58:49 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
Message-ID: <W_uSQSqLoHuPOuubV4NPKvP6ywhbhBRHQHtjIf-T4Ho=.b361deb5-6d4b-4192-804e-9d11bbbd17d2@github.com>

On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add `@LastModified: Apr 2022` to DocumentCache

Right, we generally try to avoid making too many changes to the implementation code in the java.xml.crypto module in order to stay consistent with Apache Santuario. They also would not accept this change because it is a new API and they need to run on older releases. I haven't had time yet to understand this Enhancement, but are the changes necessary for this part?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From iris at openjdk.java.net  Thu Apr 14 20:04:29 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 14 Apr 2022 20:04:29 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <NFvf7_p4txi12-K2-912ClqS4tYNahmEeymbTVj_r8Y=.160b9349-4a43-40eb-a21d-ce957322d779@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

Looks good.

I usually like GitHub's colorful diffs, but this is one of those rare cases where looking at the single webrev-generated diff file is so much easier.  About the only thing that could improve it would be to reduce the context (i.e. "diff -C").

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8250

From duke at openjdk.java.net  Thu Apr 14 20:15:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 20:15:33 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
Message-ID: <qly5zkZEVyG6oOE3o_bbZUfJDmQJ-kGRDnIJCsbINBs=.685798e4-cd91-496c-aa1c-a9b68f75cd21@github.com>

On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add `@LastModified: Apr 2022` to DocumentCache

> Are the changes necessary for this part?

@seanjmullan no, they are just performance refinement.

If you really that wanna 100% sync ,

I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java

Is this solution acceptable then?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From mullan at openjdk.java.net  Thu Apr 14 20:20:33 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 14 Apr 2022 20:20:33 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <qly5zkZEVyG6oOE3o_bbZUfJDmQJ-kGRDnIJCsbINBs=.685798e4-cd91-496c-aa1c-a9b68f75cd21@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
 <qly5zkZEVyG6oOE3o_bbZUfJDmQJ-kGRDnIJCsbINBs=.685798e4-cd91-496c-aa1c-a9b68f75cd21@github.com>
Message-ID: <aNyUSJzlvcSuVVEJD89DyIy5SBa1gL7esaf3ZpuVpmQ=.98e6b339-c853-4a88-84e3-6c245a979a0f@github.com>

On Thu, 14 Apr 2022 20:11:37 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> > Are the changes necessary for this part?
> 
> @seanjmullan no, they are just performance refinement.
> 
> If you really that wanna 100% sync ,
> 
> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java
> 
> Is this solution acceptable then?

Yes, that would be preferred. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From wetmore at openjdk.java.net  Thu Apr 14 20:23:30 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 14 Apr 2022 20:23:30 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

I checked over:

java.base/macosx/classes/apple/security
java.base/share/classes/com/sun/crypto
java.base/share/classes/com/sun/security
java.base/share/classes/java/security
java.base/share/classes/javax/crypto
java.base/share/classes/javax/net
java.base/share/classes/sun/security

The copyright dates need updating.

src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java line 128:

> 126:         // Each time this method is called, we're examining a new list
> 127:         // from the global list. So, we have to start by getting the list
> 128:         // that contains the set of Vertices we're considering.

The class being affected is a Vertex, so either change to vertices, or leave as is...

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8250

From psandoz at openjdk.java.net  Thu Apr 14 20:30:35 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 14 Apr 2022 20:30:35 GMT
Subject: Integrated: 8283892: Compress and expand bits
In-Reply-To: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
References: <6PdYH5IGwfQYxPfrPazEd0foOe1Bn1EoRs87xht-kmU=.1fcfc4dc-e995-41de-88b2-98c209272455@github.com>
Message-ID: <_t2FzihhY8_5hhzerI-nkeCH3EEO_S_3MchFmldPX0Y=.850b99d8-15df-411f-8fc6-a7e174f77c81@github.com>

On Tue, 5 Apr 2022 22:05:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Add support to compress bits and expand bits of `int` and `long` values, see Hacker's Delight (2nd edition), section 7.4.
> 
> Compressing or expanding bits of an `int` or `long` value can be composed to enable general permutations, and the "sheep and goats" operation (SAG) see Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a stable binary radix sort.
> 
> The compress and expand functionality maps efficiently to hardware instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the implementations can be very efficient on supporting hardware. Intrinsification will occur in a separate PR.
> 
> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the beneficial performance impact of the `PDEP` instruction, and by extension the `expand` method, when applied to the implementation of a bit-vector select operation in succinct data structures (for example `select(r)` returns the position of the `r`th 1).
> 
> Testing-wise the approach take is three fold:
> 1. Tests compared against simple implementations that are easy to read and verify against the JDK implementations (which later will also be made intrinsic). To compensate all tests are also run flipping the test methods and the methods under test.
> 2. Tests composed of compress and expand and vice versa.
> 3. Tests with known mask patterns, whose expected values are easily derived from the inputs.

This pull request has now been integrated.

Changeset: fbb09160
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fbb09160906b4d9b0a29c8e99465f12ad16d4c88
Stats:     1031 lines in 7 files changed: 1024 ins; 5 del; 2 mod

8283892: Compress and expand bits

Reviewed-by: alanb, redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/8115

From smarks at openjdk.java.net  Thu Apr 14 20:43:44 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 14 Apr 2022 20:43:44 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <PGqk-qoYHcGMQXeez1FBLcWjDr-YdksvA0ZrUOIbgCs=.d5dcd37c-2412-44ba-9cbc-68eed4b0f5bd@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
 <PGqk-qoYHcGMQXeez1FBLcWjDr-YdksvA0ZrUOIbgCs=.d5dcd37c-2412-44ba-9cbc-68eed4b0f5bd@github.com>
Message-ID: <UfhZnP73mlxYy6OFNfFOPiNnqa8EWg_I5lxPC3FJWsg=.bf1c6eff-e08d-4f3f-af05-8106821c66a2@github.com>

On Thu, 14 Apr 2022 19:53:45 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add `@LastModified: Apr 2022` to DocumentCache
>
> I learned something new about HashMap today...
> 
> I looked at java.security.cert and sun.security.* and that part LGTM.
> 
> That said, you need to check with @seanjmullan for the java.xml.crypto code.  We try to keep the code in sync with the Apache code.  As this is a new API, we probably can't push this kind of change to Apache as they need to support older releases.

Thanks @bradfordwetmore and @seanjmullan for looking at this, and @XenoAmess for following up quickly.

To summarize, it sounds like the only issues are with the changes to two files in the `java.xml.crypto` area, as those need to be maintained in sync with Apache Santuario. Right?

In both cases it looks like the HashMap is likely being under-allocated, so the fix would be to inline to capacity computation, something like `new HashMap<>((int) Math.ceil(length / 0.75))` I guess.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From naoto at openjdk.java.net  Thu Apr 14 21:04:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 21:04:31 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18]
In-Reply-To: <xr_Oxv8hC520hKGE0ZZGlje1WFwE2ganf__RB_l_x_Y=.db498695-3f47-49a0-8fe4-001fe9fb7b67@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com>
 <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com>
 <uNsLbPcKwzq-jlie7JtG8BbwMtMYJ-hTH1h4SD9aybo=.8acf4bf4-4cb7-4b8d-9261-4e29e6ba3ed2@github.com>
 <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com>
 <xr_Oxv8hC520hKGE0ZZGlje1WFwE2ganf__RB_l_x_Y=.db498695-3f47-49a0-8fe4-001fe9fb7b67@github.com>
Message-ID: <URmfzCNj1_Yt7Y9XCaHJgmGJWo-vAXCUV91LH1OCzh0=.effaaf8d-89d2-4e6e-b17d-bcdc4b8f8db3@github.com>

On Thu, 14 Apr 2022 18:32:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>> 
>> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this.
>
> Thanks. Will fix it myself, as I want to eliminate that immediate value in the code.

PR opened, based on this PR.
https://github.com/openjdk/jdk/pull/8253

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From asemenyuk at openjdk.java.net  Thu Apr 14 21:04:52 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 14 Apr 2022 21:04:52 GMT
Subject: RFR: JDK-8236128: Allow jpackage create installers for services
 [v2]
In-Reply-To: <Rc1qJzW40px0VvmFGDZBcQ-Ow3w7ubJNmzHu7PkSmQE=.7d67b399-5d2f-4537-9275-4ae9b88ed33f@github.com>
References: <Rc1qJzW40px0VvmFGDZBcQ-Ow3w7ubJNmzHu7PkSmQE=.7d67b399-5d2f-4537-9275-4ae9b88ed33f@github.com>
Message-ID: <R2KLGE__w7gzMOpSvhUIAGy2DDNK1DwppVQjiZ8MZb0=.37254868-119d-488f-ba1a-f3581d252e8e@github.com>

> Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
>  CSR

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 121 commits:

 - Merge branch 'master' into JDK-8236128
 - Whitespace cleanup
 - Whitespace cleanup
 - JDK-8236128: Allow jpackage create installers for services
 - Sync l10n files. Fix copyright year
 - Minor formatting fix
 - Merge fix
 - Merge fixed
 - Merge branch 'master' into JDK-8236128
 - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk into JDK-8236128
 - ... and 111 more: https://git.openjdk.java.net/jdk/compare/f4edb59a...1a3d7cf5

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7793&range=01
  Stats: 3116 lines in 64 files changed: 2848 ins; 121 del; 147 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7793/head:pull/7793

PR: https://git.openjdk.java.net/jdk/pull/7793

From naoto at openjdk.java.net  Thu Apr 14 21:22:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 21:22:50 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers
Message-ID: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>

Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/7928

Commit messages:
 - 8284856: Add a test case for checking UnicodeScript entity numbers

Changes: https://git.openjdk.java.net/jdk/pull/8253/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8253&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284856
  Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8253/head:pull/8253

PR: https://git.openjdk.java.net/jdk/pull/8253

From duke at openjdk.java.net  Thu Apr 14 21:27:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 21:27:16 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22]
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>

> 8186958: Need method to create pre-sized HashMap

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  java.xml.crypto's usage downgrade grammar to 1.8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7928/files
  - new: https://git.openjdk.java.net/jdk/pull/7928/files/71b7dba3..95e22f25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=20-21

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7928.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Thu Apr 14 21:27:18 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 14 Apr 2022 21:27:18 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <PGqk-qoYHcGMQXeez1FBLcWjDr-YdksvA0ZrUOIbgCs=.d5dcd37c-2412-44ba-9cbc-68eed4b0f5bd@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
 <PGqk-qoYHcGMQXeez1FBLcWjDr-YdksvA0ZrUOIbgCs=.d5dcd37c-2412-44ba-9cbc-68eed4b0f5bd@github.com>
Message-ID: <BUMNpoXrr1X5tXt2b-zSXqFerDZpzb8YwCyuFr92EY4=.085066d6-8201-4fda-b41a-3f9105a5656b@github.com>

On Thu, 14 Apr 2022 19:56:22 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add `@LastModified: Apr 2022` to DocumentCache
>
> src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java line 110:
> 
>> 108:                 int length = attributes.getLength();
>> 109:                 Map<String, String> namespaceMap =
>> 110:                         HashMap.newHashMap(length);
> 
> Please check these changes with @seanjmullan before integrating.

@seanjmullan 
mirror pr in https://github.com/apache/santuario-xml-security-java/pull/64
jira at https://issues.apache.org/jira/projects/SANTUARIO/issues/SANTUARIO-586?filter=reportedbyme

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From psandoz at openjdk.java.net  Thu Apr 14 21:42:08 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 14 Apr 2022 21:42:08 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <dcCZ3cRzLKnKAn_8Wc7gw-_9aXlP3cGzA0TodgM95YY=.6c184371-b9bd-4729-9e06-5a234cd91567@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/Thread.java line 862:

> 860:          * @param start the starting value of the counter
> 861:          * @return this builder
> 862:          * @throws IllegalArgumentException if count is negative

Suggestion:

         * @throws IllegalArgumentException if start is negative

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From iris at openjdk.java.net  Thu Apr 14 21:42:51 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 14 Apr 2022 21:42:51 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers
In-Reply-To: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
Message-ID: <cTBqB4hGuP86DooFcGcyPquT9AiexA_zEc4-BaZ1Yh4=.0a01f128-b21b-45fe-b49d-1a02696f2b6a@github.com>

On Thu, 14 Apr 2022 20:52:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.

Nice catch in the review for 8186958.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8253

From psandoz at openjdk.java.net  Thu Apr 14 21:54:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 14 Apr 2022 21:54:44 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <Ni3fWhOk8jAyK8ko9jNEm4nybvzq5fXZAGlf9UTq750=.0c462e40-46c2-46a7-beb3-773afc59498d@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/Thread.java line 213:

> 211: 
> 212:     // Additional fields for platform threads
> 213:     private static class FieldHolder {

All but the task field are explicitly known by the VM (and stillborn is not accessed by Java code. Suggest grouping accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Thu Apr 14 22:17:52 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 14 Apr 2022 22:17:52 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v6]
In-Reply-To: <ee9hku95IwMoM8qWNtOOFbN-Ml6Z-FJVDi7idbo68mI=.3f48c952-638c-41ac-9045-51f891579e00@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <ee9hku95IwMoM8qWNtOOFbN-Ml6Z-FJVDi7idbo68mI=.3f48c952-638c-41ac-9045-51f891579e00@github.com>
Message-ID: <CQzKv1mjdzFFWs8DkY2GFuDlY2SICCmICiVvPOgjQ8k=.7d5910ae-1232-4c7d-bbcd-175a581bb481@github.com>

On Thu, 14 Apr 2022 18:52:25 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine jmh

Now this makes sense, that with a skip buffer of 2048, skipping by 2048 has a similar performance as skipping by 8192 for field-backed ones.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From psandoz at openjdk.java.net  Thu Apr 14 22:22:45 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 14 Apr 2022 22:22:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <uRyyuibBtTDjeKpe5Q7ZJCtiH3ln59y5O6ddG5NDXGY=.c4a246ee-299e-43ba-8bad-c7cbd59876bb@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/Thread.java line 3028:

> 3026: 
> 3027:     /** The thread container that this thread is in */
> 3028:     @Stable private volatile ThreadContainer container;

The `volatile` modifier with `@Stable` is unusual. IIUC the field is set once on start (behaves as if a final field). Once C2 gets hold of it and can treat the value as a runtime constant the `volatile` has no effect. This is a tricky area but i think a store fence will suffice in `setThreadContainer` since the value goes from null to non-null and therefore cannot be speculated upon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From naoto at openjdk.java.net  Thu Apr 14 22:27:20 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Apr 2022 22:27:20 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers [v2]
In-Reply-To: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
Message-ID: <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>

> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed a typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8253/files
  - new: https://git.openjdk.java.net/jdk/pull/8253/files/31da445c..fc30fc9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8253&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8253&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8253/head:pull/8253

PR: https://git.openjdk.java.net/jdk/pull/8253

From iris at openjdk.java.net  Thu Apr 14 23:14:41 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 14 Apr 2022 23:14:41 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers [v2]
In-Reply-To: <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
 <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
Message-ID: <keoo_NqRl8TjKcVIcbxnC4biRHoO0KZXWQ_tMAht5mI=.487d2b0c-5fa9-4111-b80a-7c54d79e8c76@github.com>

On Thu, 14 Apr 2022 22:27:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8253

From smarks at openjdk.java.net  Thu Apr 14 23:31:47 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 14 Apr 2022 23:31:47 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers [v2]
In-Reply-To: <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
 <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
Message-ID: <3bKWF7Dn6L4APgsP_u_7cYljTGq20C_HFTgVaykWXKY=.8bcf41e0-f29f-4005-9bda-9698c920c403@github.com>

On Thu, 14 Apr 2022 22:27:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo

LGTM

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8253

From psandoz at openjdk.java.net  Fri Apr 15 00:19:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 00:19:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <ObFjCRzngqS_orQeqp6lhdjl0lP-4KYWDrwpI2iSN0k=.6517d5cb-acf3-4147-90ad-d1768f535dbc@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/VirtualThread.java line 65:

> 63:  * system.
> 64:  */
> 65: class VirtualThread extends Thread {

Suggestion:

final class VirtualThread extends Thread {

src/java.base/share/classes/java/lang/VirtualThread.java line 94:

> 92:      *  RUNNING -> PARKING         // Thread attempts to park
> 93:      *  PARKING -> PARKED          // yield successful, thread is parked
> 94:      *  PARKING -> PINNED          // yield failed, thread is pinned

Suggestion:

     *  PARKING -> PARKED          // parking successful, thread is parked
     *  PARKING -> PINNED          // parking failed, thread is pinned

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sminervini.prism at protonmail.com  Fri Apr 15 02:32:18 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Fri, 15 Apr 2022 02:32:18 +0000
Subject: OpenJDK or SE Java Floating Point Options?
Message-ID: <YwsPzgiMbmskjtJ6r2FJG8zFrPBqtvwcansnnEk2-Yo48d2RdDWmrzOk2mbRLubYrXC60vV8D43k4uALmx1yqT-TtKGIYJJdChrRTqNnrps=@protonmail.com>

To core-libs-dev at openjdk.java.net,

The Java OpenJDK, particularly the runtime, in its present state, has one key problem. Arithmetic performed by operators on number variables or data, of types float and double, are able to gain denormal or pronormal values, alongside method calls made on java.lang.StrictMath. This is is always quoted as being because of Java adherence to standard IEEE 754,
which has a 2008 version, and also has a more recent but non-free paper released in 2019.

Programmers need range accurate integer and decimal mathematics, in higher level computer languages such as Java, certainly higher level languages than Assembly or C. While Java does have a workaround approach to these floating point problems, involving BigDecimal and BigInteger, and another approach that supplies a calculator class, the big-math library,

https://github.com/eobermuhlner/big-math ,

using and rely on these stop-gap, work-around solutions is a poor approach, which can eventually become problematic. BigInteger and BigDecimal are larger in memory than needed, they are slower, messier in source code to program, debug, understand and edit, of themselves exclude access to operator syntax, and also are never reified with Java official library classes or interfaces.

The standard document IEEE 754, with its capitulation of floating point arithmetic, mentions traps, state exceptions and flags, phenomena that as of OpenJDK 17 Java has not adopted. It has been the view that because 754 doesn't stipulate what happens with underflow or overflow specifically, nor does it stipulate that it is a base 10 system on top of a binary one exactly, that therefore, because of this, underflow and overflow aren't (and can't be) bugs or software logic errors, by "definition of IEEE 754".

It has been this which has lead to the rejection of a series of related bug requests on the Java online bug database submission system to simply be denied.

The original justification for floating point denormal and pronormals is a view which wants to compromise digit place accuracy for speed. This is diametrically fused with a more important view that must have all accurate digit places for full range accuracy, because that is simply required by some technical task that the language is designed for and supported to perform. However, in modern times it has become the case that this compromise isn't needed any more, since accuracy can dovetail with speed, given modern hardware evolution, in the shape of the SSE phenomenon and similar.

Since 754 is not stated to be either a base 10 or base 2 system, therefore from base 10's point of view, it could be either.

Binary numbers and their arithmetic are for the sake of machines. Decimal mathematics is for the sake of human beings.
Given this, it makes things the case that IEEE 754 is incomplete, leading to inconsistency and finally incoherency. These mean that 754 has a "blind spot" which does lead to logic errors.

This state of affairs has made original floating point correction, at the level of the original operator and StrictMath method call level, within the Java ubiquity itself, both pertinent and critical.

Notwistanding calculator classes and comparisons, consider the following two code fragments:

//----------------------------------------------------------
//The C++ Language. Arithmetic only, no comparisons.

#include

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}

/*
Program has started...

0.01

0.01

Program has Finished.*/

//----------------------------------------------------------
//The Java Language. Arithmetic only, no comparisons.

import static java.lang.System.*;
public class Start
{
public static void main(String ... args)
{
out.println("Program has started...");
double a = 0.1D;
double b = 0.1D;
double c = a*b;
out.println();
out.println(c);
float d = 0.1F;
float e = 0.1F;
float f = d*e;
out.println();
out.println(f);
out.println();
out.println("Program has Finished.");
}}
/*
Program has started...

0.010000000000000002

0.010000001

Program has Finished.*/
//----------------------------------------------------------**

The first fragment runs on 64 bit Windows 10, and compiles by the Twilight Dragon Media C++ compiler (available for Windows from https://jmeubank.github.io/tdm-gcc/download/ ). Similar GNU C++ compilers are available for the Mac, Unix, Linux, and others, for free, with availability to their source code too.

The first code fragment from above is an example of accurate ranged floating arithmetic, which can be accomplished quickly, available from Free, Open Source Software. Something like this can be even more easily accomplished in Java by refactoring the former into the OpenJDK.

While Java has comparators ==, !=, >,<,>=,<= immediately working on float and double (which C++ hasn't), C++ does have
range accurate, base 10 decimal floating point arithmetic on its float, double, long float, long double types. This combines with the C++ code fragment included above to provide a case model for both what is possible, and as a starting point for where bases for extant code resources may be found.

C++ taps into SSE, or equivalent, additional hardware bit registers, with updated arithmetic implementation code, to deal with straddling decimal to binary carries past the range end of floating point type, so that the final base 10 digit calculated to-and-fro in relation to binary, is considered properly and placed properly.

The concern has been that repairing this will generate some kind of incompatability for Java. This concern simply doesn't ultimately make any sense, since floating point denormal or pronormal values are only ever innaccurate, and operate at similar speeds to SSE oriented correction anyway. They cannot be specifically needed for anything, and correcting them in place will only lead to advantage, certainly at the same speeds anyway.

Correction could be implemented by altering the default operation behaviour of the runtime. However, if compatability is of greater concern, something like a main method annotation and similar annotations for Threads and Runnables can be included, that the compiler detects, causing it to compile in a bit for that code space, switching, therein, to the floating point arithmetic/StrictMath behaviour required therein. This might even allow both modes to interact together, if done carefully enough.

Given all these things, is it possible for the Java Community Process to consider these matters in these sorts of terms, and implement in-place removal of floating point denormal and pronormal values (utilising SSE equivalent hardware registers and refactoring of available faster code), with an improved StrictMath in some manner?

So that all Java programmers can develop their software in a more straightforward and efficient manner, even along any of these paths?

Many thanks,

Sergio Minervini.

Sent with [ProtonMail](https://protonmail.com/) secure email.

From vromero at openjdk.java.net  Fri Apr 15 03:56:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 03:56:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
 <wcUy3a_vA3YqAq5bK1O_SwSX_GopTTF5RFJEdrzPdwc=.f7653bbe-7d47-4390-9817-84ab5bd22840@github.com>
Message-ID: <oEN8DKXMf49vZ2Iwxvrf-YvsF9gdEtqqHbn59hByON0=.9b020f80-1c50-4715-8448-d802e9a3b662@github.com>

On Thu, 14 Apr 2022 08:46:50 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1377:
> 
>> 1375:         }
>> 1376:         JCExpression guard = ((JCPattern) cse).guard;
>> 1377:         if (guard != null && guard.type.hasTag(BOOLEAN)) {
> 
> In the spec we see the following:
> 
>> A pattern case element is said to be unrefined if either (i) it has no associated when expression, or (ii) it has an associated when expression that is a constant expression ([15.29](https://docs.oracle.com/javase/specs/jls/se18/html/jls-15.html#jls-15.29)) with value true. A case element is unrefined if it is not a pattern case element or it is an unrefined pattern case element.
> 
> However, in the definition of `unconditional` I don't see the part for the constant expression.
> 
> I wonder if the spec should be updated or the code at this point

the code below checks that the guard is boolean constant `true`, this is the way the compiler can do that, a constant can be retrieved using the `constValue` method

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From zjx001202 at gmail.com  Fri Apr 15 05:37:03 2022
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 15 Apr 2022 13:37:03 +0800
Subject: OpenJDK or SE Java Floating Point Options?
In-Reply-To: <YwsPzgiMbmskjtJ6r2FJG8zFrPBqtvwcansnnEk2-Yo48d2RdDWmrzOk2mbRLubYrXC60vV8D43k4uALmx1yqT-TtKGIYJJdChrRTqNnrps=@protonmail.com>
References: <YwsPzgiMbmskjtJ6r2FJG8zFrPBqtvwcansnnEk2-Yo48d2RdDWmrzOk2mbRLubYrXC60vV8D43k4uALmx1yqT-TtKGIYJJdChrRTqNnrps=@protonmail.com>
Message-ID: <CAJL5A3nhQOjuH2kktQrEugqxgHHzM=HCH946XP02GZkmDmKmgg@mail.gmail.com>

Your code snippet C++ shows different results than Java, simply because
cout doesn't output full precision numbers.

To see accurate results in C++, add this line of code at the beginning of
the main function (need to import header file `iomanip`):

std::cout << std::setprecision(20);


After this, you can see the correct value of floating point numbers in C++.



On Fri, Apr 15, 2022 at 10:32 AM sminervini.prism <
sminervini.prism at protonmail.com> wrote:

> To core-libs-dev at openjdk.java.net,
>
> The Java OpenJDK, particularly the runtime, in its present state, has one
> key problem. Arithmetic performed by operators on number variables or data,
> of types float and double, are able to gain denormal or pronormal values,
> alongside method calls made on java.lang.StrictMath. This is is always
> quoted as being because of Java adherence to standard IEEE 754,
> which has a 2008 version, and also has a more recent but non-free paper
> released in 2019.
>
> Programmers need range accurate integer and decimal mathematics, in higher
> level computer languages such as Java, certainly higher level languages
> than Assembly or C. While Java does have a workaround approach to these
> floating point problems, involving BigDecimal and BigInteger, and another
> approach that supplies a calculator class, the big-math library,
>
> https://github.com/eobermuhlner/big-math ,
>
> using and rely on these stop-gap, work-around solutions is a poor
> approach, which can eventually become problematic. BigInteger and
> BigDecimal are larger in memory than needed, they are slower, messier in
> source code to program, debug, understand and edit, of themselves exclude
> access to operator syntax, and also are never reified with Java official
> library classes or interfaces.
>
> The standard document IEEE 754, with its capitulation of floating point
> arithmetic, mentions traps, state exceptions and flags, phenomena that as
> of OpenJDK 17 Java has not adopted. It has been the view that because 754
> doesn't stipulate what happens with underflow or overflow specifically, nor
> does it stipulate that it is a base 10 system on top of a binary one
> exactly, that therefore, because of this, underflow and overflow aren't
> (and can't be) bugs or software logic errors, by "definition of IEEE 754".
>
> It has been this which has lead to the rejection of a series of related
> bug requests on the Java online bug database submission system to simply be
> denied.
>
> The original justification for floating point denormal and pronormals is a
> view which wants to compromise digit place accuracy for speed. This is
> diametrically fused with a more important view that must have all accurate
> digit places for full range accuracy, because that is simply required by
> some technical task that the language is designed for and supported to
> perform. However, in modern times it has become the case that this
> compromise isn't needed any more, since accuracy can dovetail with speed,
> given modern hardware evolution, in the shape of the SSE phenomenon and
> similar.
>
> Since 754 is not stated to be either a base 10 or base 2 system, therefore
> from base 10's point of view, it could be either.
>
> Binary numbers and their arithmetic are for the sake of machines. Decimal
> mathematics is for the sake of human beings.
> Given this, it makes things the case that IEEE 754 is incomplete, leading
> to inconsistency and finally incoherency. These mean that 754 has a "blind
> spot" which does lead to logic errors.
>
> This state of affairs has made original floating point correction, at the
> level of the original operator and StrictMath method call level, within the
> Java ubiquity itself, both pertinent and critical.
>
> Notwistanding calculator classes and comparisons, consider the following
> two code fragments:
>
> //----------------------------------------------------------
> //The C++ Language. Arithmetic only, no comparisons.
>
> #include
>
> using namespace std;
>
> int main()
> {
> cout << "Program has started..." << endl;
> double a = 0.1D;
> double b = 0.1D;
> double c = a*b;
> cout << endl << c << endl << endl;
> float d = 0.1F;
> float e = 0.1F;
> float f = d*e;
> cout << f << endl << endl;
> cout << "Program has Finished.";
> return 0;
> }
>
> /*
> Program has started...
>
> 0.01
>
> 0.01
>
> Program has Finished.*/
>
> //----------------------------------------------------------
> //The Java Language. Arithmetic only, no comparisons.
>
> import static java.lang.System.*;
> public class Start
> {
> public static void main(String ... args)
> {
> out.println("Program has started...");
> double a = 0.1D;
> double b = 0.1D;
> double c = a*b;
> out.println();
> out.println(c);
> float d = 0.1F;
> float e = 0.1F;
> float f = d*e;
> out.println();
> out.println(f);
> out.println();
> out.println("Program has Finished.");
> }}
> /*
> Program has started...
>
> 0.010000000000000002
>
> 0.010000001
>
> Program has Finished.*/
> //----------------------------------------------------------**
>
> The first fragment runs on 64 bit Windows 10, and compiles by the Twilight
> Dragon Media C++ compiler (available for Windows from
> https://jmeubank.github.io/tdm-gcc/download/ ). Similar GNU C++ compilers
> are available for the Mac, Unix, Linux, and others, for free, with
> availability to their source code too.
>
> The first code fragment from above is an example of accurate ranged
> floating arithmetic, which can be accomplished quickly, available from
> Free, Open Source Software. Something like this can be even more easily
> accomplished in Java by refactoring the former into the OpenJDK.
>
> While Java has comparators ==, !=, >,<,>=,<= immediately working on float
> and double (which C++ hasn't), C++ does have
> range accurate, base 10 decimal floating point arithmetic on its float,
> double, long float, long double types. This combines with the C++ code
> fragment included above to provide a case model for both what is possible,
> and as a starting point for where bases for extant code resources may be
> found.
>
> C++ taps into SSE, or equivalent, additional hardware bit registers, with
> updated arithmetic implementation code, to deal with straddling decimal to
> binary carries past the range end of floating point type, so that the final
> base 10 digit calculated to-and-fro in relation to binary, is considered
> properly and placed properly.
>
> The concern has been that repairing this will generate some kind of
> incompatability for Java. This concern simply doesn't ultimately make any
> sense, since floating point denormal or pronormal values are only ever
> innaccurate, and operate at similar speeds to SSE oriented correction
> anyway. They cannot be specifically needed for anything, and correcting
> them in place will only lead to advantage, certainly at the same speeds
> anyway.
>
> Correction could be implemented by altering the default operation
> behaviour of the runtime. However, if compatability is of greater concern,
> something like a main method annotation and similar annotations for Threads
> and Runnables can be included, that the compiler detects, causing it to
> compile in a bit for that code space, switching, therein, to the floating
> point arithmetic/StrictMath behaviour required therein. This might even
> allow both modes to interact together, if done carefully enough.
>
> Given all these things, is it possible for the Java Community Process to
> consider these matters in these sorts of terms, and implement in-place
> removal of floating point denormal and pronormal values (utilising SSE
> equivalent hardware registers and refactoring of available faster code),
> with an improved StrictMath in some manner?
>
> So that all Java programmers can develop their software in a more
> straightforward and efficient manner, even along any of these paths?
>
> Many thanks,
>
> Sergio Minervini.
>
> Sent with [ProtonMail](https://protonmail.com/) secure email.

From duke at openjdk.java.net  Fri Apr 15 06:07:11 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 15 Apr 2022 06:07:11 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
Message-ID: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>

Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods to mention such behavior.

-------------

Commit messages:
 - Fix indent
 - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

Changes: https://git.openjdk.java.net/jdk/pull/8259/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8259&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8178355
  Stats: 165 lines in 2 files changed: 132 ins; 32 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.java.net/jdk/pull/8259

From aturbanov at openjdk.java.net  Fri Apr 15 08:14:39 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 15 Apr 2022 08:14:39 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <Fl18aNG5VRm9cKAGACvisoCc6A_t-Vgy03p-ldK9_2A=.3cd9f6fc-4e51-4916-836b-6bcf4088bda1@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

Shouldn't copyright year be updated too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From stuefe at openjdk.java.net  Fri Apr 15 09:11:42 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 15 Apr 2022 09:11:42 GMT
Subject: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem [v3]
In-Reply-To: <SF-JRSPe_Hk8O_VqWH7aPbmp9YIIQd6kcj7sYdrFbzk=.2f8d57d4-d2aa-4478-86fc-c0cd98e86d62@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
 <SF-JRSPe_Hk8O_VqWH7aPbmp9YIIQd6kcj7sYdrFbzk=.2f8d57d4-d2aa-4478-86fc-c0cd98e86d62@github.com>
Message-ID: <s9OKjs95afxBZNiOZMIBQ5Bllgdv1zsiCoEIMxoJBvo=.9ef6127b-26f9-4e0d-a53f-c66e5de2e47b@github.com>

On Thu, 14 Apr 2022 18:29:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
>> 
>> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

Thanks Roger!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8240

From stuefe at openjdk.java.net  Fri Apr 15 09:11:42 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 15 Apr 2022 09:11:42 GMT
Subject: Integrated: JDK-8284874: Add comment to ProcessHandle/OnExitTest to
 describe zombie problem
In-Reply-To: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
References: <nFqsWEqUhXxr5Pc5g_isJdzodT6TyIEv1Y4TVQ-iU1E=.23193d6b-d205-43d3-9002-77f52a029305@github.com>
Message-ID: <njmxfBzZPEsevQEVivJYij0HAMRsWf20T0DZFxAMfGc=.de7ab0e9-518c-4977-bf97-154da8adaf99@github.com>

On Thu, 14 Apr 2022 09:32:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not reap zombies in a timely fashion. [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this problem in detail.
> 
> Until we figure out a way to fix that (if at all - see comments in JBS), let us have a clarifying comment in the test itself.

This pull request has now been integrated.

Changeset: bb7c97bd
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb7c97bddfe88cb3261706f5e272fd0418e5238c
Stats:     19 lines in 1 file changed: 18 ins; 0 del; 1 mod

8284874: Add comment to ProcessHandle/OnExitTest to describe zombie problem

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8240

From alanb at openjdk.java.net  Fri Apr 15 11:45:01 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Apr 2022 11:45:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Refresh
 - Refresh
 - Merge with jdk-19+18
 - Refresh
 - Initial push

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/0e12c206..f53f0d4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01-02

  Stats: 148912 lines in 1502 files changed: 104901 ins; 9917 del; 34094 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From prappo at openjdk.java.net  Fri Apr 15 11:46:44 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 15 Apr 2022 11:46:44 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

src/java.base/share/legal/icu.md line 310:

> 308:  #  list of conditions and the following disclaimer. Redistributions in binary
> 309:  #  form must reproduce the above copyright notice, this list of conditions and
> 310:  #  the following disclaimer in the documentation and/or the materials

I think it's a mistype of "other", not "the"; look at the similar text below.

src/java.base/share/native/libzip/zlib/ChangeLog line 99:

> 97: - Simplify contrib/vstudio/vc10 with 'd' suffix
> 98: - Add TOP support to win32/Makefile.msc
> 99: - Support i686 and amd64 assembler builds in CMakeLists.txt

Similarly to Naoto's comment on ICU: shouldn't we leave this as is? If anybody cares enough about this typo, they could file a bug against zlib directly.

src/java.base/share/native/libzip/zlib/README line 67:

> 65:   when compiled with cc.
> 66: 
> 67: - On Digital Unix 4.0D (formerly OSF/1) on AlphaServer, the cc option -std1 is

Same as above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From prappo at openjdk.java.net  Fri Apr 15 11:50:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 15 Apr 2022 11:50:39 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com>
Message-ID: <qUHWJF3Dg8BdfFfvpseQQyeet39jHLOidPEfGmOD-Kg=.9a5211d7-adc3-4229-bfe4-d42e9fc4ac99@github.com>

On Fri, 15 Apr 2022 11:25:09 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> src/java.base/share/legal/icu.md line 310:
> 
>> 308:  #  list of conditions and the following disclaimer. Redistributions in binary
>> 309:  #  form must reproduce the above copyright notice, this list of conditions and
>> 310:  #  the following disclaimer in the documentation and/or the materials
> 
> I think it's a mistype of "other", not "the"; look at the similar text below.

Should be addressed on the ICU side.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From aturbanov at openjdk.java.net  Fri Apr 15 12:34:47 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 15 Apr 2022 12:34:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <pfPj-EfIX1kjcN0wNk1H27D8xTb3nYE6rItotBHpP_0=.83e1f64a-b0ad-498e-a024-c958f7ccaeed@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java line 29:

> 27: 
> 28: public interface JavaUtilConcurrentTLRAccess {
> 29:     int nextSecondaryThreadLocalRandomSeed();

method seems unused now

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri Apr 15 13:01:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Apr 2022 13:01:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <dcCZ3cRzLKnKAn_8Wc7gw-_9aXlP3cGzA0TodgM95YY=.6c184371-b9bd-4729-9e06-5a234cd91567@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <dcCZ3cRzLKnKAn_8Wc7gw-_9aXlP3cGzA0TodgM95YY=.6c184371-b9bd-4729-9e06-5a234cd91567@github.com>
Message-ID: <6wPsXjV1MP9Q86NWt2YOWecuHH0EXJwVjmPdA_baDFM=.56c7d00d-8169-4311-9d34-ac43e4ce64d0@github.com>

On Thu, 14 Apr 2022 21:39:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/java/lang/Thread.java line 862:
> 
>> 860:          * @param start the starting value of the counter
>> 861:          * @return this builder
>> 862:          * @throws IllegalArgumentException if count is negative
> 
> Suggestion:
> 
>          * @throws IllegalArgumentException if start is negative

Thanks, I think that dates from when the param was renamed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 65:
> 
>> 63:  * system.
>> 64:  */
>> 65: class VirtualThread extends Thread {
> 
> Suggestion:
> 
> final class VirtualThread extends Thread {

okay.

> src/java.base/share/classes/java/lang/VirtualThread.java line 94:
> 
>> 92:      *  RUNNING -> PARKING         // Thread attempts to park
>> 93:      *  PARKING -> PARKED          // yield successful, thread is parked
>> 94:      *  PARKING -> PINNED          // yield failed, thread is pinned
> 
> Suggestion:
> 
>      *  PARKING -> PARKED          // parking successful, thread is parked
>      *  PARKING -> PINNED          // parking failed, thread is pinned

The comment was about cont.yield, will change it to make it clearer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri Apr 15 13:01:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Apr 2022 13:01:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <pfPj-EfIX1kjcN0wNk1H27D8xTb3nYE6rItotBHpP_0=.83e1f64a-b0ad-498e-a024-c958f7ccaeed@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <pfPj-EfIX1kjcN0wNk1H27D8xTb3nYE6rItotBHpP_0=.83e1f64a-b0ad-498e-a024-c958f7ccaeed@github.com>
Message-ID: <eBtZj6KA2IdZBO9K8UZy-K5b7Ce4OdeY4KhqTAXLWUQ=.28853309-2a85-4b69-9719-0a852033cc0e@github.com>

On Fri, 15 Apr 2022 12:31:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> method seems unused now

It's used by the SL API, which will follow later. I realize this may sound complicated but it avoids more complicated splits.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri Apr 15 13:09:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Apr 2022 13:09:39 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <Xs8LwVblb5dZlApSM44w0k4HSyrobuaS5Zl-RNJwyvw=.923a6fc4-edbc-4ecf-9726-cecd4e1edfaf@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

I skimmed through the changes to src/java.base and they look okay except for the changes to 3rd party code that I think should be dropped from this patch.

src/java.base/share/native/libzip/zlib/inftrees.h line 65:

> 63:    1444, which is the sum of 852 for literal/length codes and 592 for distance
> 64:    codes.  These values were found by exhaustive searches using the program
> 65:    examples/enough.c found in the zlib distribution.  The arguments to that

This is 3rd party code so should be dropped from the patch as we want as few changes to this code has possible.

src/java.base/windows/native/libnio/ch/wepoll.c line 894:

> 892:      * error code when the once-callback returns FALSE. We return -1 here to
> 893:      * indicate that global initialization failed; the failing init function is
> 894:      * responsible for setting `errno` and calling `SetLastError()`. */

This is also 3rd party code so should be dropped from this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From alanb at openjdk.java.net  Fri Apr 15 13:24:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Apr 2022 13:24:51 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v5]
In-Reply-To: <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
Message-ID: <oGDgZDuFnGO63NcWd-Padt8u8xbU9yI9lE5_mShTeF0=.7f4ebafe-e777-46e9-b656-aa83b88bab58@github.com>

On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked 
>> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766)
>> 
>> We found the issue can be produced stably with at least 64 modules.
>> Note that we need to add the --date jmod option to avoid the timestamp issue.
>> 
>> Testing:
>> Added test case fails without fix for JDK-8240734, and passes otherwise.
>> Tested with tier2 on linux x86.
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8240903
>  - Delete extra blank links
>  - Change shell test io java test
>  - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z'
>  - Update Copyright
>  - 8240903: Add a regression test for JDK-8240734

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From duke at openjdk.java.net  Fri Apr 15 13:47:40 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 15 Apr 2022 13:47:40 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <uksHJqxb2IOTEeiGv1bGVuYlR1vpYwchxNpPKsxnIMA=.a4c5938e-457f-4238-9962-634abcc6a9d0@github.com>
 <zfQQvk5LZ4fCIfoIZFBUjBcvPX2J6_Pa4A1KjGe2nhg=.29b270d9-3599-4f82-a69b-fc7dd3210d4f@github.com>
Message-ID: <QSBRL0wFUJe_ClWr0TOwOMqi-JpvGCbsGgmFkt-MdzE=.34d57b2f-9e6f-430e-9e55-c798aa8cedf8@github.com>

On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance and if a non-null instance is used to get a non-null class they are PROBABLY the same but it is far from clear. The implementations of both are at least native and may be instrinsicified. The doc for Class.isAssignableFrom cites JLS 5.1.4 which in what I found is about primitives so I suspect it is woefully out of date 
>> https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4
>> 
>> What client tests have you run that touch the code you are changing ?
>> 
>> In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it.
>
>>In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it.
> 
> I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_ operator. And `isInstance` method javadoc is very straight forward: `This method is the dynamic equivalent of the Java language instanceof operator.`
> 
> Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that:
> 1. [Wrong isAssignableFrom test when adding Principal to Subject ](https://bugs.openjdk.java.net/browse/JDK-8034820)
> 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8254717)
> 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800)
> 
> So, it gives all 3 points to prefer isInstance method: it's shorter, it's clearer for most java developers, it's faster.

> @turbanoff
> > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that:
> 
> Maybe we should add `Class::isSubclassOf(Class<?> that)` that performs `that.isAssignableFrom(this)`:

I?have?opened [JI?9073064](https://bugs.openjdk.java.net/browse/JI-9073064 "[JI?9073064] Add?the?method `Class::isSublassOf(Class<?>)` to?`java.lang.Class` that?does the?inverse of?`Class::isAssignableFrom`") for?this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From duke at openjdk.java.net  Fri Apr 15 13:56:56 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 15 Apr 2022 13:56:56 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <CJyVBZkB0vWIZe60e7e1x5y5Tq745EpgZT0q9jJ6A0g=.4e386a1d-feaf-45b8-82cb-e4ed59546177@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

test/jdk/java/util/IdentityHashMap/DefaultRemoveReplace.java line 36:

> 34:         final String key = "key";
> 35:         final String internedValue = "value";
> 36:         final String constructedValue = new String(new char[]{'v', 'a', 'l', 'u', 'e'});

Using:
Suggestion:

        final String constructedValue = new String(internedValue);

will?allow the?internal `String.value`?array to?be?shared: <https://github.com/openjdk/jdk/blob/bdf8a2a2050393e91800786f8d5a5d6805f936eb/src/java.base/share/classes/java/lang/String.java#L259-L265>

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From duke at openjdk.java.net  Fri Apr 15 14:10:40 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 15 Apr 2022 14:10:40 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <CJyVBZkB0vWIZe60e7e1x5y5Tq745EpgZT0q9jJ6A0g=.4e386a1d-feaf-45b8-82cb-e4ed59546177@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <CJyVBZkB0vWIZe60e7e1x5y5Tq745EpgZT0q9jJ6A0g=.4e386a1d-feaf-45b8-82cb-e4ed59546177@github.com>
Message-ID: <FjTP1syCTBbQMvqP6GJshTGSxStk668ts_AGDu6ZYA8=.3d9bbd81-5614-40e8-8901-4095f088085c@github.com>

On Fri, 15 Apr 2022 13:53:59 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> test/jdk/java/util/IdentityHashMap/DefaultRemoveReplace.java line 36:
> 
>> 34:         final String key = "key";
>> 35:         final String internedValue = "value";
>> 36:         final String constructedValue = new String(new char[]{'v', 'a', 'l', 'u', 'e'});
> 
> Using:
> Suggestion:
> 
>         final String constructedValue = new String(internedValue);
> 
> will?allow the?internal `String.value`?array to?be?shared: <https://github.com/openjdk/jdk/blob/bdf8a2a2050393e91800786f8d5a5d6805f936eb/src/java.base/share/classes/java/lang/String.java#L259-L265>

I know. This is just to get rid of intellij idea's warning.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From tvaleev at openjdk.java.net  Fri Apr 15 15:21:49 2022
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Fri, 15 Apr 2022 15:21:49 GMT
Subject: Integrated: 8280915: Better parallelization for AbstractSpliterator
 and IteratorSpliterator when size is unknown
In-Reply-To: <ACrivRBSVWKN3Bj8nEdHL0veR6cRyU8ElDfNwB5P55A=.31830fd1-2c64-44c2-bcbc-26e5180faf08@github.com>
References: <ACrivRBSVWKN3Bj8nEdHL0veR6cRyU8ElDfNwB5P55A=.31830fd1-2c64-44c2-bcbc-26e5180faf08@github.com>
Message-ID: <aG-xGVLe9IqWNwkh5vSY79mq3nnkBpEn8y1ZGbnkLew=.2bba1618-d334-4393-acb7-494b7e211b8b@github.com>

On Sat, 29 Jan 2022 16:31:43 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> See the bug description for details.
> 
> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable.
> 
> No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes.
> 
> I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome.

This pull request has now been integrated.

Changeset: 4cc8eccf
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4cc8eccfcadf5d3edc31809ead2dd6554c7cca4b
Stats:     212 lines in 3 files changed: 178 ins; 0 del; 34 mod

8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/7279

From vromero at openjdk.java.net  Fri Apr 15 15:40:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 15:40:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1779:

> 1777:                         //binding pattern
> 1778:                         attribExpr(pat, switchEnv);
> 1779:                         var primary = TreeInfo.primaryPatternType(pat);

general comment: the handleSwitch method is getting more and more complex, please consider refactoring it, probably splitting it, for example different subrutines handling different case kinds. Of course this probably should be done as a separate effort.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From mcimadamore at openjdk.java.net  Fri Apr 15 16:06:40 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 15 Apr 2022 16:06:40 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <itlvM9hgIlX8qMNe2ZeH_FNryI_UZRekfpmMXApdoLo=.79784ddc-d45f-43e6-ae49-13f66d814714@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

Looks good - I like how moving the guard from pattern to an expression inside a switch made the code simpler to reason about, and also simplified the compiler API. I left some comments in the javadoc of MatchException.

src/java.base/share/classes/java/lang/MatchException.java line 33:

> 31:  * Thrown to indicate an unexpected failure in pattern matching.
> 32:  *
> 33:  * MatchException may be thrown when an exhaustive pattern matching language construct

Maybe wrap with `{@code}`

src/java.base/share/classes/java/lang/MatchException.java line 34:

> 32:  *
> 33:  * MatchException may be thrown when an exhaustive pattern matching language construct
> 34:  * (such as a switch expression) encounters a match target that does not match any of the provided

Is the term "match target" defined somewhere? In general, it would be good quoting relevant sections of the JLS, and using consistent terminology

src/java.base/share/classes/java/lang/MatchException.java line 37:

> 35:  * patterns at runtime.  This can currently arise from the following case:
> 36:  * <ul>
> 37:  *     <li>Separate compilation anomalies, where a sealed interface has a different

Why a list if there's only one case? I know we have plans to expand this to cover nulls in records patterns, but right now the javadoc should stand on its own

src/java.base/share/classes/java/lang/MatchException.java line 52:

> 50: 
> 51:     /**
> 52:      * Constructs an {@code MatchException} with no detail  message.

double space before "message" ?

src/java.base/share/classes/java/lang/MatchException.java line 73:

> 71:      *
> 72:      * @param  cause the cause (which is saved for later retrieval by the
> 73:      *         {@link #getCause()} method).  (A {@code null} value is

double space before "(A" ?

src/java.base/share/classes/java/lang/MatchException.java line 88:

> 86:      *         by the {@link #getMessage()} method).
> 87:      * @param  cause the cause (which is saved for later retrieval by the
> 88:      *         {@link #getCause()} method).  (A {@code null} value is

Same here, double space before "(A"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From vromero at openjdk.java.net  Fri Apr 15 16:16:42 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 15 Apr 2022 16:16:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <MBjkwo2rOCJRGMm1xXhCBIDCFWCYjXhklP2-5BFg0-k=.e996902b-b0ef-4bf9-bf84-30ac5d3deb39@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

the patch doesn't apply cleanly on the master repo probably need to rebase?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From mullan at openjdk.java.net  Fri Apr 15 18:12:51 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 15 Apr 2022 18:12:51 GMT
Subject: RFR: 8284893: Fix typos in java.base
In-Reply-To: <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com>
Message-ID: <Hnxzc6MuUa2NQnC_5GhyuBC74GrmBvUj7cygTZ4KDSA=.7dcb4e13-e5e9-4341-a799-8e5adc4d1cfe@github.com>

On Thu, 14 Apr 2022 20:16:21 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java line 128:
> 
>> 126:         // Each time this method is called, we're examining a new list
>> 127:         // from the global list. So, we have to start by getting the list
>> 128:         // that contains the set of Vertices we're considering.
> 
> The class being affected is a Vertex, so either change to vertices, or leave as is...

Agree, suggest changing it to "vertices".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From naoto at openjdk.java.net  Fri Apr 15 18:47:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 15 Apr 2022 18:47:53 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v7]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <DAln8lPtjwxh9fev8Uos8tRfH9r9DY3-wZGs_WtRDMk=.a280b9d7-0536-44ff-9baa-c3f0a6badbb4@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Revert to use the default method
 - Merge branch 'master' into JDK-8279185
 - Removed unnecessary package names
 - Modified class desc of `IsoFields`
 - abstract class -> top level interface
 - interface -> abstract class
 - Merge branch 'master' into JDK-8279185
 - Removed the method
 - Merge branch 'master' into JDK-8279185
 - Changed to use a type to determine ISO based or not
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/0cddf702...82339ec6

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/474dc85a..82339ec6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=05-06

  Stats: 13771 lines in 299 files changed: 10278 ins; 2309 del; 1184 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From duke at openjdk.java.net  Fri Apr 15 18:56:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 15 Apr 2022 18:56:37 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  change to liach operation.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/1f6e0eb7..9854f523

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=05-06

  Stats: 22 lines in 2 files changed: 14 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From prappo at openjdk.java.net  Fri Apr 15 19:42:09 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 15 Apr 2022 19:42:09 GMT
Subject: RFR: 8284922: Fix some doc-comment issues on methods with package
 access in JDK API
Message-ID: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>

People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed.

There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones.

-------------

Commit messages:
 - Update copyright years
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8267/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8267&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284922
  Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8267.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8267/head:pull/8267

PR: https://git.openjdk.java.net/jdk/pull/8267

From darcy at openjdk.java.net  Fri Apr 15 19:47:34 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 15 Apr 2022 19:47:34 GMT
Subject: RFR: 8284922: Fix some doc-comment issues on methods with package
 access in JDK API
In-Reply-To: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
References: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
Message-ID: <BRy0rm6KZs3QsMaTksGoTOjqJAtTbjc5XKZD8yPv9fs=.401ac88b-bce6-43ad-95e0-7ab1db72736f@github.com>

On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed.
> 
> There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones.

Looks fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8267

From iris at openjdk.java.net  Fri Apr 15 19:57:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 15 Apr 2022 19:57:50 GMT
Subject: RFR: 8284922: Fix some doc-comment issues on methods with package
 access in JDK API
In-Reply-To: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
References: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
Message-ID: <lKhHpzSjedjhYmHBIiwgWVS0HiKAY0huczIMJa32b1A=.d8b729f4-38ef-4db8-8b59-4e308a5875aa@github.com>

On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed.
> 
> There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8267

From bpb at openjdk.java.net  Fri Apr 15 20:13:40 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 15 Apr 2022 20:13:40 GMT
Subject: RFR: 8284922: Fix some doc-comment issues on methods with package
 access in JDK API
In-Reply-To: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
References: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
Message-ID: <uP2JLV4BTMMJqJ0R2utOcUMpsDsHlWIRYNASM97ZStY=.f428e1b4-73be-4eba-92bb-cbd2ea9f17e8@github.com>

On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed.
> 
> There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8267

From psandoz at openjdk.java.net  Fri Apr 15 20:43:57 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 20:43:57 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 118:

> 116:         static long beginCompensatedBlock(ForkJoinPool pool) {
> 117:             try {
> 118:                 return (long) beginCompensatedBlock.invoke(pool);

Suggestion:

                return (long) beginCompensatedBlock.invokeExact(pool);

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126:

> 124:         static void endCompensatedBlock(ForkJoinPool pool, long post) {
> 125:             try {
> 126:                 endCompensatedBlock.invoke(pool, post);

Suggestion:

                endCompensatedBlock.invokeExact(pool, post);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 20:54:41 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 20:54:41 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <ryqGxIdwh5_qUsB8vOjPPI3a7u4FYVXZko-YOLQPZCY=.ce98aec7-f46e-4e1d-a5ba-764c8331ebf2@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46:

> 44:         } else {
> 45:             CAN_USE_INTERNAL_LOCK = true;
> 46:         }

Suggestion:

        CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors");

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:04:54 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:04:54 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <FjBOyjitjZJbwJchp9pq3gY2H6VWw1svnQgmliWP6BE=.e9daf16b-68dc-4b2e-88cd-a45657a9a9ef@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262:

> 260:      * @return the thread, started
> 261:      * @throws IllegalStateException if this flock is shutdown or closed
> 262:      * @throws jdk.incubator.concurrent.StructureViolationException if the current

Suggestion:

     * @throws WrongThreadException if the current thread is not the owner or a thread
     * contained in the flock
     * @throws jdk.incubator.concurrent.StructureViolationException if the current

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:14:56 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:14:56 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <jeMJOflU4m7ar7lxkyqvkZa1vAF_9XivzrPQIyEvjKU=.d3f4126a-b919-42e8-b724-b31e462aeb42@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59:

> 57:                     && this.thread == other.thread;
> 58:         }
> 59:     }

Suggestion:

    private record ThreadRef(Thread thread) {
        @Override
        public int hashCode() {
            return Long.hashCode(thread.threadId());
        }

        @Override
        public boolean equals(Object obj) {
            return (obj instanceof ThreadRef other)
                    && this.thread == other.thread;
        }
    }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:18:52 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:18:52 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <XNFvRMNTy1RRnoitO1ZQnhzQdgDo2oNiJqVB0HBufo8=.28d65b88-05cd-40c2-b516-39d25a760447@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94:

> 92:             default:
> 93:                 throw new AssertionError("Unknown pinned reason: " + reason);
> 94:         }

Suggestion:

        return switch (reason) {
            case 2 -> Pinned.CRITICAL_SECTION;
            case 3 -> Pinned.NATIVE;
            case 4 -> Pinned.MONITOR;
            default -> throw new AssertionError("Unknown pinned reason: " + reason);
        };

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:28:39 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:28:39 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <a70SeaAKRSbibMp2-CSoHf1vNGAHc3b1ZQgS6xBOaVA=.f9e587c4-f01e-47f4-bc6b-0357a21b57a8@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115:

> 113:     }
> 114: 
> 115:     private Runnable target;

Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:34:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:34:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <oo_Mx37iKBdjBEb6AoqJAckrHNmsG7kRGpXi8EhfsQ0=.db91f2a3-4f94-42fb-a3da-2f5038282136@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264:

> 262:             } finally {
> 263:                 fence();
> 264:                 StackChunk c = tail;

`c` is not used

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 310:

> 308: 
> 309:     @IntrinsicCandidate
> 310:     private static int doYield() { throw new Error("Intrinsic not installed"); };

Suggestion:

    private static int doYield() { throw new Error("Intrinsic not installed"); }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 21:39:41 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 21:39:41 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <a1zwEEy2RutQNC0Q0M4jT-DdvVyVb-wFE2EOl6xTOU4=.d2974c37-2ac3-42c7-97f5-8ad2abd0e8aa@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 474:

> 472:     private void processNmethods(int before, int after) {
> 473: 
> 474:     }

Unused field and method?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Fri Apr 15 22:03:37 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 15 Apr 2022 22:03:37 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <HhAOfPXwbrCbH6QmzVxsH1jcxBLWplHew8DXEDAnuLs=.33ea6288-f2b2-4423-986c-2da5b1337563@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

`java.lang.MatchException` should?probably also?be?thrown by?non?`enum` enhanced?`switch`?statements[^1], to?match non?`enum` `switch`?expressions[^2].

[^1]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-14.11.3
[^2]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-15.28.2

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From psandoz at openjdk.java.net  Fri Apr 15 22:04:42 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 22:04:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <FbKKiFJlfMTc51D3eq6oc7953FvvjMPXzIOVVxxT6ho=.c131abf0-5354-476f-a453-e351ef1829f4@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184:

> 182:      * with the Thread API.
> 183:      */
> 184:     private static class RootContainer extends ThreadContainer {

This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based  on the system property. Something to consider later perhaps.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Fri Apr 15 22:13:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 15 Apr 2022 22:13:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <YFx2MUpHuZNnEp-f-WHjr9b2QykMR7dOzZE1HchbNfY=.e75d4108-4e4c-448a-8c40-b5f91eab80e3@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35:

> 33:  * disables inlining for the method to which it is applied unless the
> 34:  * method being unlined into is also annotated ChangesCurrentThread.
> 35: 

Suggestion:

 * method being inlined into is also annotated ChangesCurrentThread.
 *

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From dongbohe at openjdk.java.net  Sat Apr 16 01:14:33 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Sat, 16 Apr 2022 01:14:33 GMT
Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible
 [v5]
In-Reply-To: <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
 <iKABUFb0DBPBGIWWsBEbYJmgP13tZiMXQum9-LGx1TM=.c2b23a75-3eb4-4d61-97d5-223e3d35ab7b@github.com>
Message-ID: <wOouAcsGsknrkruKOKQfHJ1x63pp7fPuUitQ4kc5MmA=.d017be29-dc29-4277-94f1-5ac53b39c090@github.com>

On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked 
>> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766)
>> 
>> We found the issue can be produced stably with at least 64 modules.
>> Note that we need to add the --date jmod option to avoid the timestamp issue.
>> 
>> Testing:
>> Added test case fails without fix for JDK-8240734, and passes otherwise.
>> Tested with tier2 on linux x86.
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8240903
>  - Delete extra blank links
>  - Change shell test io java test
>  - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z'
>  - Update Copyright
>  - 8240903: Add a regression test for JDK-8240734

Thank you for your review, Alan.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From dongbohe at openjdk.java.net  Sat Apr 16 01:37:40 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Sat, 16 Apr 2022 01:37:40 GMT
Subject: Integrated: 8240903: Add test to check that jmod hashes are
 reproducible
In-Reply-To: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com>
Message-ID: <Tt-dbwCoWb2xlaHdShhxe3dnDIOniPqZ9mcWnEekw3Q=.c056e440-3a93-4d1d-9722-98485a46a348@github.com>

On Fri, 25 Mar 2022 01:50:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked 
> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766)
> 
> We found the issue can be produced stably with at least 64 modules.
> Note that we need to add the --date jmod option to avoid the timestamp issue.
> 
> Testing:
> Added test case fails without fix for JDK-8240734, and passes otherwise.
> Tested with tier2 on linux x86.

This pull request has now been integrated.

Changeset: 96952834
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9695283458c273c2a4121f88a2a971ad4f297d5b
Stats:     135 lines in 1 file changed: 135 ins; 0 del; 0 mod

8240903: Add test to check that jmod hashes are reproducible

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7948

From sminervini.prism at protonmail.com  Sat Apr 16 08:04:21 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Sat, 16 Apr 2022 08:04:21 +0000
Subject: OpenJDK or SE Java Floating Point Options?
Message-ID: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>

To core-libs-dev, and Glavo,

given this inner nature of C++, which I had not seen, I do renege those code snippets.

It is still the case that I and others need Java floating point and StrictMath
(the key double type calculator class) to be repaired.  It has been made clear to us by a number of publicly available sources,
irrespective of their age, from their date of publication and going forwards,
that with registry additions already present in Java relevant hardware, being SSE and beyond,
that repair can and must be wrought for Java float and double numeric types utilised in both Java SE and OpenJDK's
runtime environments.  This includes their present ranges, whenever arithmetic operations at all or
certain method calls involving them are made, where the results manage to straddle the edge of
those ranges.

float  from 1.40129846432481707e-45   to 3.40282346638528860e+38 (positive or negative).
double from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

As I attempted to submit in my previous  message to core-libs-dev, IEEE 754 is silent on pertinent matters
around decimal arithmetic, mainly certain end facts concluding that binary and decimal
use in computer software need to have objectivity. The proper precedent to draw from is not a
standard with a small "blind spot", but the phenomenon which simply states that both information and
behaviour can be encoded into a computer, so that such a machine can behave by means of that
information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans.

Range complete decimal mathematics is for humans, and binary mathematics is for computers.
Therefore, for a decimal result to have proper meaning, it must be entirely correct within
its (rational, truncated) range. The most efficient and only meaningful thing to do is to utilise
additional (SEE and similar) registers, with appropriate sub-java code, to use all registry
space, including the extra space if needed, to produce range accurate Java results
via improved operational logic.  It is known that having a little more registry space past
the number (result range) limit, for use and consideration, is the only range, base-10
perfect way to go.  It is certainly better than the available class approaches, which
waste memory, speed, and lack important and appropriate auxiliary use options.

In recent times, it has been the case that there are upstream and downstream vendors of
the OpenJDK.  Discussions with them have proven impossible, since all of them
only agree to conform and derive from whatever the OpenJDK and the JCP choose to do.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper workaround, and provide corrected,
defaulting or specifying-compatible waya for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without denormal and pronormal
inclusion?

> Message: 2
> Date: Fri, 15 Apr 2022 13:37:03 +0800
> From: Glavo zjx001202 at gmail.com
>
> To: "sminervini.prism" sminervini.prism at protonmail.com
>
> Cc: "core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net
>
> Subject: Re: OpenJDK or SE Java Floating Point Options?
> Message-ID:
> CAJL5A3nhQOjuH2kktQrEugqxgHHzM=HCH946XP02GZkmDmKmgg at mail.gmail.com
>
> Content-Type: text/plain; charset="UTF-8"
>
> Your code snippet C++ shows different results than Java, simply because
> cout doesn't output full precision numbers.
>
> To see accurate results in C++, add this line of code at the beginning of
> the main function (need to import header file `iomanip`):
>
> std::cout << std::setprecision(20);
>
>
> After this, you can see the correct value of floating point numbers in C++.


From aph-open at littlepinkcloud.com  Sat Apr 16 09:02:04 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sat, 16 Apr 2022 10:02:04 +0100
Subject: OpenJDK or SE Java Floating Point Options?
In-Reply-To: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>
References: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>
Message-ID: <511c266d-1962-1f41-08d4-60bc78db0825@littlepinkcloud.com>

On 4/16/22 09:04, sminervini.prism wrote:
 > It is still the case that I and others need Java floating point and StrictMath
 > (the key double type calculator class) to be repaired.

If you are going to pursue this line of reasoning, you must be aware
of some things.

Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

 > May the Java Community Process reconsider the present floating point
 > operations and method calls situation, based on an imperfect
 > standard and improper workaround, and provide corrected, defaulting
 > or specifying-compatible waya for Java floating point arithmetic and
 > Calculator class method results to always cohere in their ranges,
 > without denormal and pronormal inclusion?

In a word, no. That possibility is so unlikely that it is not worthy
of consideration.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jpai at openjdk.java.net  Sat Apr 16 09:28:42 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 16 Apr 2022 09:28:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <rH1-cueUsrxXuCOh6ZSJjsJkekBYRqBcf4Q8v6ykxaU=.7101d4f4-91bc-43b0-9338-24dc16b67a1a@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/io/BufferedOutputStream.java line 136:

> 134:      * are added. A no-op if the buffer is not resizable.
> 135:      */
> 136:     private void growIfNeeded(int len) {

Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sat Apr 16 10:26:42 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sat, 16 Apr 2022 10:26:42 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22]
In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
Message-ID: <Su-FDxO6tnvIGblNU6zite1n8kmMFNq7-Ixkmq4ZBG0=.42ddebc1-ac7d-46a2-8979-35f5936f864c@github.com>

On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.xml.crypto's usage downgrade grammar to 1.8

So is there any other things we should do before calling bot to integrate?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From jpai at openjdk.java.net  Sat Apr 16 10:32:42 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 16 Apr 2022 10:32:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76:

> 74:                 && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) {
> 75:             ct.beginBlocking();
> 76:             long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool());

It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`?

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94:

> 92: 
> 93:     /**
> 94:      * Marks the end an operation that may have blocked.

I think this should have been "Marks the end of an ..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sat Apr 16 11:09:36 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 16 Apr 2022 11:09:36 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <ANeA1O-SK9B1AxLb-LrcBG3L0HOk3qGVpbDzU5mTsE4=.b4386e74-c2be-4e7c-84a7-e91117507a37@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/io/FilterInputStream.java line 233:

> 231:      */
> 232:     @Override
> 233:     public void reset() throws IOException {

I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From dholmes at openjdk.java.net  Sat Apr 16 12:23:29 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 16 Apr 2022 12:23:29 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <E5q2OicRXTRU7t_MyGy3KzPLaRz_nPiul6kBW5mQ0vk=.d74d3691-bbff-44e0-a1bc-40269b5c5e1a@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

I don't this is the right "fix". There is a bit of a disconnect between the VM option and the system property. Although the default value of the VM flag is zero, that is ignored and the JDK side, not being directed otherwise, determines the max size. If you set the flag explicitly to zero that is passed through to the JDK and the max memory is actually set to zero.

I think this is more a documentation issue - MaxDirectMemory has no affect unless explicitly set on the command-line. The default value of the flag is actually irrelevant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From alanb at openjdk.java.net  Sat Apr 16 14:26:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 14:26:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com>
Message-ID: <vIufSvhkW252jd-2_LQ1ea-QCn0U3xx5alm1zhhKc88=.ce195e7b-d01d-44f3-bf55-3c88564b5148@github.com>

On Fri, 15 Apr 2022 20:39:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126:
> 
>> 124:         static void endCompensatedBlock(ForkJoinPool pool, long post) {
>> 125:             try {
>> 126:                 endCompensatedBlock.invoke(pool, post);
> 
> Suggestion:
> 
>                 endCompensatedBlock.invokeExact(pool, post);

Yes, that would be better.

> src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46:
> 
>> 44:         } else {
>> 45:             CAN_USE_INTERNAL_LOCK = true;
>> 46:         }
> 
> Suggestion:
> 
>         CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors");

This  doesn't work for the empty string case as it would map to true rather than false. So I think we leave this as is.

> src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262:
> 
>> 260:      * @return the thread, started
>> 261:      * @throws IllegalStateException if this flock is shutdown or closed
>> 262:      * @throws jdk.incubator.concurrent.StructureViolationException if the current
> 
> Suggestion:
> 
>      * @throws WrongThreadException if the current thread is not the owner or a thread
>      * contained in the flock
>      * @throws jdk.incubator.concurrent.StructureViolationException if the current

Thanks, I think this slipped in when moving the SL API to the incubator module. It should be IllegalThreadStateException if the thread has already started, and WrongThreadException if not the owner (or flock).

> src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59:
> 
>> 57:                     && this.thread == other.thread;
>> 58:         }
>> 59:     }
> 
> Suggestion:
> 
>     private record ThreadRef(Thread thread) {
>         @Override
>         public int hashCode() {
>             return Long.hashCode(thread.threadId());
>         }
> 
>         @Override
>         public boolean equals(Object obj) {
>             return (obj instanceof ThreadRef other)
>                     && this.thread == other.thread;
>         }
>     }

Yes, this can be a record.

> src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35:
> 
>> 33:  * disables inlining for the method to which it is applied unless the
>> 34:  * method being unlined into is also annotated ChangesCurrentThread.
>> 35: 
> 
> Suggestion:
> 
>  * method being inlined into is also annotated ChangesCurrentThread.
>  *

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 14:33:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 14:33:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>
Message-ID: <3DUMJmZ230xIecn-FP1iApMRFsr21tD2OGfZ-Sg2_Uc=.65d0cb79-e651-406c-aaa9-859937051963@github.com>

On Sat, 16 Apr 2022 10:29:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94:
> 
>> 92: 
>> 93:     /**
>> 94:      * Marks the end an operation that may have blocked.
> 
> I think this should have been "Marks the end of an ..."

Yes, there's a typo there - thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 14:37:44 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 14:37:44 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>
Message-ID: <jqmGeANQNCJgMkub8qag54uLniFm_SupjYv6Sbc-u_Q=.bee15c68-74b7-48e9-b3c8-733ccccbdf73@github.com>

On Sat, 16 Apr 2022 10:25:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76:
> 
>> 74:                 && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) {
>> 75:             ct.beginBlocking();
>> 76:             long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool());
> 
> It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`?

REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a corrects issue but we may be able to make this a bit more robust for these cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sat Apr 16 14:45:40 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Sat, 16 Apr 2022 14:45:40 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
Message-ID: <JgFnyYyVzBmyCeAq2qCs3hDZFznoFDMujGhcwiAmUrI=.253fb317-6cce-4874-852a-a2675de073a3@github.com>

On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111:

> 109:                 methodType = MethodType.methodType(void.class, long.class);
> 110:                 endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType);
> 111: 

This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`.

Suggestion:

                JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();
                MethodType methodType = MethodType.methodType(long.class);
                beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType);
                if (beginCompensatedBlock == null) {
                    throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType);
                }
                methodType = MethodType.methodType(void.class, long.class);
                endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType);
                if (endCompensatedBlock == null) {
                    throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType);
                }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 15:02:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 15:02:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <ANeA1O-SK9B1AxLb-LrcBG3L0HOk3qGVpbDzU5mTsE4=.b4386e74-c2be-4e7c-84a7-e91117507a37@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <ANeA1O-SK9B1AxLb-LrcBG3L0HOk3qGVpbDzU5mTsE4=.b4386e74-c2be-4e7c-84a7-e91117507a37@github.com>
Message-ID: <WO1kR4DGkpyh3Pwlg0q_uAEXd2_mV0jAAEqBAvpLlug=.28edaa35-1582-44e3-9fd2-1b1aa3a69f82@github.com>

On Sat, 16 Apr 2022 11:05:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/java/io/FilterInputStream.java line 233:
> 
>> 231:      */
>> 232:     @Override
>> 233:     public void reset() throws IOException {
> 
> I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern?

Yes, this is intentional but it would be great to split out this change and get them into the main line in advance. There is a JEP size task required to re-visit all of the locking in java.io. In the case of the input/output streams, most of it is not documented and there are several inconsistencies. In the case of FilterInputStream, it doesn't use synchronization for the other ops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 15:02:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 15:02:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <JgFnyYyVzBmyCeAq2qCs3hDZFznoFDMujGhcwiAmUrI=.253fb317-6cce-4874-852a-a2675de073a3@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <JgFnyYyVzBmyCeAq2qCs3hDZFznoFDMujGhcwiAmUrI=.253fb317-6cce-4874-852a-a2675de073a3@github.com>
Message-ID: <6Y07wh7rpLs5SDolUCKoYqjmlst-6TKw03RpPubm0bM=.4401cd6d-e80a-48f9-bce2-77e9c757e4b2@github.com>

On Sat, 16 Apr 2022 12:31:41 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111:
> 
>> 109:                 methodType = MethodType.methodType(void.class, long.class);
>> 110:                 endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType);
>> 111: 
> 
> This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`.
> 
> Suggestion:
> 
>                 JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();
>                 MethodType methodType = MethodType.methodType(long.class);
>                 beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType);
>                 if (beginCompensatedBlock == null) {
>                     throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType);
>                 }
>                 methodType = MethodType.methodType(void.class, long.class);
>                 endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType);
>                 if (endCompensatedBlock == null) {
>                     throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType);
>                 }

I think we may just eliminate the reflection use and use a shared secret instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 15:02:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 15:02:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <FbKKiFJlfMTc51D3eq6oc7953FvvjMPXzIOVVxxT6ho=.c131abf0-5354-476f-a453-e351ef1829f4@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <FbKKiFJlfMTc51D3eq6oc7953FvvjMPXzIOVVxxT6ho=.c131abf0-5354-476f-a453-e351ef1829f4@github.com>
Message-ID: <zX0QGA7avdCwhVvplTFaBYPzWb1C9KgVZ0H-VvFJanY=.8d9dde3f-e351-404f-866f-585ea3e94d8d@github.com>

On Fri, 15 Apr 2022 22:01:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184:
> 
>> 182:      * with the Thread API.
>> 183:      */
>> 184:     private static class RootContainer extends ThreadContainer {
> 
> This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based  on the system property. Something to consider later perhaps.

We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 16 15:59:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Apr 2022 15:59:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <rH1-cueUsrxXuCOh6ZSJjsJkekBYRqBcf4Q8v6ykxaU=.7101d4f4-91bc-43b0-9338-24dc16b67a1a@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <rH1-cueUsrxXuCOh6ZSJjsJkekBYRqBcf4Q8v6ykxaU=.7101d4f4-91bc-43b0-9338-24dc16b67a1a@github.com>
Message-ID: <ScvUYEqTKYNvUMcgQFnwscz2HGJ_-OlEoTBX2kIYER4=.1bc95fd1-c2a5-433b-bed3-cb77d881e005@github.com>

On Sat, 16 Apr 2022 09:25:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/java/io/BufferedOutputStream.java line 136:
> 
>> 134:      * are added. A no-op if the buffer is not resizable.
>> 135:      */
>> 136:     private void growIfNeeded(int len) {
> 
> Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held?

Okay, we can add a comment to these methods (asserts are possible but tend not to be used in this area).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sun Apr 17 03:34:35 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 03:34:35 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <jqmGeANQNCJgMkub8qag54uLniFm_SupjYv6Sbc-u_Q=.bee15c68-74b7-48e9-b3c8-733ccccbdf73@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <y3hJWnrizEK-gvrBKzlhjclF3lL93aJnUBBTR9BbEoo=.1bd4e3ca-6d1a-42e2-a586-56fb677ee885@github.com>
 <jqmGeANQNCJgMkub8qag54uLniFm_SupjYv6Sbc-u_Q=.bee15c68-74b7-48e9-b3c8-733ccccbdf73@github.com>
Message-ID: <Hva40uZAz_P1of4aZQyje-0t1MpeLg0GqSDgvHpEUho=.f17b179a-84bf-43ae-ab4e-0e31bbd3af6a@github.com>

On Sat, 16 Apr 2022 14:34:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76:
>> 
>>> 74:                 && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) {
>>> 75:             ct.beginBlocking();
>>> 76:             long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool());
>> 
>> It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`?
>
> REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a correctness issue but we may be able to make this a bit more robust for these cases.

Hello Alan, 
My concern wasn't really about OOME or resource issue. I had noticed the `ForkJoinPools.beginCompensatedBlock` has a try/catch which then propagates back the `Throwable`. So I thought there could be some genuine exceptions that could be thrown in this flow which ultimately calls `ForkJoinPool.beginCompensatedBlock()`. I haven't yet reached the changes in `ForkJoinPool.java` class itself, so it's likely that this catch block is only there for theoretical reasons when dealing with `MethodHandle`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sun Apr 17 03:52:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 03:52:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <XhcYeNvF-puwfhckIalOe5uUcSHgtgUi5sbwCaQRjjM=.14d4c1cd-209f-49ec-85a7-1aa4e72d9739@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/io/PrintStream.java line 1420:

> 1418:             } else {
> 1419:                 synchronized (this) {
> 1420:                     implFormat(format, args);

I think there's a typo here. I think it should have been:


implFormat(l, format, args);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sun Apr 17 05:00:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 05:00:40 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <yOux-w_H5UYpZMBxkZ-iKrfmeNzdgbK_nLC-18th7wQ=.24f0ce3e-9149-4c91-8cc8-a3cb254f0e58@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/lang/StackTraceElement.java line 556:

> 554:     }
> 555: 
> 556:     static StackTraceElement[] of(StackTraceElement[] stackTrace) {

Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sun Apr 17 06:19:48 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 06:19:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <Qc52HmVhOKh952DYKRG7ZOFeJIVQTJWRhiswi1KQEXM=.4920f899-0538-4978-a183-8c42e9cd29e8@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/lang/Thread.java line 602:

> 600:         } else {
> 601:             // getContextClassLoader not trusted
> 602:             ClassLoader cl = parent.contextClassLoader;

I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are.

It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if  that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be:

if (sm == null || !isCCLOverridden(parent.getClass())) {
    return parent.getContextClassLoader();
}

(notice the negation)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sun Apr 17 06:58:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Apr 2022 06:58:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <XhcYeNvF-puwfhckIalOe5uUcSHgtgUi5sbwCaQRjjM=.14d4c1cd-209f-49ec-85a7-1aa4e72d9739@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <XhcYeNvF-puwfhckIalOe5uUcSHgtgUi5sbwCaQRjjM=.14d4c1cd-209f-49ec-85a7-1aa4e72d9739@github.com>
Message-ID: <RfDZRUIPMMlo4IXCDRLMdAwPz8_P7nQZoTzZoIUG1s4=.603883ab-6877-4ca5-96f7-a5f7752b956e@github.com>

On Sun, 17 Apr 2022 03:49:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/java/io/PrintStream.java line 1420:
> 
>> 1418:             } else {
>> 1419:                 synchronized (this) {
>> 1420:                     implFormat(format, args);
> 
> I think there's a typo here. I think it should have been:
> 
> 
> implFormat(l, format, args);

Well spotted, the locale should be provided.

> src/java.base/share/classes/java/lang/Thread.java line 602:
> 
>> 600:         } else {
>> 601:             // getContextClassLoader not trusted
>> 602:             ClassLoader cl = parent.contextClassLoader;
> 
> I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are.
> 
> It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if  that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be:
> 
> if (sm == null || !isCCLOverridden(parent.getClass())) {
>     return parent.getContextClassLoader();
> }
> 
> (notice the negation)

This code hasn't changed, it's just moved to a helper method. When running with a security manager and the CCL methods aren't overridden, then it avoids the permission check. However, I can see how the comment is mis-reading so we can improve that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sun Apr 17 09:45:34 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Sun, 17 Apr 2022 09:45:34 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap [v4]
In-Reply-To: <sa-yQPr3eJSQ2nn7ELJVMofxIiL2MnndoFcGirsosLc=.12d38c25-cc14-482e-9664-6ed8f54bec6f@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
 <bdqs76U2dWZMMtiF-x4vgh-gy_wC7V2M02IfgkMEy64=.4c47b0d9-13da-455a-80b4-f90ab1a01cba@github.com>
 <sa-yQPr3eJSQ2nn7ELJVMofxIiL2MnndoFcGirsosLc=.12d38c25-cc14-482e-9664-6ed8f54bec6f@github.com>
Message-ID: <e3hWj_K-AnpaqGZvVFW9ePNKDKi69j_bwAcQXIi0GaA=.cda50abf-fbd4-42d1-90d4-34e527fb01eb@github.com>

On Sat, 19 Mar 2022 19:46:19 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> liach has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default
>>  - fix whitespace
>
> src/java.base/share/classes/java/util/IdentityHashMap.java line 523:
> 
>> 521:      *          mapping was in the map
>> 522:      */
>> 523:     private boolean removeMapping(Object key, Object value) {
> 
> Note?that `IdentityHashMap.remove(Object,?Object)` needs?to?call this?method, as?the?default implementation calls `Objects.equals(?)`: <https://github.com/openjdk/jdk/blob/3f923b82c31325504430b50dee262fd460004e7b/src/java.base/share/classes/java/util/Map.java#L866-L874>

This?is being?addressed in?<https://github.com/openjdk/jdk/pull/8259>.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6532

From jpai at openjdk.java.net  Sun Apr 17 12:42:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 12:42:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <AeHBh78QP6KEqyqTL44hXNph23SSdhMiuTzfjMjaLx4=.f7ea37e9-7557-4d44-9f39-5b4c893e5e0d@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/lang/Thread.java line 1554:

> 1552:      * Null out reference after Thread termination (JDK-4006245)
> 1553:      */
> 1554:     void clearReferences() {

I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations. 

With the new implementation in this PR, this `clearReferences()` will no longer set the user/application `task` instance to `null`. I understand why we aren't doing that - the `task` field in the `FieldHolder` is `final` (IMO, rightly so). This, in theory, undoes what JDK-4006245 had implemented. I don't know if we still need such a change here and I'm just bringing this up to see if anyone else has any opinions or if any additional experiments need to be run in context of this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Sun Apr 17 13:36:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 17 Apr 2022 13:36:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
Message-ID: <ddJD9WSuhXp55gDGbxVG2XL4mMN5NXyUMcptQiFBt4g=.9c71453c-1f45-4274-8730-c25fe75406be@github.com>

On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

src/java.base/share/classes/java/lang/Thread.java line 2414:

> 2412:             sm.checkPermission(new RuntimePermission("setContextClassLoader"));
> 2413:         }
> 2414:         if (!isSupportedClassLoader(contextClassLoader)) {

For a few moments, I thought this was a typo and should instead have been:

if (!isSupportedClassLoader(cl)) {

but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader  is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`).

Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jiefu at openjdk.java.net  Sun Apr 17 14:44:57 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 17 Apr 2022 14:44:57 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator
 for negative byte/short elements
Message-ID: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>

Hi all,

According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
However, current implementation is incorrect for negative bytes/shorts.

The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.

 13     public static void urshift(byte[] src, byte[] dst) {
 14         for (int i = 0; i < src.length; i++) {
 15             dst[i] = (byte)(src[i] >>> 3);
 16         }
 17     }
 18 
 19     public static void urshiftVector(byte[] src, byte[] dst) {
 20         int i = 0;
 21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
 22             var va = ByteVector.fromArray(spec, src, i);
 23             var vb = va.lanewise(VectorOperators.LSHR, 3);
 24             vb.intoArray(dst, i);
 25         }
 26 
 27         for (; i < src.length; i++) {
 28             dst[i] = (byte)(src[i] >>> 3);
 29         }
 30     }


Unfortunately and to our surprise, code at line28 computes different results with code at line23.
It took quite a long time to figure out this bug.

The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
So this seems unreasonable and unfriendly to Java developers.
It would be better to fix it.

The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
This logic is:
- For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
- For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
- For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.

I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
And many thanks to @fg1417 .


Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

-------------

Commit messages:
 - Add a space
 - 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

Changes: https://git.openjdk.java.net/jdk/pull/8276/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8276&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284932
  Stats: 77 lines in 17 files changed: 19 ins; 12 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8276.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8276/head:pull/8276

PR: https://git.openjdk.java.net/jdk/pull/8276

From alanb at openjdk.java.net  Sun Apr 17 16:03:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Apr 2022 16:03:30 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Refresh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/f53f0d4e..ff1ef712

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02-03

  Stats: 1517 lines in 74 files changed: 1034 ins; 311 del; 172 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sun Apr 17 16:03:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Apr 2022 16:03:31 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <AeHBh78QP6KEqyqTL44hXNph23SSdhMiuTzfjMjaLx4=.f7ea37e9-7557-4d44-9f39-5b4c893e5e0d@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <AeHBh78QP6KEqyqTL44hXNph23SSdhMiuTzfjMjaLx4=.f7ea37e9-7557-4d44-9f39-5b4c893e5e0d@github.com>
Message-ID: <bwu_yGVf4v041KSJGmzz_KqydxSMWNXyRUx_TafgBpA=.a0d3f392-72fc-4514-b52c-6532fe1d2a93@github.com>

On Sun, 17 Apr 2022 12:39:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations.

The comment on that method dates from early JDK releases with the Classic VM and its conservative GC. It also predates the java.lang.ref API.  The question that I think you are asking is if you create a Thread with a runnable task, let it terminate but keep the reference to the Thread forever then what does it keep alive. We can think about more but so far we haven't seen any issues or tests fail with the reference to the runnable task.

> src/java.base/share/classes/java/lang/Thread.java line 2414:
> 
>> 2412:             sm.checkPermission(new RuntimePermission("setContextClassLoader"));
>> 2413:         }
>> 2414:         if (!isSupportedClassLoader(contextClassLoader)) {
> 
> For a few moments, I thought this was a typo and should instead have been:
> 
> if (!isSupportedClassLoader(cl)) {
> 
> but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader  is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`).
> 
> Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`?

I think the comment on isSupportedClassLoader is readable so I think it's okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sun Apr 17 16:03:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Apr 2022 16:03:32 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <XNFvRMNTy1RRnoitO1ZQnhzQdgDo2oNiJqVB0HBufo8=.28d65b88-05cd-40c2-b516-39d25a760447@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <XNFvRMNTy1RRnoitO1ZQnhzQdgDo2oNiJqVB0HBufo8=.28d65b88-05cd-40c2-b516-39d25a760447@github.com>
Message-ID: <hqGW1iM7CKhcl4PpyyisAxZT_JUDYuRj0IxbaST4OQE=.13dc70cf-e957-47d9-ae98-2e262d5be429@github.com>

On Fri, 15 Apr 2022 21:15:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94:
> 
>> 92:             default:
>> 93:                 throw new AssertionError("Unknown pinned reason: " + reason);
>> 94:         }
> 
> Suggestion:
> 
>         return switch (reason) {
>             case 2 -> Pinned.CRITICAL_SECTION;
>             case 3 -> Pinned.NATIVE;
>             case 4 -> Pinned.MONITOR;
>             default -> throw new AssertionError("Unknown pinned reason: " + reason);
>         };

That would be clearer (I think this predates switch expressions).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Sun Apr 17 16:24:13 2022
From: duke at openjdk.java.net (liach)
Date: Sun, 17 Apr 2022 16:24:13 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
Message-ID: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>

Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.

The main compatibility changes and their rationales are:
1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
   - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
   - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
   - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
2. The disappearance of proxies in stack traces.
   - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.

A summary of the rest of the changes:
1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.

In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?

Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

-------------

Commit messages:
 - Change proxy serialization to work with hidden classes (require spec update)
 - Formatting
 - Move to hidden class and methods in class data
 - Implement anchors and remove proxyClassLookup factory

Changes: https://git.openjdk.java.net/jdk/pull/8278/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8278&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242888
  Stats: 400 lines in 6 files changed: 122 ins; 222 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8278.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8278/head:pull/8278

PR: https://git.openjdk.java.net/jdk/pull/8278

From duke at openjdk.java.net  Sun Apr 17 17:29:26 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 17 Apr 2022 17:29:26 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <NvR2yASUjqxpp0wRNSrmeOr4TmMiu4zfdQMY5c1hfpw=.9d9b3336-d8f8-4e9c-bd35-1491d9ecb5af@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Hi,

The `>>>` operator is not defined for subword types, what the code in line 28 does vs what it is supposed to do is different, which is more likely the bug here. An unsigned shift should operate on subword types the same as it does on word and double-word types, which is to zero extend the value before shifting it rightwards.

Another argument would be that an unsigned shift operates on the unsigned types, and the signed cast exposes this misunderstanding regarding the operation.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From hiran.chaudhuri at gmx.net  Sun Apr 17 18:22:53 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Sun, 17 Apr 2022 20:22:53 +0200
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
 <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
Message-ID: <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>

On Thu, 2022-04-07 at 19:53 -0400, Alexey Semenyuk wrote:

>
> I can see two separate issues with jpackage:
  1. jpackage reports NPE if it can't figure out the package name
> from
> the supplied application image. It should issue a helpful error
> message
> instead
>   2. jpackage fails to populate application image with Java runtime
> and
> app specific files when executed in Github but exits with "0" status
> indicating no error
>

I totally agree these are two separate issues.

>
> The major problem in your use case is that jpackage doesn't create
> correct application image. Instead, it creates only a directory
> structure of application image, but no files and exits with a
> "success"
> status code. This is quite strange. Is there any chance Gradle
> ignores
> non-zero exit code from jpackage execution? Can you directly run
> jpackage command creating application image in the environment where
> it
> outputs "empty" application image and check its exit code (please
> add
> "--verbose" to jpackage command line to get debug output)?
>
> - Alexey
>

Now this is somewhat puzzling for me:
I tried to factor out Gradle by putting the JPackage commands into a
separate section of the Github Actions script. So now it is invoked
through bash.

No wonder, the command triggered by Gradle and the one triggered by
bash revealed the same result: A lot of files were missing. I verified
this by listing the directories through a 'find'.

But then I followed your advice and added --verbose to the JPackage
command. And find lists a lot more files now.

In case you are interested, check out
https://github.com/HiranChaudhuri/settlers-installer/runs/5890636608?check_suite_focus=true

So now I believe that --verbose does not only change log output but
also impacts app-image creation. BTW, the command used is

jpackage --verbose --type app-image --dest app/build/app-image -i
app/build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-
SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake
--app-version 0.1.0-SNAPSHOT --description 'Settlers 3 remake - see
https://github.com/' --vendor Hiran, --icon
app/build/resources/main/siedler3-helme-logo.png --resource-dir
app/build/resources/jpackage

Hiran


From some-java-user-99206970363698485155 at vodafonemail.de  Sun Apr 17 19:43:14 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Sun, 17 Apr 2022 21:43:14 +0200
Subject: Improve `finally` block exception handling
Message-ID: <cc4ce3850b5742e2bc647b598119ee16@vodafonemail.de>


Hello,

are there any plans to improve exception handling in combination with `finally` blocks?
Currently, when a `finally` block does not complete normally, the original exception is
silently discarded (as described in the JLS). This behavior is error-prone, not obvious
at all, and has been criticized in the past a lot. An example for this is https://stackoverflow.com/q/48088
and the linked posts there.

While javac warns you about this issue when using `-Xlint:finally`, it is only a warning
and not even enabled by default.

Are there any plans to forbid usage of `break`, `continue`, `yield` and `return` in
`finally` blocks?
Switch expressions have already set a precedent for this by not allowing to leave the
switch expression by something other than a `throw` or `yield` statement, trying to use
for example a `return` statement causes a compilation error.

Similarly for `throw` and any implicitly thrown exceptions, is there a plan to at least
add the original exception as suppressed one to the newly thrown?
Of course one could argue that the same applies to `catch` clauses whose body accidentally
causes an exception which discards the caught one. However the main difference is that
there, only a specific exception type is caught (and discarded), whereas for `finally`
exceptions of _any_ type are discarded. It could also be argued that adding suppressed
exceptions decreases performance or causes memory leaks, but one the other hand
this behavior was explicitly included try-with-resources statements, most likely because the
value this adds was considered more important than any performance issues this
might cause.

Also, it is important to keep in mind that this affects _all_ Throwable types, including
VM errors which you really should not catch, and which due to a `finally` block might
silently be discarded. Most, if not all, code in which a `finally` does not complete
normally does not seem to consider this.

This is also not a theoretical problem; this issue exists in multiple open source projects,
potentially even in the JDK itself.
Often the code can be rewritten by either moving the complete code or parts of it
outside of the `finally` block, or by introducing a local variable to hold the result and
to return that after the `finally` block.

What do you think about this topic?
Is backward compatibility a concern? If so, can you provide an example where using such
a pattern provides any notable advantages which justify the potential loss of thrown
VM errors or exceptions.

Kind regards




From jiefu at openjdk.java.net  Sun Apr 17 23:09:31 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 17 Apr 2022 23:09:31 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <NvR2yASUjqxpp0wRNSrmeOr4TmMiu4zfdQMY5c1hfpw=.9d9b3336-d8f8-4e9c-bd35-1491d9ecb5af@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <NvR2yASUjqxpp0wRNSrmeOr4TmMiu4zfdQMY5c1hfpw=.9d9b3336-d8f8-4e9c-bd35-1491d9ecb5af@github.com>
Message-ID: <j2Ss386W9_ERGQSZ53PishDMrlFIPR8BiSNG5st8Hk4=.f459e97a-0a55-41c7-bf02-7c37a0f96cf0@github.com>

On Sun, 17 Apr 2022 17:25:57 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> The `>>>` operator is not defined for subword types, what the code in line 28 does vs what it is supposed to do are different, which is more likely the bug here. An unsigned shift should operate on subword types the same as it does on word and double-word types, which is to zero extend the value before shifting it rightwards.
> 
> Another argument would be that an unsigned shift operates on the unsigned types, and the signed cast exposes this misunderstanding regarding the operation.
> 
> Thanks.

Thanks @merykitty for your comments.

What I show in this PR is the typical translation of a Java scalar program to Vector API code.
Obviously, the implementation is wrong for negative bytes/shorts according to the description of the Vecotor API doc.

As a general programming language, Java does support the usage of `>>>` for negative bytes/shorts.
Will you use this Vector API to optimize a Java lib which doesn't know the actual input at all?
For a given shift_cnt, why not produce the same result for Vector API just as what is done for scalar `>>>`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Sun Apr 17 23:57:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 17 Apr 2022 23:57:41 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <qwv3pCZDkYPTEPN_VCvE64UH8KkAxjH3c_Eh-NzN3B0=.d8206fc5-ee9d-4397-94e3-ecba1835f8ba@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Hi,

According to JLS section 5.8, any operand in a numeric arithmetic context undergoes a promotion to int, long, float or double and the operation is only defined for values of the promoted types. This means that `>>>` is not defined for byte/short values and the real behaviour here is that `src[i]` get promoted to int by a signed cast before entering the unsigned shift operation. This is different from `VectorOperators.LSHR` which is defined for byte/short element types. The scalar code does not do a byte unsigned shift but an int unsigned shift between a promotion and a narrowing cast, the explicit cast `(byte)` notifies the user of this behaviour.

Secondly, consistency is the key, having a byte unsigned shift promoted elements to int is not consistent, I can argue why aren't int elements being promoted to longs, or longs being promoted to the 128-bit integral type, too.

Finally, as I have mentioned in #7979, this usage of unsigned shift seems more likely to be a bug than an intended behaviour, so we should not bother to optimise this pattern.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 01:51:40 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 01:51:40 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <qwv3pCZDkYPTEPN_VCvE64UH8KkAxjH3c_Eh-NzN3B0=.d8206fc5-ee9d-4397-94e3-ecba1835f8ba@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <qwv3pCZDkYPTEPN_VCvE64UH8KkAxjH3c_Eh-NzN3B0=.d8206fc5-ee9d-4397-94e3-ecba1835f8ba@github.com>
Message-ID: <SaB0aPQUuIDErctjIoLcVTPA5UP72oNxhwx9H6WC_1Q=.e86bedf9-9868-4f05-9692-88377e3d47ba@github.com>

On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> According to JLS section 5.8, any operand in a numeric arithmetic context undergoes a promotion to int, long, float or double and the operation is only defined for values of the promoted types. This means that `>>>` is not defined for byte/short values and the real behaviour here is that `src[i]` get promoted to int by a signed cast before entering the unsigned shift operation. This is different from `VectorOperators.LSHR` which is defined for byte/short element types. The scalar code does not do a byte unsigned shift but an int unsigned shift between a promotion and a narrowing cast, the explicit cast `(byte)` notifies the user of this behaviour.

I can't understand why people can't use `>>>` for negative bytes/shorts.
 - Does the spec forbidden this usage?
 - Is there any compile error?
 - Is there any runtime error?
 - Is the behavior to be undefined?

The JLS you mentioned actually defines how to compute `>>>` for bytes/shorts in Java, which applies to both positive and negative bytes/shorts.
 - First, it gets promoted.
 - Then, do something else.

So I disagree with you if the JLS spec doesn't say people are not allowed to use `>>>` for negative bytes/shorts.




> 
> Secondly, consistency is the key, having a byte unsigned shift promoting elements to ints is not consistent, I can argue why aren't int elements being promoted to longs, or longs being promoted to the 128-bit integral type, too.
> 


Well, this kind of behavior was specified by the Java spec rules many years ago.
We have to just follow these rules if you can't change the specs.


> Finally, as I have mentioned in #7979, this usage of unsigned shift seems more likely to be a bug than an intended behaviour, so we should not bother to optimise this pattern.

Since the behavior of shift operations is clearly defined by the Java specs and supported by the language, how do you know there is no one to use it intendedly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From ecki at zusammenkunft.net  Mon Apr 18 02:27:41 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 18 Apr 2022 02:27:41 +0000
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <SaB0aPQUuIDErctjIoLcVTPA5UP72oNxhwx9H6WC_1Q=.e86bedf9-9868-4f05-9692-88377e3d47ba@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <qwv3pCZDkYPTEPN_VCvE64UH8KkAxjH3c_Eh-NzN3B0=.d8206fc5-ee9d-4397-94e3-ecba1835f8ba@github.com>
 <SaB0aPQUuIDErctjIoLcVTPA5UP72oNxhwx9H6WC_1Q=.e86bedf9-9868-4f05-9692-88377e3d47ba@github.com>
Message-ID: <AM9P193MB1142138C3D9643B641E09BDAFFF39@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello,

Maybe offer operations which can do all variants (shift, roll, signed/unsigned) - maybe even with support for byte/int conversion? Any of those bit fiddling activities in a pipeline can benefit from vectoring.

And also, the Javadoc can list the equivalent operator based code and maybe bit pattern examples for all overflow cases.

And also.. the unit tests can double as snipped code.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Jie Fu <jiefu at openjdk.java.net>
Gesendet: Monday, April 18, 2022 3:51:40 AM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Betreff: Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> According to JLS section 5.8, any operand in a numeric arithmetic context undergoes a promotion to int, long, float or double and the operation is only defined for values of the promoted types. This means that `>>>` is not defined for byte/short values and the real behaviour here is that `src[i]` get promoted to int by a signed cast before entering the unsigned shift operation. This is different from `VectorOperators.LSHR` which is defined for byte/short element types. The scalar code does not do a byte unsigned shift but an int unsigned shift between a promotion and a narrowing cast, the explicit cast `(byte)` notifies the user of this behaviour.

I can't understand why people can't use `>>>` for negative bytes/shorts.
 - Does the spec forbidden this usage?
 - Is there any compile error?
 - Is there any runtime error?
 - Is the behavior to be undefined?

The JLS you mentioned actually defines how to compute `>>>` for bytes/shorts in Java, which applies to both positive and negative bytes/shorts.
 - First, it gets promoted.
 - Then, do something else.

So I disagree with you if the JLS spec doesn't say people are not allowed to use `>>>` for negative bytes/shorts.




>
> Secondly, consistency is the key, having a byte unsigned shift promoting elements to ints is not consistent, I can argue why aren't int elements being promoted to longs, or longs being promoted to the 128-bit integral type, too.
>


Well, this kind of behavior was specified by the Java spec rules many years ago.
We have to just follow these rules if you can't change the specs.


> Finally, as I have mentioned in #7979, this usage of unsigned shift seems more likely to be a bug than an intended behaviour, so we should not bother to optimise this pattern.

Since the behavior of shift operations is clearly defined by the Java specs and supported by the language, how do you know there is no one to use it intendedly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 02:35:38 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 02:35:38 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <f2TRWQwde2hwOPUbASNIvX6vgMauH34S87-GRiNM2vc=.1427279e-9c73-4599-a04f-bbf2d5832c58@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Hi,

Just because an operation can be used with certain operands does not necessarily mean that operation is defined for that type of operand. For example, we have `MyObject::equals(Object)`, and you can use a `String` as an argument for this method, does that mean `MyObject::equals(String)` is also defined. The answer is no, because you can define another method `MyObject::equals(String)` and the compiler won't complain about the redefinition of `MyObject::equals(String)`.

What I try to convey here is that `src[i] >>> 3` is not a byte unsigned shift, it is an int unsigned shift following a byte-to-int promotion. This is different from the Vector API that has definition for the shift operations of subword types.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 02:42:33 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 02:42:33 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <WIy8Tl2StbRGY5ytUSsYp_E4eqUWSpXXgvMLDyoOwQo=.f252a45e-2317-48b4-99ea-8cd0ce84a640@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Also you can see the reasons in these lines of comments:

https://github.com/openjdk/jdk/blob/e5041ae3d45b43be10d5da747d773882ebf0482b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L944

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 02:50:37 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 02:50:37 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <f2TRWQwde2hwOPUbASNIvX6vgMauH34S87-GRiNM2vc=.1427279e-9c73-4599-a04f-bbf2d5832c58@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <f2TRWQwde2hwOPUbASNIvX6vgMauH34S87-GRiNM2vc=.1427279e-9c73-4599-a04f-bbf2d5832c58@github.com>
Message-ID: <aqESAJpV6Y2gda0WWpp0RMIlBzsVcS1m1BufoKiEM_A=.9b15b8de-7177-422d-813a-7aafe9e69b11@github.com>

On Mon, 18 Apr 2022 02:32:39 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> What I try to convey here is that `src[i] >>> 3` is not a byte unsigned shift, it is an int unsigned shift following a byte-to-int promotion. This is different from the Vector API that has definition for the shift operations of subword types.

The vector api docs says it would compute `a>>>(n&(ESIZE*8-1))`.
<img width="647" alt="image" src="https://user-images.githubusercontent.com/19923746/163746064-b1c1ae37-245e-4a92-9020-99b13195193d.png">

> Also you can see the reasons in these lines of comments:
> 
> https://github.com/openjdk/jdk/blob/e5041ae3d45b43be10d5da747d773882ebf0482b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L944
> 
> Thanks.

The patch wouldn't change the masked shift count of vector api.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 02:50:37 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 02:50:37 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <74ZK5w-uMmEH7-6vNmofrS_b_q8ZOOOd70bvlPwD6cM=.bcb94cc2-7081-44a7-ac10-8f05c0e3d0e5@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Then the doc seems to be the actual one to be blamed here I think.

> our lane types are first-class types, not just dressed up ints.

This is what I'm focusing on actually. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 03:24:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 03:24:30 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <Q5x5h8ziqWuX8FPCRwmxim0m5PTNxQEeeGPCkq38UyY=.249e4f00-a4c7-4a3e-ae0e-3f3332e57ad2@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

According to the vector api doc, `LSHR` seems to be designed to vectorize the scalar `>>>` with masked `shift_cnt`.
Since for most cases, if we use vector api to rewrite the scalar code, we don't know if all the inputs are positive only.
So it would be better to follow the scalar `>>>` behavior for any supported masked `shift_cnt`.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 03:51:50 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 03:51:50 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Hi,

Because unsigned cast should operate on unsigned types, the more appropriate usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from unsigned byte to int. Actually, I fail to understand the intention of your example, why not use signed shift instead, what does unsigned shift provide here apart from extra cognitive load in reasoning the operation.

May you provide a more concrete example to the utilisation of unsigned shift on signed subword types, please. The example provided by @fg1417 in #7979 seems to indicate the real intention is to right shifting unsigned bytes, with the unsigned cast sometimes omitted (changed to a signed cast) because the shift results are masked by a stricter mask immediately.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 04:17:40 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 04:17:40 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
Message-ID: <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>

On Mon, 18 Apr 2022 03:48:13 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Because unsigned cast should operate on unsigned types, the more appropriate usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from unsigned byte to int. Actually, I fail to understand the intention of your example, why not use signed shift instead, what does unsigned shift provide here apart from extra cognitive load in reasoning the operation.


The fact is that you can't prevent developers from using `>>>` upon negative elements since neither the JVMS nor the JLS prevents it.


> May you provide a more concrete example to the utilisation of unsigned shift on signed subword types, please. The example provided by @fg1417 in #7979 seems to indicate the real intention is to right shifting unsigned bytes, with the unsigned cast sometimes omitted (changed to a signed cast) because the shift results are masked by a stricter mask immediately.

Sorry, I can't show the detail of our customer's code.
However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`, how can you say there should be always non-negative operands?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 04:28:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 04:28:41 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
Message-ID: <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>

On Mon, 18 Apr 2022 04:14:39 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`

Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.

Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From david.holmes at oracle.com  Mon Apr 18 04:40:58 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Apr 2022 14:40:58 +1000
Subject: Improve `finally` block exception handling
In-Reply-To: <cc4ce3850b5742e2bc647b598119ee16@vodafonemail.de>
References: <cc4ce3850b5742e2bc647b598119ee16@vodafonemail.de>
Message-ID: <fab2bd21-24b9-8ca5-6a45-0507be0db0d6@oracle.com>

Hello,

On 18/04/2022 5:43 am, 
some-java-user-99206970363698485155 at vodafonemail.de wrote:
> 
> Hello,
> 
> are there any plans to improve exception handling in combination with `finally` blocks?

I'm not aware of anything, nor what that anything could realistically 
be. You make only one suggestion that has a little merit.

> Currently, when a `finally` block does not complete normally, the original exception is
> silently discarded (as described in the JLS). This behavior is error-prone, not obvious
> at all, and has been criticized in the past a lot. An example for this is https://stackoverflow.com/q/48088
> and the linked posts there.

The behaviour of try/catch/finally is not "obvious at all", you have to 
read what it means and when you do that you clearly see what happens 
regarding exceptions.

> While javac warns you about this issue when using `-Xlint:finally`, it is only a warning
> and not even enabled by default.
> 
> Are there any plans to forbid usage of `break`, `continue`, `yield` and `return` in
> `finally` blocks?

Why would we do that? What would that gain?

> Switch expressions have already set a precedent for this by not allowing to leave the
> switch expression by something other than a `throw` or `yield` statement, trying to use
> for example a `return` statement causes a compilation error.

That is because it is an _expression_ - expressions have to have 
different language rules to statements. There is no connection to a 
finally block.

> Similarly for `throw` and any implicitly thrown exceptions, is there a plan to at least
> add the original exception as suppressed one to the newly thrown?

That suggestion is not completely without merit, but nor is it a 
"slam-dunk" obvious thing to do. The semantic implications of the 
exceptions matter, and semantics come from the programmers intent. 
There's no reasonable way to automagically determine that when an 
exception is created that another exception (that led to the finally 
block) should be inserted as a "suppressed exception". That would 
actually be completely wrong to do in many circumstances you would 
instead need to act when the exception would terminate the finally block 
and then add the original exception as the "suppressed" exception. But 
really the programmer is in the best position to decide how exceptions 
need to be handled.

> Of course one could argue that the same applies to `catch` clauses whose body accidentally
> causes an exception which discards the caught one. However the main difference is that

Yes exactly the same.

> there, only a specific exception type is caught (and discarded), whereas for `finally`
> exceptions of _any_ type are discarded. It could also be argued that adding suppressed

We have multi-catch now so that argument is somewhat weaker.

> exceptions decreases performance or causes memory leaks, but one the other hand
> this behavior was explicitly included try-with-resources statements, most likely because the
> value this adds was considered more important than any performance issues this
> might cause.

try-with-resources added support for suppressed exceptions because the 
automatic closing of the resource could throw an exception, and that had 
to be factored in to the whole mechanism.

> Also, it is important to keep in mind that this affects _all_ Throwable types, including
> VM errors which you really should not catch, and which due to a `finally` block might
> silently be discarded. Most, if not all, code in which a `finally` does not complete
> normally does not seem to consider this.

That is true. But for me a finally block is intended to be quite small 
and succint and should be written from the perspective of "an unexpected 
exception has occurred, what it is it critical for me to do before 
leaving the current scope".

> This is also not a theoretical problem; this issue exists in multiple open source projects,
> potentially even in the JDK itself.
> Often the code can be rewritten by either moving the complete code or parts of it
> outside of the `finally` block, or by introducing a local variable to hold the result and
> to return that after the `finally` block.
> 
> What do you think about this topic?

I think there is no clear and obvious solution that the language can put 
in place here.

Just my personal 2c.

Cheers,
David

> Is backward compatibility a concern? If so, can you provide an example where using such
> a pattern provides any notable advantages which justify the potential loss of thrown
> VM errors or exceptions.
> 
> Kind regards
> 
> 
> 

From eliu at openjdk.java.net  Mon Apr 18 04:51:31 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 18 Apr 2022 04:51:31 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
Message-ID: <7sXkW6eJnW_vQ6X0o2j-Mq7q7xTb2psvjYk0tJsztU8=.3e04f081-09bd-437d-bca9-f705204b9a25@github.com>

On Mon, 18 Apr 2022 04:14:39 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi,
>> 
>> Because unsigned cast should operate on unsigned types, the more appropriate usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from unsigned byte to int. Actually, I fail to understand the intention of your example, why not use signed shift instead, what does unsigned shift provide here apart from extra cognitive load in reasoning the operation.
>> 
>> May you provide a more concrete example to the utilisation of unsigned shift on signed subword types, please. The example provided by @fg1417 in #7979 seems to indicate the real intention is to right shifting unsigned bytes, with the unsigned cast sometimes omitted (changed to a signed cast) because the shift results are masked by a stricter mask immediately.
>> 
>> Thank you very much.
>
>> Because unsigned cast should operate on unsigned types, the more appropriate usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from unsigned byte to int. Actually, I fail to understand the intention of your example, why not use signed shift instead, what does unsigned shift provide here apart from extra cognitive load in reasoning the operation.
> 
> 
> The fact is that you can't prevent developers from using `>>>` upon negative elements since neither the JVMS nor the JLS prevents it.
> 
> 
>> May you provide a more concrete example to the utilisation of unsigned shift on signed subword types, please. The example provided by @fg1417 in #7979 seems to indicate the real intention is to right shifting unsigned bytes, with the unsigned cast sometimes omitted (changed to a signed cast) because the shift results are masked by a stricter mask immediately.
> 
> Sorry, I can't show the detail of our customer's code.
> However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`, how can you say there should be always non-negative operands?

@DamonFool 

I think the issue is that these two cases of yours are not equal semantically.


 13     public static void urshift(byte[] src, byte[] dst) {
 14         for (int i = 0; i < src.length; i++) {
 15             dst[i] = (byte)(src[i] >>> 3);
 16         }
 17     }
 18 
 19     public static void urshiftVector(byte[] src, byte[] dst) {
 20         int i = 0;
 21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
 22             var va = ByteVector.fromArray(spec, src, i);
 23             var vb = va.lanewise(VectorOperators.LSHR, 3);
 24             vb.intoArray(dst, i);
 25         }
 26 
 27         for (; i < src.length; i++) {
 28             dst[i] = (byte)(src[i] >>> 3);
 29         }
 30     }


Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 05:12:43 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 05:12:43 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
Message-ID: <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>

On Mon, 18 Apr 2022 04:25:23 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> > However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`
> 
> Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.

Yes, you're right that's why I said `LSHR` can be replaced with `ASHR`.

However, not all the people are clever enough to do this source code level replacement.
To be honest, I would never think of that `>>>` can be auto-vectorized by this idea proposed by https://github.com/openjdk/jdk/pull/7979 .

> 
> Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)

`LSHR` following the behavior of scalar `>>>` is very important for Java developers to rewrite the code with vector api.
Maybe, we should add one more operator to support what you called `the proper unsigned shifts`, right?
But that's another topic which can be done in a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon Apr 18 05:17:35 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 05:17:35 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
 <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
Message-ID: <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>

On Mon, 18 Apr 2022 05:09:33 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`
>> 
>> Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.
>> 
>> Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)
>> 
>> Thank you very much.
>
>> > However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`
>> 
>> Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.
> 
> Yes, you're right that's why I said `LSHR` can be replaced with `ASHR`.
> 
> However, not all the people are clever enough to do this source code level replacement.
> To be honest, I would never think of that `>>>` can be auto-vectorized by this idea proposed by https://github.com/openjdk/jdk/pull/7979 .
> 
>> 
>> Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)
> 
> `LSHR` following the behavior of scalar `>>>` is very important for Java developers to rewrite the code with vector api.
> Maybe, we should add one more operator to support what you called `the proper unsigned shifts`, right?
> But that's another topic which can be done in a separate issue.

> @DamonFool
> 
> I think the issue is that these two cases of yours are not equal semantically.

Why?
According to the vector api doc, they should compute the same value when the shift_cnt is 3, right?

> 
> ```
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> ```
> 
> Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`

Since all the vector operations are already based on byte lane type, I don't think we need a `cast` operation here.
Can we solve this problem by inserting a cast operation?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 05:20:28 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 18 Apr 2022 05:20:28 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <uiwHV47rEgAW7wm8EJsxCc7hq4D6lZlXR_8zBLpAF_Y=.1e67f7ea-dc53-4c6f-b260-0c2798feed93@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

I now think that this should be split into probably four separate patches:
1. Merge the 2 passes of scanning interfaces, and store the exported/non-exported package within the classloader value info for dynamic modules
2. Use the JLIA access to obtain lookup than spin an accessor in every proxy class
3. Update serialization constructor generation to use method handles (as in #1830) for hidden classes, don't change the serialization specs for now, as it affects security.

And finally, convert proxies to hidden classes like in this pr. There will be an option (most likely command line) to restore old proxies. And in the new proxies, method objects can be passed as class data, like in the current patch. The jshell test change will be in the final conversion patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From duke at openjdk.java.net  Mon Apr 18 06:21:49 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 18 Apr 2022 06:21:49 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
Message-ID: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>

Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.

Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

-------------

Commit messages:
 - 8284942: Proxy building can just iterate superinterfaces once

Changes: https://git.openjdk.java.net/jdk/pull/8281/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284942
  Stats: 64 lines in 1 file changed: 16 ins; 25 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From eliu at openjdk.java.net  Mon Apr 18 07:34:33 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 18 Apr 2022 07:34:33 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
 <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
 <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
Message-ID: <NjfGskxqL2e04xrpAscFwl9_YwbRpYV6HrVc75Hol2s=.9ef20857-dec7-4eda-8040-98ba73809a2a@github.com>

On Mon, 18 Apr 2022 05:14:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> > However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`
>>> 
>>> Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.
>> 
>> Yes, you're right that's why I said `LSHR` can be replaced with `ASHR`.
>> 
>> However, not all the people are clever enough to do this source code level replacement.
>> To be honest, I would never think of that `>>>` can be auto-vectorized by this idea proposed by https://github.com/openjdk/jdk/pull/7979 .
>> 
>>> 
>>> Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)
>> 
>> `LSHR` following the behavior of scalar `>>>` is very important for Java developers to rewrite the code with vector api.
>> Maybe, we should add one more operator to support what you called `the proper unsigned shifts`, right?
>> But that's another topic which can be done in a separate issue.
>
>> @DamonFool
>> 
>> I think the issue is that these two cases of yours are not equal semantically.
> 
> Why?
> According to the vector api doc, they should compute the same value when the shift_cnt is 3, right?
> 
>> 
>> ```
>>  13     public static void urshift(byte[] src, byte[] dst) {
>>  14         for (int i = 0; i < src.length; i++) {
>>  15             dst[i] = (byte)(src[i] >>> 3);
>>  16         }
>>  17     }
>>  18 
>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>  20         int i = 0;
>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>  22             var va = ByteVector.fromArray(spec, src, i);
>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>  24             vb.intoArray(dst, i);
>>  25         }
>>  26 
>>  27         for (; i < src.length; i++) {
>>  28             dst[i] = (byte)(src[i] >>> 3);
>>  29         }
>>  30     }
>> ```
>> 
>> Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`
> 
> Since all the vector operations are already based on byte lane type, I don't think we need a `cast` operation here.
> Can we solve this problem by inserting a cast operation?

@DamonFool 

`>>>` can not apply to sub-word type in Java. `(byte)(src[i] >>> 3)` is unsigned right shift in type of INT and transformed the result to BYTE. In vector api, it extends the `>>>` to sub-word type with the same semantic meaning like `iushr`[1], that is zero extending.

> The vector api docs says it would compute a>>>(n&(ESIZE*8-1)).

I think `>>>` has some extending meanings here. As I said above, no sub-word type for `>>>` in Java.


[1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.iushr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From Alan.Bateman at oracle.com  Mon Apr 18 07:36:08 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Apr 2022 08:36:08 +0100
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <0dcb6adc-13b4-1319-bb0e-e0ec86f916bd@oracle.com>

On 17/04/2022 17:24, liach wrote:
> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
>
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>     - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>     - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>     - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>     - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.

It's great that you have time to experiment in this area but just to set 
expectations that it will likely require significant discussion and 
maybe prototyping of alternatives. It suspect the Reviewer effort will 
end up being many times the effort required to do the actual work 
because of the compatibility and security issues that will need to be 
worked through.

I think you need to add non-discoverability to the list of compatibility 
issues. Do we know for sure that there aren't frameworks and libraries 
that use Class.forName on proxy classes? We've had issues in the past 
with changes in this area.

It's too early to say but it might be that the compatibility risks may 
nudge this one into creating a new API.

-Alan.




From jiefu at openjdk.java.net  Mon Apr 18 08:33:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 08:33:30 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
 <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
 <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
Message-ID: <2STdSZhmfGDaUrgu-er_9sh-ezFAn2Wa4E7BK9EVcYs=.8ebbc203-258e-4c96-96b0-bd77c98415a5@github.com>

On Mon, 18 Apr 2022 05:14:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> > However, just image that someone would like to optimize some code segments of bytes/shorts `>>>`
>>> 
>>> Then that person can just use signed shift (`VectorOperators.ASHR`), right? Shifting on masked shift counts means that the shift count cannot be greater than 8 for bytes and 16 for shorts, which means that `(byte)(src[i] >>> 3)` is exactly the same as `(byte)(src[i] >> 3)`. Please correct me if I misunderstood something here.
>> 
>> Yes, you're right that's why I said `LSHR` can be replaced with `ASHR`.
>> 
>> However, not all the people are clever enough to do this source code level replacement.
>> To be honest, I would never think of that `>>>` can be auto-vectorized by this idea proposed by https://github.com/openjdk/jdk/pull/7979 .
>> 
>>> 
>>> Your proposed changes make unsigned shifts for subwords behave exactly the same as signed shifts, which is both redundant (we have 2 operations doing exactly the same thing) and inadequate (we lack the operation to do the proper unsigned shifts)
>> 
>> `LSHR` following the behavior of scalar `>>>` is very important for Java developers to rewrite the code with vector api.
>> Maybe, we should add one more operator to support what you called `the proper unsigned shifts`, right?
>> But that's another topic which can be done in a separate issue.
>
>> @DamonFool
>> 
>> I think the issue is that these two cases of yours are not equal semantically.
> 
> Why?
> According to the vector api doc, they should compute the same value when the shift_cnt is 3, right?
> 
>> 
>> ```
>>  13     public static void urshift(byte[] src, byte[] dst) {
>>  14         for (int i = 0; i < src.length; i++) {
>>  15             dst[i] = (byte)(src[i] >>> 3);
>>  16         }
>>  17     }
>>  18 
>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>  20         int i = 0;
>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>  22             var va = ByteVector.fromArray(spec, src, i);
>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>  24             vb.intoArray(dst, i);
>>  25         }
>>  26 
>>  27         for (; i < src.length; i++) {
>>  28             dst[i] = (byte)(src[i] >>> 3);
>>  29         }
>>  30     }
>> ```
>> 
>> Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`
> 
> Since all the vector operations are already based on byte lane type, I don't think we need a `cast` operation here.
> Can we solve this problem by inserting a cast operation?

> @DamonFool
> 
> `>>>` can not apply to sub-word type in Java. `(byte)(src[i] >>> 3)` is unsigned right shift in type of INT and transformed the result to BYTE. In vector api, it extends the `>>>` to sub-word type with the same semantic meaning like `iushr`[1], that is zero extending.
> 
> > The vector api docs says it would compute a>>>(n&(ESIZE*8-1)).
> 
> I think `>>>` has some extending meanings here. As I said above, no sub-word type for `>>>` in Java.
> 
> [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.iushr

As discussed above https://github.com/openjdk/jdk/pull/8276#issuecomment-1101016904 , there isn't any problem to apply `>>>` upon shorts/bytes.

What do you think of https://github.com/openjdk/jdk/pull/7979 , which tries to vectorize unsigned shift right on signed subword types ?
And what do you think of the benchmarks mentioned in that PR?

The vector api doc clearly states `LSHR` operator would compute `a>>>(n&(ESIZE*8-1))`.
But it fails to do so when `a` is negative byte/short element.

So if the doc description is correct, the current implementation would be wrong, right?

However, if you think the current implementation is correct, the vector api doc would be wrong.
Then, we would lack an operator working like the scalar `>>>` since current implementation fails to do so for negative bytes/shorts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 09:15:12 2022
From: duke at openjdk.java.net (xpbob)
Date: Mon, 18 Apr 2022 09:15:12 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
Message-ID: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>

set memory.swappiness to 0,swap space will not be used 
determine the value of memory.swappiness
https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt


    Memory Limit: 50.00M
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: 100.00M
    Maximum Processes Limit: 4194305 

=>

    Memory Limit: 50.00M
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: 50.00M
    Maximum Processes Limit: 4194305

-------------

Commit messages:
 - 8284950: Swappiness disables swap space usage

Changes: https://git.openjdk.java.net/jdk/pull/8285/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284950
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Mon Apr 18 10:26:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 18 Apr 2022 10:26:41 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <2STdSZhmfGDaUrgu-er_9sh-ezFAn2Wa4E7BK9EVcYs=.8ebbc203-258e-4c96-96b0-bd77c98415a5@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
 <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
 <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
 <2STdSZhmfGDaUrgu-er_9sh-ezFAn2Wa4E7BK9EVcYs=.8ebbc203-258e-4c96-96b0-bd77c98415a5@github.com>
Message-ID: <c2yb1rhJLR7gChIzp6SlCdjtTcy7wY2B_Ti-Vxt4ffY=.1952fc0b-3046-4501-b356-2a3381b78306@github.com>

On Mon, 18 Apr 2022 08:29:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> @DamonFool
>>> 
>>> I think the issue is that these two cases of yours are not equal semantically.
>> 
>> Why?
>> According to the vector api doc, they should compute the same value when the shift_cnt is 3, right?
>> 
>>> 
>>> ```
>>>  13     public static void urshift(byte[] src, byte[] dst) {
>>>  14         for (int i = 0; i < src.length; i++) {
>>>  15             dst[i] = (byte)(src[i] >>> 3);
>>>  16         }
>>>  17     }
>>>  18 
>>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>>  20         int i = 0;
>>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>>  22             var va = ByteVector.fromArray(spec, src, i);
>>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>>  24             vb.intoArray(dst, i);
>>>  25         }
>>>  26 
>>>  27         for (; i < src.length; i++) {
>>>  28             dst[i] = (byte)(src[i] >>> 3);
>>>  29         }
>>>  30     }
>>> ```
>>> 
>>> Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`
>> 
>> Since all the vector operations are already based on byte lane type, I don't think we need a `cast` operation here.
>> Can we solve this problem by inserting a cast operation?
>
>> @DamonFool
>> 
>> `>>>` can not apply to sub-word type in Java. `(byte)(src[i] >>> 3)` is unsigned right shift in type of INT and transformed the result to BYTE. In vector api, it extends the `>>>` to sub-word type with the same semantic meaning like `iushr`[1], that is zero extending.
>> 
>> > The vector api docs says it would compute a>>>(n&(ESIZE*8-1)).
>> 
>> I think `>>>` has some extending meanings here. As I said above, no sub-word type for `>>>` in Java.
>> 
>> [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.iushr
> 
> As discussed above https://github.com/openjdk/jdk/pull/8276#issuecomment-1101016904 , there isn't any problem to apply `>>>` upon shorts/bytes.
> 
> What do you think of https://github.com/openjdk/jdk/pull/7979 , which tries to vectorize unsigned shift right on signed subword types ?
> And what do you think of the benchmarks mentioned in that PR?
> 
> The vector api doc clearly states `LSHR` operator would compute `a>>>(n&(ESIZE*8-1))`.
> But it fails to do so when `a` is negative byte/short element.
> 
> So if the doc description is correct, the current implementation would be wrong, right?
> 
> However, if you think the current implementation is correct, the vector api doc would be wrong.
> Then, we would lack an operator working like the scalar `>>>` since current implementation fails to do so for negative bytes/shorts.

Hi @DamonFool, the doc does obviously not mean what you think, and actually seems to indicate the Eric's interpretation instead. Simply because `a >>> (n & (ESIZE - 1))` does not output the type of `a` for subword-type inputs, which is clearly wrong. This suggests that the doc here should be interpreted that `>>>` is the extended shift operation, which is defined on subword types the same as for words and double-words. Though, I agree that the doc must be modified to reflect the intention more clearly.

> Then, we would lack an operator working like the scalar >>> since current implementation fails to do so for negative bytes/shorts.

As you have noted, we have `ASHR` for bytes, shorts and `LSHR` for ints, longs. Thanks a lot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From info at j-kuhn.de  Mon Apr 18 10:53:45 2022
From: info at j-kuhn.de (Johannes Kuhn)
Date: Mon, 18 Apr 2022 12:53:45 +0200
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <0dcb6adc-13b4-1319-bb0e-e0ec86f916bd@oracle.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
 <0dcb6adc-13b4-1319-bb0e-e0ec86f916bd@oracle.com>
Message-ID: <fbf69cdb-f230-3c7d-8fe7-56dc0b2bcc00@j-kuhn.de>



On 18-Apr-22 9:36, Alan Bateman wrote:
> On 17/04/2022 17:24, liach wrote:
>> Convert dynamic proxies to hidden classes. Modifies the serialization 
>> of proxies (requires change in "Java Object Serialization 
>> Specification"). Makes the proxies hidden in stack traces. Removes 
>> duplicate logic in proxy building.
>>
>> The main compatibility changes and their rationales are:
>> 1. Modification to the serialization specification: In the "An 
>> instance of the class is allocated... The contents restored 
>> appropriately" section, I propose explicitly state that handling of 
>> proxies are unspecified as to allow implementation freedom, though 
>> I've seen deliberate attempts for proxies to implement interfaces with 
>> `readResolve` in order to control their serialization behavior.
>> ??? - This is for the existing generated constructor accessor is 
>> bytecode-based, which cannot refer to hidden classes.
>> ??? - An alternative is to preserve the behavior, where the 
>> serialization constructor calls `invokespecial` on the closest 
>> serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>> ??? - My rationale against preservation is such super calls are unsafe 
>> and should be discouraged in the long term. Calling the existing 
>> constructor with a dummy argument, as in my implementation, would be 
>> more safe.
>> 2. The disappearance of proxies in stack traces.
>> ??? - Same behavior exists in lambda expressions: For instance, in 
>> `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, 
>> implemented by the lambda, will not appear in the stack trace, and 
>> isn't too problematic.
> 
> It's great that you have time to experiment in this area but just to set 
> expectations that it will likely require significant discussion and 
> maybe prototyping of alternatives. It suspect the Reviewer effort will 
> end up being many times the effort required to do the actual work 
> because of the compatibility and security issues that will need to be 
> worked through.
> 
> I think you need to add non-discoverability to the list of compatibility 
> issues. Do we know for sure that there aren't frameworks and libraries 
> that use Class.forName on proxy classes? We've had issues in the past 
> with changes in this area.
> 
> It's too early to say but it might be that the compatibility risks may 
> nudge this one into creating a new API.
> 
> -Alan.
> 
> 
> 

Proxies will have to be rethought at some future point - wrt Valhalla.

The current specification says:

 > A proxy class implements exactly the interfaces specified at its 
creation, in the same order. Invoking getInterfaces on its Class object 
will return an array containing the same list of interfaces (in the 
order specified at its creation), [...]

In the current design Valhalla will add two interfaces - IdentityObject 
and ValueObject (afaik). One of them have to be implemented as well.
Also, because the superclass is java.lang.reflect.Proxy, and that class 
has a protected final field, it can currently not implement ValueObject.

An other thing are annotations - currently they are implemented using 
Proxies. This implementation detail surfaces when serializing an 
annotation. Other implementation strategies are possible - for example 
spinning a record at runtime.
But this leads to the question - how can one migrate away from 
serialized proxies in a compatible way?

In the end - a lot of stuff in the JDK depends on Proxies, and their 
limitations now begins to surface.

A new API may not be a bad idea. :)

- Johannes

From forax at univ-mlv.fr  Mon Apr 18 11:09:30 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 18 Apr 2022 13:09:30 +0200 (CEST)
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <fbf69cdb-f230-3c7d-8fe7-56dc0b2bcc00@j-kuhn.de>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
 <0dcb6adc-13b4-1319-bb0e-e0ec86f916bd@oracle.com>
 <fbf69cdb-f230-3c7d-8fe7-56dc0b2bcc00@j-kuhn.de>
Message-ID: <1028561197.13833547.1650280170453.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Johannes Kuhn" <info at j-kuhn.de>
> To: "Alan Bateman" <Alan.Bateman at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Monday, April 18, 2022 12:53:45 PM
> Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes

> On 18-Apr-22 9:36, Alan Bateman wrote:
>> On 17/04/2022 17:24, liach wrote:
>>> Convert dynamic proxies to hidden classes. Modifies the serialization
>>> of proxies (requires change in "Java Object Serialization
>>> Specification"). Makes the proxies hidden in stack traces. Removes
>>> duplicate logic in proxy building.
>>>
>>> The main compatibility changes and their rationales are:
>>> 1. Modification to the serialization specification: In the "An
>>> instance of the class is allocated... The contents restored
>>> appropriately" section, I propose explicitly state that handling of
>>> proxies are unspecified as to allow implementation freedom, though
>>> I've seen deliberate attempts for proxies to implement interfaces with
>>> `readResolve` in order to control their serialization behavior.
>>> ??? - This is for the existing generated constructor accessor is
>>> bytecode-based, which cannot refer to hidden classes.
>>> ??? - An alternative is to preserve the behavior, where the
>>> serialization constructor calls `invokespecial` on the closest
>>> serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>>> ??? - My rationale against preservation is such super calls are unsafe
>>> and should be discouraged in the long term. Calling the existing
>>> constructor with a dummy argument, as in my implementation, would be
>>> more safe.
>>> 2. The disappearance of proxies in stack traces.
>>> ??? - Same behavior exists in lambda expressions: For instance, in
>>> `((Runnable) () -> { throw new Error(); }).run();`, the `run` method,
>>> implemented by the lambda, will not appear in the stack trace, and
>>> isn't too problematic.
>> 
>> It's great that you have time to experiment in this area but just to set
>> expectations that it will likely require significant discussion and
>> maybe prototyping of alternatives. It suspect the Reviewer effort will
>> end up being many times the effort required to do the actual work
>> because of the compatibility and security issues that will need to be
>> worked through.
>> 
>> I think you need to add non-discoverability to the list of compatibility
>> issues. Do we know for sure that there aren't frameworks and libraries
>> that use Class.forName on proxy classes? We've had issues in the past
>> with changes in this area.
>> 
>> It's too early to say but it might be that the compatibility risks may
>> nudge this one into creating a new API.
>> 
>> -Alan.
>> 
>> 
>> 
> 
> Proxies will have to be rethought at some future point - wrt Valhalla.
> 
> The current specification says:
> 
> > A proxy class implements exactly the interfaces specified at its
> creation, in the same order. Invoking getInterfaces on its Class object
> will return an array containing the same list of interfaces (in the
> order specified at its creation), [...]
> 
> In the current design Valhalla will add two interfaces - IdentityObject
> and ValueObject (afaik). One of them have to be implemented as well.
> Also, because the superclass is java.lang.reflect.Proxy, and that class
> has a protected final field, it can currently not implement ValueObject.

Recently, we (the Valhalla EG) have decided that IdentityObject/ValueObject were not the right way to represent identity and value class.
So no problem anymore on that side.

> 
> An other thing are annotations - currently they are implemented using
> Proxies. This implementation detail surfaces when serializing an
> annotation. Other implementation strategies are possible - for example
> spinning a record at runtime.
> But this leads to the question - how can one migrate away from
> serialized proxies in a compatible way?
> 
> In the end - a lot of stuff in the JDK depends on Proxies, and their
> limitations now begins to surface.
> 
> A new API may not be a bad idea. :)

Yes !
And we can leverage invokedynamic/method handles to avoid boxing/ bad perf.
The idea is that first time an implementation of an abstract method is required, an object (implementing an interface similar to InvocationHandler) acting as a bootstrap method is called to provide a method handle that will be used as implementation.

see https://github.com/forax/hidden_proxy for a prototype of that idea.

> 
> - Johannes

R?mi

From jiefu at openjdk.java.net  Mon Apr 18 11:35:34 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 18 Apr 2022 11:35:34 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <2STdSZhmfGDaUrgu-er_9sh-ezFAn2Wa4E7BK9EVcYs=.8ebbc203-258e-4c96-96b0-bd77c98415a5@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <8Pt74pzAlOwdFRMskZan1Dn-Cfx2QuFLzGOSA6KgEJw=.a64237fc-6e6f-4d1b-8a75-ec1e13e6bf1e@github.com>
 <Ytzf_nSfjAxdNcgYu5OzEMRU4mgMjUrnTxYpeEbK850=.306faa5e-8039-432f-8379-dce76551ed6e@github.com>
 <6KvfGzFtMHq_9h5FDlpB4tmXNYqKL0kOQ93Tm94p3NI=.3b6741ec-e9f7-432a-b0e0-75180e2633c7@github.com>
 <HdN-Yas5mltyDfaHuexCpJvqfO5EfBIi4HqchCLR3Ig=.4f28ff95-65ea-40c1-bed2-8d78b55b3aad@github.com>
 <tz8KFjz-Zb3L8YdjqA6LO43ehYZ6eUE1GR7z8RGoEbA=.a193417c-862d-47db-bb58-4be443cb6f0a@github.com>
 <2STdSZhmfGDaUrgu-er_9sh-ezFAn2Wa4E7BK9EVcYs=.8ebbc203-258e-4c96-96b0-bd77c98415a5@github.com>
Message-ID: <az7pwyLD7EsXD9f6d8tJcNKN0CIoommxMYuysOExXUk=.214ac0f6-11fb-4419-a20a-8595378f418a@github.com>

On Mon, 18 Apr 2022 08:29:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> @DamonFool
>>> 
>>> I think the issue is that these two cases of yours are not equal semantically.
>> 
>> Why?
>> According to the vector api doc, they should compute the same value when the shift_cnt is 3, right?
>> 
>>> 
>>> ```
>>>  13     public static void urshift(byte[] src, byte[] dst) {
>>>  14         for (int i = 0; i < src.length; i++) {
>>>  15             dst[i] = (byte)(src[i] >>> 3);
>>>  16         }
>>>  17     }
>>>  18 
>>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>>  20         int i = 0;
>>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>>  22             var va = ByteVector.fromArray(spec, src, i);
>>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>>  24             vb.intoArray(dst, i);
>>>  25         }
>>>  26 
>>>  27         for (; i < src.length; i++) {
>>>  28             dst[i] = (byte)(src[i] >>> 3);
>>>  29         }
>>>  30     }
>>> ```
>>> 
>>> Besides the unsigned shift, line15 also has a type conversion which is missing in the vector api case. To get the equivalent result, one need to cast the result explicitly at line24, e.g, `((IntVector)vb.castShape(SPECISE_XXX, 0)).intoArray(idst, i);`
>> 
>> Since all the vector operations are already based on byte lane type, I don't think we need a `cast` operation here.
>> Can we solve this problem by inserting a cast operation?
>
>> @DamonFool
>> 
>> `>>>` can not apply to sub-word type in Java. `(byte)(src[i] >>> 3)` is unsigned right shift in type of INT and transformed the result to BYTE. In vector api, it extends the `>>>` to sub-word type with the same semantic meaning like `iushr`[1], that is zero extending.
>> 
>> > The vector api docs says it would compute a>>>(n&(ESIZE*8-1)).
>> 
>> I think `>>>` has some extending meanings here. As I said above, no sub-word type for `>>>` in Java.
>> 
>> [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.iushr
> 
> As discussed above https://github.com/openjdk/jdk/pull/8276#issuecomment-1101016904 , there isn't any problem to apply `>>>` upon shorts/bytes.
> 
> What do you think of https://github.com/openjdk/jdk/pull/7979 , which tries to vectorize unsigned shift right on signed subword types ?
> And what do you think of the benchmarks mentioned in that PR?
> 
> The vector api doc clearly states `LSHR` operator would compute `a>>>(n&(ESIZE*8-1))`.
> But it fails to do so when `a` is negative byte/short element.
> 
> So if the doc description is correct, the current implementation would be wrong, right?
> 
> However, if you think the current implementation is correct, the vector api doc would be wrong.
> Then, we would lack an operator working like the scalar `>>>` since current implementation fails to do so for negative bytes/shorts.

> Hi @DamonFool, the doc does obviously not mean what you think, and actually seems to indicate the Eric's interpretation instead. Simply because `a >>> (n & (ESIZE - 1))` does not output the type of `a` for subword-type inputs, which is clearly wrong. This suggests that the doc here should be interpreted that `>>>` is the extended shift operation, which is defined on subword types the same as for words and double-words. Though, I agree that the doc must be modified to reflect the intention more clearly.
> 


My intention is to make Vector API to be more friendly to Java developers.
The so called extended unsigned right shift operation for bytes/shorts actually behave differently with the well-known scalar `>>>`, which may become the source of bugs.


> > Then, we would lack an operator working like the scalar >>> since current implementation fails to do so for negative bytes/shorts.
> 
> As you have noted, we have `ASHR` for bytes, shorts and `LSHR` for ints, longs. Thanks a lot.


Then people have to be very careful about when to use `AHSR` and when to use `LSHR`, which is really inconvenient and easy to make a mistake.
And not all the people are smart enough to know this skill for bytes/shorts.
So simply modifying the vector api doc can't solve these problems.

Maybe, we can add one more operator to distinguish the semantics of scalar `>>>` with the so called extended unsigned right shift operation for bytes/shorts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Mon Apr 18 12:22:56 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 18 Apr 2022 12:22:56 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
Message-ID: <Zc9vO-S8MPEjjd5U-8VhnzihYLb19kXxldiKJcbJZek=.4e15aa71-5e99-4d94-bb56-aade1b620063@github.com>

On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 266:

> 264:      * contained in the flock
> 265:      * @throws jdk.incubator.concurrent.StructureViolationException if the current
> 266:       * scope-local bindings are not the same as when the flock was created

Suggestion:

     * scope-local bindings are not the same as when the flock was created

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From ksakata at openjdk.java.net  Mon Apr 18 12:55:40 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Mon, 18 Apr 2022 12:55:40 GMT
Subject: Integrated: 8283870: jdeprscan --help causes an exception when the
 locale is ja, zh_CN or de
In-Reply-To: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
Message-ID: <6_nPszRY-p_fncjw61Rb54xsCl5i6y6YfOd65V-GYDQ=.5985730a-b6af-4771-a71b-0c3254757780@github.com>

On Mon, 11 Apr 2022 05:31:49 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> # Summary
> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
> 
> # How to reproduce this issue
> 
> $ jdeprscan -J-Duser.language=ja --help
> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>         ... 8 more
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ?Same as above?
> 
> $ jdeprscan -J-Duser.language=de --help
> ?Same as above?
> 
> Of course, it works well when the locale is anything other than those locales.
> 
> # Details
> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
> 
> I removed extra single quotes.
> 
> # Test
> It seems there is no test class for it. So I run commands as I mentioned before.
> 
> $ jdeprscan -J-Duser.language=ja --help
> ????: jdeprscan [options] {dir|jar|class} ...
> 
> ?????:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ???API????????????????????????
> ???????????????????????JAR?????
> ?????????????????????????????
> ???????????????????????????????
> ????$????????:
> 
>     java.lang.Thread$State
> 
> --class-path?????????????????????
> ???????????
> 
> --for-removal??????????????????????????API?
> ????????????6?7???8????????????
> 
> --full-version????????????????????????????
> 
> --help (-? -h)?????????????????????????
> 
> --list (-l)?????????API???????????????????????
> ???????JAR??????????????????????
> 
> --release????????????????API?????????Java SE
> ???????????
> 
> --verbose (-v)????????????????????????????????
> 
> --version????????????????????????????????
> 
> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
> ???jdeprscan [options] {dir|jar|class} ...
> 
> ???
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> ????????????????? API?
> ???????????????JAR ???
> ????????????????
> ????????????? $ ???
> ?????????
> 
>     java.lang.Thread$State
> 
> --class-path ?????????????
> ?????
> 
> --for-removal ????????????????
> ? API???????? 6?7 ? 8 ?????
> 
> --full-version ???????????????
> 
> --help (-? -h) ????????????
> 
> --list (-l) ?????????? API???????
> ???????????jar ?????
> 
> --release ????????????? API ?
> ? Java SE ????
> 
> --verbose (-v) ????????????????
> 
> --version ???????????????
> 
> $ jdeprscan -J-Duser.language=de --help
> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
> 
> Optionen:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
> f?r verschachtelte Klassen angegeben werden. Beispiel:
> 
>     java.lang.Thread$State
> 
> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
> von abh?ngigen Klassen.
> 
> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
> 
> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
> 
> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
> 
> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
> 
> Die Option --release gibt das Java SE-Release an, das die Gruppe
> der veralteten APIS zum Scannen liefert.
> 
> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
> 
> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
> 
> $ jdeprscan -J-Duser.language=en --help                    
> Usage: jdeprscan [options] {dir|jar|class} ...
> 
> options:
>         --class-path PATH
>         --for-removal
>         --full-version
>   -? -h --help
>   -l    --list
>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>   -v    --verbose
>         --version
> 
> Scans each argument for usages of deprecated APIs. An argument
> may be a directory specifying the root of a package hierarchy,
> a JAR file, a class file, or a class name. The class name must be
> specified using a fully qualified class name using the $ separator
> character for nested classes, for example,
> 
>     java.lang.Thread$State
> 
> The --class-path option provides a search path for resolution
> of dependent classes.
> 
> The --for-removal option limits scanning or listing to APIs that are
> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
> 
> The --full-version option prints out the full version string of the tool.
> 
> The --help (-? -h) option prints out a full help message.
> 
> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
> so no directory, jar, or class arguments should be provided.
> 
> The --release option specifies the Java SE release that provides the set
> of deprecated APIs for scanning.
> 
> The --verbose (-v) option enables additional message output during processing.
> 
> The --version option prints out the abbreviated version string of the tool.

This pull request has now been integrated.

Changeset: ef25e189
Author:    Koichi Sakata <ksakata at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef25e189c7f987b6c7b049ce481ee832cc7f70aa
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8283870: jdeprscan --help causes an exception when the locale is ja, zh_CN or de

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8174

From smarks at openjdk.java.net  Mon Apr 18 16:09:45 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 18 Apr 2022 16:09:45 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <aNyUSJzlvcSuVVEJD89DyIy5SBa1gL7esaf3ZpuVpmQ=.98e6b339-c853-4a88-84e3-6c245a979a0f@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
 <qly5zkZEVyG6oOE3o_bbZUfJDmQJ-kGRDnIJCsbINBs=.685798e4-cd91-496c-aa1c-a9b68f75cd21@github.com>
 <aNyUSJzlvcSuVVEJD89DyIy5SBa1gL7esaf3ZpuVpmQ=.98e6b339-c853-4a88-84e3-6c245a979a0f@github.com>
Message-ID: <tFJ3b5yCpDPXua1sHEg_xM5CrDwtxJWKswdYhI4yXlA=.313e5ee7-2951-44f2-a507-5435a9c4110c@github.com>

On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Are the changes necessary for this part?
>> 
>> @seanjmullan no, they are just performance refinement.
>> 
>> If you really that wanna 100% sync ,
>> 
>> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java
>> 
>> Is this solution acceptable then?
>
>> > Are the changes necessary for this part?
>> 
>> @seanjmullan no, they are just performance refinement.
>> 
>> If you really that wanna 100% sync ,
>> 
>> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java
>> 
>> Is this solution acceptable then?
> 
> Yes, that would be preferred. Thanks!

I'd like to see a confirmation from @seanjmullan to make sure the issues with Santuario are resolved satisfactorily. Other than that I think it's pretty well covered. I've already run these changes through our internal test system and they look fine. I'll do a final recheck and let you know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From iklam at openjdk.java.net  Mon Apr 18 16:28:31 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 18 Apr 2022 16:28:31 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <1_Cx-O4f_jTPsnCdReReaPmZiMlbDSozf-wPlZPMpBE=.3c506da9-580e-470d-ba17-b95a2dbd512c@github.com>

On Mon, 18 Apr 2022 09:07:31 GMT, xpbob <duke at openjdk.java.net> wrote:

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 155:

> 153:         long memswBytes = getLongValue(controller, "memory.memsw.limit_in_bytes");
> 154:         long swappiness = getLongValue(controller, "memory.swappiness");
> 155:         return (memswBytes > 0 && swappiness > 0);

Does this also need to be changed in the test?

https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L291-L296

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From iklam at openjdk.java.net  Mon Apr 18 16:28:31 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 18 Apr 2022 16:28:31 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
In-Reply-To: <1_Cx-O4f_jTPsnCdReReaPmZiMlbDSozf-wPlZPMpBE=.3c506da9-580e-470d-ba17-b95a2dbd512c@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <1_Cx-O4f_jTPsnCdReReaPmZiMlbDSozf-wPlZPMpBE=.3c506da9-580e-470d-ba17-b95a2dbd512c@github.com>
Message-ID: <vwEbMEYGZxpqozojMVU0o_KVZW7RHFSIMIpc1GfvKJQ=.86ce962c-7098-403a-baf4-d0eb9238d9d0@github.com>

On Mon, 18 Apr 2022 16:22:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 155:
> 
>> 153:         long memswBytes = getLongValue(controller, "memory.memsw.limit_in_bytes");
>> 154:         long swappiness = getLongValue(controller, "memory.swappiness");
>> 155:         return (memswBytes > 0 && swappiness > 0);
> 
> Does this also need to be changed in the test?
> 
> https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L291-L296

There's also corresponding code in HotSpot:

https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L129-L150

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From mullan at openjdk.java.net  Mon Apr 18 16:44:35 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 18 Apr 2022 16:44:35 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21]
In-Reply-To: <aNyUSJzlvcSuVVEJD89DyIy5SBa1gL7esaf3ZpuVpmQ=.98e6b339-c853-4a88-84e3-6c245a979a0f@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <MfeVybsMaSvlclmeqgHD4I1wxhjyDBX-VcGYHgB0k9k=.f64012af-fe8e-4314-a30a-ed6badbaca13@github.com>
 <qly5zkZEVyG6oOE3o_bbZUfJDmQJ-kGRDnIJCsbINBs=.685798e4-cd91-496c-aa1c-a9b68f75cd21@github.com>
 <aNyUSJzlvcSuVVEJD89DyIy5SBa1gL7esaf3ZpuVpmQ=.98e6b339-c853-4a88-84e3-6c245a979a0f@github.com>
Message-ID: <EyXOY3fxlb41YZzKvAKXBs3bXvXU6DIkRYxaL1RCSXM=.d040f608-8306-4157-a6a0-3d65c10725e3@github.com>

On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> Are the changes necessary for this part?
>> 
>> @seanjmullan no, they are just performance refinement.
>> 
>> If you really that wanna 100% sync ,
>> 
>> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java
>> 
>> Is this solution acceptable then?
>
>> > Are the changes necessary for this part?
>> 
>> @seanjmullan no, they are just performance refinement.
>> 
>> If you really that wanna 100% sync ,
>> 
>> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java
>> 
>> Is this solution acceptable then?
> 
> Yes, that would be preferred. Thanks!

> I'd like to see a confirmation from @seanjmullan to make sure the issues with Santuario are resolved satisfactorily. Other than that I think it's pretty well covered. I've already run these changes through our internal test system and they look fine. I'll do a final recheck and let you know.

I am fine with this being integrated. @XenoAmess already [submitted a PR to the Santuario Project](https://github.com/apache/santuario-xml-security-java/pull/64) using the existing `HashMap` constructor which I have approved. So the code will be in sync the next time we upgrade the JDK to a newer version of Santuario.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:30 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:30 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v4]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <-R33j4QSbzRESFk8uh-J0EIgN15g4bqqt59oLXK5ddY=.bcdda047-e3ff-4c5e-ac6e-fcdfb0b939e0@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/ef7a7d6a..311d68a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=02-03

  Stats: 27 lines in 6 files changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:30 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:30 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
Message-ID: <d8f-1gDXt_jB7QFopFkl6m8n686V7rSW-XwPtq0Wrzk=.63fd1729-5258-480a-a409-acdb6cae7033@github.com>

On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup.

Thanks for the comments so far. I've reflected most of them here:
https://github.com/openjdk/jdk/pull/8182/commits/311d68a60200dc4d9928e5ea2854c22fbcf68596
please let me know what you think!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon Apr 18 17:27:31 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 18 Apr 2022 17:27:31 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v3]
In-Reply-To: <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <g4jxgLTEWeNTE1NVcrFAZJRBbY_wXYX9SnLVn-8xoWI=.87d30d97-1491-49be-b3bd-f78f7bec8552@github.com>
 <JozJia5Wjs5vWHG7hvtIXsw2GkAUFkmenl9Hye1SuAY=.894034f5-4178-4e46-bd76-c3c0c3b0a268@github.com>
Message-ID: <DADSwLVC8niNxSxBU7guAxmA_H-jWR44HEIPDrlcpKo=.7a6b084c-35d2-4cc7-8ae5-61c1f472c79e@github.com>

On Fri, 15 Apr 2022 15:36:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1779:
> 
>> 1777:                         //binding pattern
>> 1778:                         attribExpr(pat, switchEnv);
>> 1779:                         var primary = TreeInfo.primaryPatternType(pat);
> 
> general comment: the handleSwitch method is getting more and more complex, please consider refactoring it, probably splitting it, for example different subrutines handling different case kinds. Of course this probably should be done as a separate effort.

Thanks for the comment. I agree the method is fairly complex, but it is also a bit difficult to disentangle into separate methods. We've separated some of the checks to `Check.checkSwitchCaseStructure` before. I'll try to think of splitting it more, but I am not sure where that will lead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From mchung at openjdk.java.net  Mon Apr 18 17:29:40 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 18 Apr 2022 17:29:40 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <KlSxT_ZbOGgS6s1sP7M6m8q6bwnjZqzdaLiVqk-4sqg=.321c46b7-5616-4e04-9fb1-1092d9c625e9@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

It's good to see more experiment and prototype for this issue.   Like Alan said, the spec change, compatibility risks and security issues in particular on the serialization spec/impl change require lot of discussions and also prototyping of other alternatives.   A new API may also be one alternative to consider.

The current spec of Proxy class is defined with null protection domain (same protection domain as the bootstrap class loader). Lookup::defineHiddenClass defines the hidden class in the same protection domain as the defining class loader.   This would become a non-issue when the security manager is removed.  However, before the removal of security manager, we still need to look into the compatibility risks and what and how applications/libraries depend on this behavior. 

During the development of JEP 371, I had a prototype of converting dynamic proxies to hidden class by adding a shim class (that's what your prototype does).   That raises the question "how to get a Lookup on a package for the dynamic proxy class to be injected in without injecting a shim class (i.e. your anchor class)?"  This functionality could be considered as a separate RFE.    However, frameworks don't always have the access to inject a class in a package defined to a class loader.  This is something worth looking into.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From prappo at openjdk.java.net  Mon Apr 18 17:39:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 18 Apr 2022 17:39:45 GMT
Subject: Integrated: 8284922: Fix some doc-comment issues on methods with
 package access in JDK API
In-Reply-To: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
References: <KYuQmkyHDRdn-vlsci2tIlvVuoaVpJuxofzrbFUnZMs=.dffa2eb1-3fbc-4c89-a596-fe7b67707d4b@github.com>
Message-ID: <lMEDfge05evUAzdCbWlPYtE9yOdGi6Y4PNHR-Kq98oU=.2a2d28b5-f4f6-4749-93cf-11dd54cbf970@github.com>

On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed.
> 
> There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones.

This pull request has now been integrated.

Changeset: d3d71ea2
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d3d71ea289b7525d3f5c5057d995776be9a0796a
Stats:     6 lines in 3 files changed: 1 ins; 0 del; 5 mod

8284922: Fix some doc-comment issues on methods with package access in JDK API

Reviewed-by: darcy, iris, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8267

From rriggs at openjdk.java.net  Mon Apr 18 18:59:44 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 18 Apr 2022 18:59:44 GMT
Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in
 ProcessBuilder [v3]
In-Reply-To: <6d4WqaCOA9ZnCwAvOrbXs-cR1ZLAz6LDLd-e9Q3kCIY=.4e14c495-26ee-4d60-98ac-a3ee51ea5c4e@github.com>
References: <jPgf8MMtxpopBKcD5qjDtui-ugoZB2itFSZ6DHa9gRE=.127d22f4-80fd-4c1d-b304-9390946be1cb@github.com>
 <6d4WqaCOA9ZnCwAvOrbXs-cR1ZLAz6LDLd-e9Q3kCIY=.4e14c495-26ee-4d60-98ac-a3ee51ea5c4e@github.com>
Message-ID: <7y3SgCMh4-07zmZb2_vGmF-M8NC21V2MvzrAZkR29q8=.bb968965-8954-4802-b32c-e86f71e7fff8@github.com>

On Tue, 5 Apr 2022 16:39:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that
>> process builder recognized argument strings, causing some arguments to be doubly quoted and malformed.
>> 
>> ProcessBuilder encodes command arguments in two ways, a looser legacy encoding
>> and stricter encoding that prevents quotes from being misinterpreted.
>> The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect.
>> 
>> When the property is "true" or not set, arguments are inserted into the Windows command line
>> with minimal changes.  Arguments containing space or tab are quoted to prevent them being split.
>> Arguments that start and end with double-quote are left alone.
>> Some executables interpret a backslash before the final quote as an escape; if the argument 
>> contains first and last quotes, backslashes are ignored.
>> 
>> When the allowAmbigousCommands property is `false`, care is taken to ensure that
>> the final quote of an argument is the closing quote for the argument and is not
>> interpreted as a literal quote by a preceding quote (or an odd number of quotes).
>> 
>> The PR includes a test matrix of the cases where an argument with spaces and a final backslash
>> is passed with each combination of `allowAmbiguousCommands = true and false`,
>> launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes.
>> 
>> The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument.
>> In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly.
>> The trailing backslash in an argument occurs rarely exception when the argument is a directory.
>> In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path.
>> 
>> See also PR#7504, for background and a proposal.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8282008-quoted-escape
>  - Add count of skipped tests and improve comments
>  - Refactored ArgCheck test to be more readable and easier to maintain and backport
>  - Cleanup comment and copyright
>  - JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder

This change required a CSR, now approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7709

From rriggs at openjdk.java.net  Mon Apr 18 19:07:35 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 18 Apr 2022 19:07:35 GMT
Subject: Integrated: JDK-8282008: Incorrect handling of quoted arguments in
 ProcessBuilder
In-Reply-To: <jPgf8MMtxpopBKcD5qjDtui-ugoZB2itFSZ6DHa9gRE=.127d22f4-80fd-4c1d-b304-9390946be1cb@github.com>
References: <jPgf8MMtxpopBKcD5qjDtui-ugoZB2itFSZ6DHa9gRE=.127d22f4-80fd-4c1d-b304-9390946be1cb@github.com>
Message-ID: <FDrmIicy5ZCHjXzFEYuhNxTqQbyNaaedMsFgsrDtG60=.9da83be7-8461-4369-9f5c-3b0182a76d77@github.com>

On Fri, 4 Mar 2022 23:20:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that
> process builder recognized argument strings, causing some arguments to be doubly quoted and malformed.
> 
> ProcessBuilder encodes command arguments in two ways, a looser legacy encoding
> and stricter encoding that prevents quotes from being misinterpreted.
> The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect.
> 
> When the property is "true" or not set, arguments are inserted into the Windows command line
> with minimal changes.  Arguments containing space or tab are quoted to prevent them being split.
> Arguments that start and end with double-quote are left alone.
> Some executables interpret a backslash before the final quote as an escape; if the argument 
> contains first and last quotes, backslashes are ignored.
> 
> When the allowAmbigousCommands property is `false`, care is taken to ensure that
> the final quote of an argument is the closing quote for the argument and is not
> interpreted as a literal quote by a preceding quote (or an odd number of quotes).
> 
> The PR includes a test matrix of the cases where an argument with spaces and a final backslash
> is passed with each combination of `allowAmbiguousCommands = true and false`,
> launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes.
> 
> The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument.
> In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly.
> The trailing backslash in an argument occurs rarely exception when the argument is a directory.
> In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path.
> 
> See also PR#7504, for background and a proposal.

This pull request has now been integrated.

Changeset: 897d6c0d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/897d6c0dc7cdfb3ad92f864f9ad4b50e642197e4
Stats:     343 lines in 2 files changed: 332 ins; 6 del; 5 mod

8282008: Incorrect handling of quoted arguments in ProcessBuilder

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.java.net/jdk/pull/7709

From duke at openjdk.java.net  Mon Apr 18 20:01:39 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 18 Apr 2022 20:01:39 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <ERADd8oF-_ddjGCVRE8XpNNiRrGR5Pe2uCf0fHa2hGA=.1df49f9a-f894-46fb-97b9-399fc218db01@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

I strongly recommend a new API over revamping `Proxy` itself. https://github.com/forax/hidden_proxy would be a good prototype that serves most needs of the current Proxy API (except a few, like invoking default superinterface method). With hidden classes, I don't see much value in leaving the new API's produced instance in separate modules; what we have for hidden classes should be fine for the most part.

Imo the main obstacle is still the handling of serialization. The annotations are serializable, but currently hidden classes do not work with serialization at all and must use `writeReplace` and `readResolve`. And how to migrate annotations off proxies without breaking serialization is still a question as well. Maybe we can upgrade invocation handlers to allow them to declare custom `readResolve` logic for the proxy to facilitate migration away. How the new API will treat serialization is still undetermined.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From duke at openjdk.java.net  Mon Apr 18 20:11:32 2022
From: duke at openjdk.java.net (jmehrens)
Date: Mon, 18 Apr 2022 20:11:32 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
Message-ID: <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>

On Fri, 15 Apr 2022 18:56:37 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to liach operation.

> @jmehrens what about this then? I think it safe now(actually this mechanism is learned from Reader)

Reader uses a lock object and it appears that InputStream locks on this (per make/reset)  I would assume now that you have some object member fields you need to hold some lock while accessing those.  Even though single thread access would be the expected case.

Not related but, it looks like the static buffer issue has come up a few times.  Maybe time to add a test to: https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/InputStream/Skip.java that would fail if the skip buffer is static?

Not really the primary issue but, it seems questionable to me that we don't have to fill the skip buffer with zeros after the last read.  That way any sensitive information that was skipped would also be forgotten.  Matching with Reader seems more important for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From forax at univ-mlv.fr  Mon Apr 18 20:41:26 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 18 Apr 2022 22:41:26 +0200 (CEST)
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <ERADd8oF-_ddjGCVRE8XpNNiRrGR5Pe2uCf0fHa2hGA=.1df49f9a-f894-46fb-97b9-399fc218db01@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
 <ERADd8oF-_ddjGCVRE8XpNNiRrGR5Pe2uCf0fHa2hGA=.1df49f9a-f894-46fb-97b9-399fc218db01@github.com>
Message-ID: <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "liach" <duke at openjdk.java.net>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at openjdk.java.net>
> Sent: Monday, April 18, 2022 10:01:39 PM
> Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes

> On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:
> 
>> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies
>> (requires change in "Java Object Serialization Specification"). Makes the
>> proxies hidden in stack traces. Removes duplicate logic in proxy building.
>> 
>> The main compatibility changes and their rationales are:
>> 1. Modification to the serialization specification: In the "An instance of the
>> class is allocated... The contents restored appropriately" section, I propose
>> explicitly state that handling of proxies are unspecified as to allow
>> implementation freedom, though I've seen deliberate attempts for proxies to
>> implement interfaces with `readResolve` in order to control their serialization
>> behavior.
>>    - This is for the existing generated constructor accessor is bytecode-based,
>>    which cannot refer to hidden classes.
>>    - An alternative is to preserve the behavior, where the serialization
>>    constructor calls `invokespecial` on the closest serializable superclass'
>>    no-arg constructor, like in #1830 by @DasBrain.
>>    - My rationale against preservation is such super calls are unsafe and should be
>>    discouraged in the long term. Calling the existing constructor with a dummy
>>    argument, as in my implementation, would be more safe.
>> 2. The disappearance of proxies in stack traces.
>>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) ()
>>    -> { throw new Error(); }).run();`, the `run` method, implemented by the
>>    lambda, will not appear in the stack trace, and isn't too problematic.
>> 
>> A summary of the rest of the changes:
>> 1. Merged the two passes of determining module and package of the proxy into
>> one. This reduced a lot of code and allowed anchor class (for hidden class
>> creation) selection be done together as well.
>> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of
>> `java.base`. This API is intended for implementation of legacy (pre
>> `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more
>> complex tricks to obtain proper permissions as lookups.
>> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959):
>> passes methods computed by proxy generator as class data to the hidden proxy
>> class to reduce generated proxy class size and improve performance.
>> 
>> In addition, since this change is somewhat large, should we keep the old proxy
>> generator as well and have it toggled through a command-line flag (like the old
>> v49 proxy generator or the old reflection implementation)?
>> 
>> Please feel free to comment or review. This change definitely requires a CSR,
>> but I have yet to determine what specifications should be changed.
> 
> I strongly recommend a new API over revamping `Proxy` itself.
> https://github.com/forax/hidden_proxy would be a good prototype that serves
> most needs of the current Proxy API (except a few, like invoking default
> superinterface method). 

The third parameter of defineProxy() is a lambda which is called for each method that can be overriden, either toString/equals/hashCode but also any default methods,
if the lambda return true, the method is overriden, otherwise the default implementation is used.

> With hidden classes, I don't see much value in leaving
> the new API's produced instance in separate modules; what we have for hidden
> classes should be fine for the most part.
> 
> Imo the main obstacle is still the handling of serialization. The annotations
> are serializable, but currently hidden classes do not work with serialization
> at all and must use `writeReplace` and `readResolve`. And how to migrate
> annotations off proxies without breaking serialization is still a question as
> well. Maybe we can upgrade invocation handlers to allow them to declare custom
> `readResolve` logic for the proxy to facilitate migration away. How the new API
> will treat serialization is still undetermined.

yes, i suppose that like with lambdas, we need a special overload of defineProxy that automatically implements writeReplace() and use a specific class SerializableProxy (mirroring how SerializableLambda works).

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/8278

From smarks at openjdk.java.net  Mon Apr 18 22:37:36 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 18 Apr 2022 22:37:36 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22]
In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
Message-ID: <FMJxnq_vpsnhfQ17SucDCfYvoXbmSt61zTQKt13AArY=.54c3ea4a-25be-4858-84ef-54822251c9a8@github.com>

On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.xml.crypto's usage downgrade grammar to 1.8

Marked as reviewed by smarks (Reviewer).

OK, go ahead and integrate!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From alexey.semenyuk at oracle.com  Mon Apr 18 22:41:05 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 18 Apr 2022 18:41:05 -0400
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
 <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
 <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>
Message-ID: <3039fd70-e60f-33a7-23c8-29dae8327d1b@oracle.com>



On 4/17/2022 2:22 PM, Hiran Chaudhuri wrote:
> On Thu, 2022-04-07 at 19:53 -0400, Alexey Semenyuk wrote:
>
>> I can see two separate issues with jpackage:
>    1. jpackage reports NPE if it can't figure out the package name
>> from
>> the supplied application image. It should issue a helpful error
>> message
>> instead
>>    2. jpackage fails to populate application image with Java runtime
>> and
>> app specific files when executed in Github but exits with "0" status
>> indicating no error
>>
> I totally agree these are two separate issues.
>
>> The major problem in your use case is that jpackage doesn't create
>> correct application image. Instead, it creates only a directory
>> structure of application image, but no files and exits with a
>> "success"
>> status code. This is quite strange. Is there any chance Gradle
>> ignores
>> non-zero exit code from jpackage execution? Can you directly run
>> jpackage command creating application image in the environment where
>> it
>> outputs "empty" application image and check its exit code (please
>> add
>> "--verbose" to jpackage command line to get debug output)?
>>
>> - Alexey
>>
> Now this is somewhat puzzling for me:
> I tried to factor out Gradle by putting the JPackage commands into a
> separate section of the Github Actions script. So now it is invoked
> through bash.
>
> No wonder, the command triggered by Gradle and the one triggered by
> bash revealed the same result: A lot of files were missing. I verified
> this by listing the directories through a 'find'.
>
> But then I followed your advice and added --verbose to the JPackage
> command. And find lists a lot more files now.
>
> In case you are interested, check out
> https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/5890636608?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!fMwHRzbnvjiQPsoiuBB1Cnl4RNGxATH4RHnb3Ugy-dlsPTPHLoqOF2uSYcFRkfaSYHQA$
Thank you for sharing. I find this piece of log interesting:
---
[19:28:24.553] Command [PID: -1]:
 ??? jlink --output app/build/app-image/SettlersRemake/lib/runtime 
--module-path /usr/lib/jvm/temurin-17-jdk-amd64/jmods --add-modules 
jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.transaction.xa,java.logging,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.net,jdk.random,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata 
--strip-native-commands --strip-debug --no-man-pages --no-header-files
---
It is not quite right that pid of jlink invocation is reported as "-1". 
jlnk fills runtime directory in app image. Something if off here, 
invocation of jlink in non-verbose mode fails. In the verbose mode, 
jpackage saves command lines and output of all external tools it invokes 
and prints saved data to the console.
At least there is a workaround for the issue - add "--verbose" to 
jpackage command line.

I've filed [1] and [2] CRs to track the issues.

[1] https://bugs.openjdk.java.net/browse/JDK-8284973
[2] https://bugs.openjdk.java.net/browse/JDK-8284974

- Alexey

>
> So now I believe that --verbose does not only change log output but
> also impacts app-image creation. BTW, the command used is
>
> jpackage --verbose --type app-image --dest app/build/app-image -i
> app/build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-
> SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake
> --app-version 0.1.0-SNAPSHOT --description 'Settlers 3 remake - see
> https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!fMwHRzbnvjiQPsoiuBB1Cnl4RNGxATH4RHnb3Ugy-dlsPTPHLoqOF2uSYcFRkQh1q_el$ ' --vendor Hiran, --icon
> app/build/resources/main/siedler3-helme-logo.png --resource-dir
> app/build/resources/jpackage
>
> Hiran
>


From mchung at openjdk.java.net  Mon Apr 18 22:49:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 18 Apr 2022 22:49:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
Message-ID: <umssWK2w8T8GlECY5hqhNACFePlBy7T74ie1jjcns70=.d13a9ba8-4064-4d6a-85e8-a0dd0aa7d8d7@github.com>

On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655:

> 653:      * synchronization control.  It might be an expensive operation.
> 654:      * Its behavior with cycles involving virtual threads is not defined
> 655:      * in this release.

What does the current implementation return if the virtual threads are involved in a deadlock?    The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined.    I wonder if it's helpful to include `@implNote` if appropriate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From hiran.chaudhuri at gmx.net  Mon Apr 18 23:06:38 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Tue, 19 Apr 2022 01:06:38 +0200
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <3039fd70-e60f-33a7-23c8-29dae8327d1b@oracle.com>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
 <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
 <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>
 <3039fd70-e60f-33a7-23c8-29dae8327d1b@oracle.com>
Message-ID: <e0e83867dd51406d2e70d6a8c62619f6a607edd7.camel@gmx.net>

On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote:
>
> I've filed [1] and [2] CRs to track the issues.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8284973
> [2] https://bugs.openjdk.java.net/browse/JDK-8284974
>
> - Alexey

Sounds great. Thank you.

While we are at improving JPackage, there are a few more items I
stumbled over:

a) When running jpackage on Linux, a freedesktop.org style starter file
is created - but one more line in there would make it a lot more
usable:
https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file

b) The solution is to override resource files. Meanwhile I found out
the resource files are templates, and jpackage replaces specific
strings in these files. This however is nowhere mentioned in the
documentation.

c) Running jpackage in two phases as I do (1: create app-image, 2:
create final package) I learned that --name has to be specified in both
runs. When running jpackage on MacOS however the second run needs the
application name postfixed with .app otherwise jpackage won't find the
directory it created in the first run. See the logs
https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true
and
https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true

Hiran


From smarks at openjdk.java.net  Tue Apr 19 00:07:57 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 19 Apr 2022 00:07:57 GMT
Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22]
In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
 <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com>
Message-ID: <_Chw5faR5IlUHqflJ7FT4npMIOh0ECjpCQdDH4cE0D8=.bb789c23-043a-4515-8c39-0f940b514711@github.com>

On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.xml.crypto's usage downgrade grammar to 1.8

I've also written a release note for this change. Please review.

https://bugs.openjdk.java.net/browse/JDK-8284975

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Tue Apr 19 00:07:58 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 00:07:58 GMT
Subject: Integrated: 8186958: Need method to create pre-sized HashMap
In-Reply-To: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
References: <b1auRA11Xb5Xj8Eu7Px5vr0sxJcNFKQi1pI7u80locI=.1298ae4e-e1ed-4f45-9c60-d016447b1c4a@github.com>
Message-ID: <bukTGFJeLVL8jfUnsTK62koP8mbOJOkS_6HzxMWKa9g=.f8f10ead-3842-4be1-9b6f-4ec83baf98f5@github.com>

On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> 8186958: Need method to create pre-sized HashMap

This pull request has now been integrated.

Changeset: 87faa85c
Author:    XenoAmess <xenoamess at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/87faa85c59e94d66c3c61d997eacdd2dbe5a1772
Stats:     212 lines in 30 files changed: 139 ins; 4 del; 69 mod

8186958: Need method to create pre-sized HashMap

Reviewed-by: chegar, naoto, joehw, lancea, wetmore, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7928

From duke at openjdk.java.net  Tue Apr 19 00:08:29 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 19 Apr 2022 00:08:29 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers [v2]
In-Reply-To: <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
 <d3rhKjCLyykV70wCEiLKufMRwAffeb5JXan6WUFlsk4=.173afeaa-1627-44bf-8bf9-eaa4f0f5dcbb@github.com>
Message-ID: <oQji-qCgskcE4Z8W99kOA9qeAC4vGS_JxraYnI0kOf4=.372f1168-b9fd-4dc9-8d88-4d7be2b4a68d@github.com>

On Thu, 14 Apr 2022 22:27:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout fix_8186958
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/8253

From mchung at openjdk.java.net  Tue Apr 19 00:09:37 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 00:09:37 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
Message-ID: <StEU_-PRsvgxbih_f4mNtCPXVIxfldoH64qX5EYy_oM=.8317a652-11e2-4a63-9707-89f9968bdb3a@github.com>

On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206:

> 204:         throws IllegalArgumentException, InterruptedException {
> 205:         if (timeout < 0) throw new IllegalArgumentException("Negative timeout value");
> 206:         if (timeout == 0) return remove();

Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file.


        if (timeout < 0)
            throw new IllegalArgumentException("Negative timeout value");
        if (timeout == 0)
            return remove();

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Tue Apr 19 01:31:24 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 01:31:24 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
 <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr>
Message-ID: <dflEb008FoSJGaW2MMbcvbxab9Wl9D31R6EHPSABfKo=.9b7fb301-43d0-4915-b059-bedc8b57dea6@github.com>

On Mon, 18 Apr 2022 20:42:48 GMT, Remi Forax <forax at univ-mlv.fr> wrote:

> The third parameter of defineProxy() is a lambda which is called for each method that can be overriden, either toString/equals/hashCode but also any default methods,
if the lambda return true, the method is overriden, otherwise the default implementation is used.

Not quite, I mean calling default implementations in the super interface, consider:

interface Root { void cleanUp(); }
interface FeatureOne extends Root { default void cleanUp() { /* do something */ } }
interface FeatureTwo extends Root { default void cleanUp() { /* do something */ } }

My proxy implements both feature one and two, but in your API, there is no way for my `cleanUp` to call both `FeatureOne.super.cleanUp();` and `FeatureTwo.super.cleanUp();`. You should probably expose the lookup in your linker too, especially that you enabled nest access and you can just use that lookup to resolve, say, an implementation static method in the proxy user class.

Also the "delegate" in your API would significantly benefit from https://bugs.openjdk.java.net/browse/JDK-8282798 (#7744), too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From dholmes at openjdk.java.net  Tue Apr 19 01:44:44 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 19 Apr 2022 01:44:44 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <u7GPGAj5ADbPVnP0e7osttH-s6wztA0LLJtbZnhfz2g=.1734d027-8090-4865-96bf-df2be8da596b@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

See main comment

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8222

From mchung at openjdk.java.net  Tue Apr 19 02:03:35 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 02:03:35 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
Message-ID: <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>

On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/System.java line 2173:

> 2171: 
> 2172:         // start Finalizer and Reference Handler threads
> 2173:         SharedSecrets.getJavaLangRefAccess().startThreads();

I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line.   Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available.  With this change, `JavaLangAccess` is already set.

src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61:

> 59:     private final Condition notEmpty;
> 60: 
> 61:     void signal() { notEmpty.signalAll(); }

`signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`.  Good to make them private.

src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138:

> 136:      *
> 137:      * @param  outputFile the path to the file to create
> 138:      * @param  format the format to use (TEXT_PLAIN or JSON)

It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Tue Apr 19 02:47:24 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 19 Apr 2022 02:47:24 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <gtCtOTC9C-W30vmNLWBBKgg9YCrQhahQ-UdaD6XEUdI=.9170d2c3-d5bf-49f5-b489-46f9a5453352@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

I see, however, I preserve the opinion that the API doc implies the extended unsigned right shift not the original `>>>` (or the output types would be wrong). So, I think you can create another operator that perform the scalar `>>>` if it is needed.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Tue Apr 19 03:29:25 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 19 Apr 2022 03:29:25 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
In-Reply-To: <vwEbMEYGZxpqozojMVU0o_KVZW7RHFSIMIpc1GfvKJQ=.86ce962c-7098-403a-baf4-d0eb9238d9d0@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <1_Cx-O4f_jTPsnCdReReaPmZiMlbDSozf-wPlZPMpBE=.3c506da9-580e-470d-ba17-b95a2dbd512c@github.com>
 <vwEbMEYGZxpqozojMVU0o_KVZW7RHFSIMIpc1GfvKJQ=.86ce962c-7098-403a-baf4-d0eb9238d9d0@github.com>
Message-ID: <lo-mFJRNvdQoc90QOsNBfPL3ETmoMvULXuhAeQJPucc=.0d32764a-ebcd-4a8d-bf2d-343c4981062f@github.com>

On Mon, 18 Apr 2022 16:25:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 155:
>> 
>>> 153:         long memswBytes = getLongValue(controller, "memory.memsw.limit_in_bytes");
>>> 154:         long swappiness = getLongValue(controller, "memory.swappiness");
>>> 155:         return (memswBytes > 0 && swappiness > 0);
>> 
>> Does this also need to be changed in the test?
>> 
>> https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L291-L296
>
> There's also corresponding code in HotSpot:
> 
> https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L129-L150

> Does this also need to be changed in the test?
> 
> https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L291-L296


This condition returns false,The following code is skipped
https://github.com/openjdk/jdk/blob/c63fabe3d582ce0828b04b0224cea49aab5fedf3/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L284

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From naoto at openjdk.java.net  Tue Apr 19 03:35:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 03:35:06 GMT
Subject: RFR: 8284856: Add a test case for checking UnicodeScript entity
 numbers [v3]
In-Reply-To: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
Message-ID: <p8CaiZEpIBqplsGaGrbFpjYnOBLTI9F7WL-evWLxil8=.86ff5f30-d22c-45fa-9779-c9b2f8017d66@github.com>

> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' into JDK-8284856
 - Fixed a typo
 - 8284856: Add a test case for checking UnicodeScript entity numbers
 - add `@LastModified: Apr 2022` to DocumentCache
 - revert changes on ProcessEnvironment
 - fix usage in XSAttributeChecker
 - update LastModified
 - Copyright latest year to 2022
 - revert changes in:
   src/java.desktop
   src/java.management
   src/jdk.internal.vm.ci
   src/jdk.jfr
   src/jdk.management.jfr
   src/jdk.management
   src/utils/IdealGraphVisualizer
 - Add apiNote to appropriate constructors of HM, LHM, and WHM.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/145dfed0...2a5f3f72

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8253/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8253&range=02
  Stats: 13 lines in 2 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8253/head:pull/8253

PR: https://git.openjdk.java.net/jdk/pull/8253

From ksakata at openjdk.java.net  Tue Apr 19 03:42:27 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 19 Apr 2022 03:42:27 GMT
Subject: RFR: 8283870: jdeprscan --help causes an exception when the locale
 is ja, zh_CN or de [v2]
In-Reply-To: <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
References: <IN0362dnhMMdQwXZHg_0tTBFol14wAgXujKSNh0bMvk=.1c50477b-c0ee-48d0-a310-ea012fc953b4@github.com>
 <G59q30-PdVEX5B2ZQjNvfL4truGmgawOCKfeegYvnpE=.2417a751-1e62-4616-bf83-95dcb1c598a1@github.com>
Message-ID: <e4bEVxoUnJZFBq9oa4_21zn6QtIEawId2gaYcbTXY3E=.695deb39-8786-4875-93ad-aa0ef5693c8f@github.com>

On Tue, 12 Apr 2022 06:36:29 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> # Summary
>> Running jdeprscan with --help option causes an exception on any OSs when the locale is ja, zh_CN or de.
>> 
>> # How to reproduce this issue
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: dir|jar|class
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1454)
>>         at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:492)
>>         at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371)
>>         at java.base/java.text.MessageFormat.format(MessageFormat.java:860)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Messages.get(Messages.java:62)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.printHelp(Main.java:706)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.run(Main.java:529)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.call(Main.java:717)
>>         at jdk.jdeps/com.sun.tools.jdeprscan.Main.main(Main.java:725)
>> Caused by: java.lang.NumberFormatException: For input string: "dir|jar|class"
>>         at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:668)
>>         at java.base/java.lang.Integer.parseInt(Integer.java:786)
>>         at java.base/java.text.MessageFormat.makeFormat(MessageFormat.java:1452)
>>         ... 8 more
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ?Same as above?
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> ?Same as above?
>> 
>> Of course, it works well when the locale is anything other than those locales.
>> 
>> # Details
>> I found **''**{dir|jar|class}**''** in both ja and zh_CN properties files. Doubled single quotes mean a single quote in MessageFormat class, so the class recognizes {dir|jar|class} as a FormatElement and throws the exception. 
>> 
>> I removed extra single quotes.
>> 
>> # Test
>> It seems there is no test class for it. So I run commands as I mentioned before.
>> 
>> $ jdeprscan -J-Duser.language=ja --help
>> ????: jdeprscan [options] {dir|jar|class} ...
>> 
>> ?????:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ???API????????????????????????
>> ???????????????????????JAR?????
>> ?????????????????????????????
>> ???????????????????????????????
>> ????$????????:
>> 
>>     java.lang.Thread$State
>> 
>> --class-path?????????????????????
>> ???????????
>> 
>> --for-removal??????????????????????????API?
>> ????????????6?7???8????????????
>> 
>> --full-version????????????????????????????
>> 
>> --help (-? -h)?????????????????????????
>> 
>> --list (-l)?????????API???????????????????????
>> ???????JAR??????????????????????
>> 
>> --release????????????????API?????????Java SE
>> ???????????
>> 
>> --verbose (-v)????????????????????????????????
>> 
>> --version????????????????????????????????
>> 
>> $ jdeprscan -J-Duser.language=zh -J-Duser.country=CN --help
>> ???jdeprscan [options] {dir|jar|class} ...
>> 
>> ???
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> ????????????????? API?
>> ???????????????JAR ???
>> ????????????????
>> ????????????? $ ???
>> ?????????
>> 
>>     java.lang.Thread$State
>> 
>> --class-path ?????????????
>> ?????
>> 
>> --for-removal ????????????????
>> ? API???????? 6?7 ? 8 ?????
>> 
>> --full-version ???????????????
>> 
>> --help (-? -h) ????????????
>> 
>> --list (-l) ?????????? API???????
>> ???????????jar ?????
>> 
>> --release ????????????? API ?
>> ? Java SE ????
>> 
>> --verbose (-v) ????????????????
>> 
>> --version ???????????????
>> 
>> $ jdeprscan -J-Duser.language=de --help
>> Verwendung: jdeprscan [Optionen] {dir|jar|class} ...
>> 
>> Optionen:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scannt jedes Argument auf die Verwendung veralteter APIs. Ein Argument
>> kann ein Verzeichnis, das die Root einer Packagehierarchie angibt,
>> eine JAR-Datei, eine Klassendatei oder ein Klassenname sein. Der Klassenname
>> muss durch einen vollst?ndig qualifizierten Klassennamen mit $ als Trennzeichen
>> f?r verschachtelte Klassen angegeben werden. Beispiel:
>> 
>>     java.lang.Thread$State
>> 
>> Die Option --class-path liefert einen Suchpfad f?r die Aufl?sung
>> von abh?ngigen Klassen.
>> 
>> Die Option --for-removal begrenzt das Scannen oder Auflisten auf APIs, die veraltet sind
>> und entfernt werden sollen. Kann nicht mit den Releasewerten 6, 7, oder 8 verwendet werden.
>> 
>> Die Option --full-version gibt die vollst?ndige Versionszeichenfolge des Tools aus.
>> 
>> Die Option --help (-? -h) gibt eine vollst?ndige Hilfemeldung aus.
>> 
>> Die Option --list (-l) gibt die Gruppe der veralteten APIs aus. Es wird nicht gescannt,
>> daher d?rfen keine Verzeichnis-, JAR- oder Klassenargumente angegeben werden.
>> 
>> Die Option --release gibt das Java SE-Release an, das die Gruppe
>> der veralteten APIS zum Scannen liefert.
>> 
>> Die Option --verbose (-v) aktiviert die Ausgabe zus?tzlicher Meldungen w?hrend der Verarbeitung.
>> 
>> Die Option --version gibt die verk?rzte Versionszeichenfolge des Tools aus.
>> 
>> $ jdeprscan -J-Duser.language=en --help                    
>> Usage: jdeprscan [options] {dir|jar|class} ...
>> 
>> options:
>>         --class-path PATH
>>         --for-removal
>>         --full-version
>>   -? -h --help
>>   -l    --list
>>         --release 7|8|9|10|11|12|13|14|15|16|17|18|19
>>   -v    --verbose
>>         --version
>> 
>> Scans each argument for usages of deprecated APIs. An argument
>> may be a directory specifying the root of a package hierarchy,
>> a JAR file, a class file, or a class name. The class name must be
>> specified using a fully qualified class name using the $ separator
>> character for nested classes, for example,
>> 
>>     java.lang.Thread$State
>> 
>> The --class-path option provides a search path for resolution
>> of dependent classes.
>> 
>> The --for-removal option limits scanning or listing to APIs that are
>> deprecated for removal. Cannot be used with a release value of 6, 7, or 8.
>> 
>> The --full-version option prints out the full version string of the tool.
>> 
>> The --help (-? -h) option prints out a full help message.
>> 
>> The --list (-l) option prints out the set of deprecated APIs. No scanning is done,
>> so no directory, jar, or class arguments should be provided.
>> 
>> The --release option specifies the Java SE release that provides the set
>> of deprecated APIs for scanning.
>> 
>> The --verbose (-v) option enables additional message output during processing.
>> 
>> The --version option prints out the abbreviated version string of the tool.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary single quotes in the German file

Thank you for sponsoring, Naoto.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8174

From jiefu at openjdk.java.net  Tue Apr 19 03:44:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 19 Apr 2022 03:44:30 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <gtCtOTC9C-W30vmNLWBBKgg9YCrQhahQ-UdaD6XEUdI=.9170d2c3-d5bf-49f5-b489-46f9a5453352@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <gtCtOTC9C-W30vmNLWBBKgg9YCrQhahQ-UdaD6XEUdI=.9170d2c3-d5bf-49f5-b489-46f9a5453352@github.com>
Message-ID: <FajULnsspDBkBkIW3K7fyMETsOUeCPJ4tPALRMzQO8c=.442a69ea-47a5-4fc3-8163-fa34a8ed116f@github.com>

On Tue, 19 Apr 2022 02:43:33 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I see, however, I preserve the opinion that the API doc implies the extended unsigned right shift not the original `>>>` (or the output types would be wrong). So, I think you can create another operator that perform the scalar `>>>` if it is needed.
> 
> Thank you very much.

Thanks @merykitty for your understanding.

After the discussion, I got the point that the original implementation of `LSHR` for bytes/shorts is useful and needed.
So let's just keep it.

Yes, we think the operator for scalar `>>>` is needed for several reasons:
1. We do have scalar `>>>` upon bytes/shorts in real programs.
2. There is usually no guarantee that all the operands would be non-negative for `>>>`.
3. Make it to be programmed more easily and also reduce the possibility to make mistakes.

Java developers would be happy and appreciated with that operator I believe. 
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From forax at univ-mlv.fr  Tue Apr 19 06:01:11 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 19 Apr 2022 08:01:11 +0200 (CEST)
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <dflEb008FoSJGaW2MMbcvbxab9Wl9D31R6EHPSABfKo=.9b7fb301-43d0-4915-b059-bedc8b57dea6@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
 <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr>
 <dflEb008FoSJGaW2MMbcvbxab9Wl9D31R6EHPSABfKo=.9b7fb301-43d0-4915-b059-bedc8b57dea6@github.com>
Message-ID: <1446733181.14034873.1650348071923.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "liach" <duke at openjdk.java.net>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at openjdk.java.net>
> Sent: Tuesday, April 19, 2022 3:31:24 AM
> Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes

> On Mon, 18 Apr 2022 20:42:48 GMT, Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> The third parameter of defineProxy() is a lambda which is called for each method
>> that can be overriden, either toString/equals/hashCode but also any default
>> methods,
> if the lambda return true, the method is overriden, otherwise the default
> implementation is used.
> 
> Not quite, I mean calling default implementations in the super interface,
> consider:
> 
> interface Root { void cleanUp(); }
> interface FeatureOne extends Root { default void cleanUp() { /* do something */
> } }
> interface FeatureTwo extends Root { default void cleanUp() { /* do something */
> } }
> 
> My proxy implements both feature one and two, but in your API, there is no way
> for my `cleanUp` to call both `FeatureOne.super.cleanUp();` and
> `FeatureTwo.super.cleanUp();`. You should probably expose the lookup in your
> linker too, especially that you enabled nest access and you can just use that
> lookup to resolve, say, an implementation static method in the proxy user
> class.

yes, you are right, i should send the Lookup too.

> 
> Also the "delegate" in your API would significantly benefit from
> https://bugs.openjdk.java.net/browse/JDK-8282798 (#7744), too.

I don't think i need the carrier API, the idea is to have only one field in the proxy, this field can be a value type (exactly a primitive class) in the future, so being expanded into multiple fields by the VM at runtime.

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/8278

From sminervini.prism at protonmail.com  Tue Apr 19 06:10:21 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Tue, 19 Apr 2022 06:10:21 +0000
Subject: Floating Point Correction Implementation?
Message-ID: <BLR1XFIoinz0hOso46D8dDGFZAUvI9HXFNnVxUXTLWm_gad37CDDZGDcPuastONFKIvcRYgIFB1phF1sQEgPTHqil8Gc1HA8rCMAOOV3F7c=@protonmail.com>

To core-libs-dev and the Java Comunity Process Team,

It remains the case that I and others need Java floating point and StrictMath (the primary double type
calculator class) to be repaired away from all their denormal and pronormal value possibilities. It has been made
clear by a number of publicly available publication sources, irrespective of age, from their date of publication and
into the future, that with hardware registry additions already present in Java platform hardware, namely SSE versions
and beyond, that repair can and must be wrought for Java float and double numeric types utilised in both Java SE and
OpenJDK's runtime environments. This includes float and double ranges, whenever arithmetic operations at all or certain
method calls involving them are made, where the results manage to straddle the edge of those ranges.

float from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).
double from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

The issue is not ascription and reading of possible values in these types, within their ranges. The problem
is with arithmetic operations, +,-,*,/,%,+=,-=,*-,/=,%=, and function calls made upon them that are inside the
StrictMath class, and possibly consequences within any closely bound classes or interfaces, namely those with
Float and Double inside their names.

As we attempted to submit in previous messages to core-libs-dev, IEEE 754 is silent on pertinent matters
around decimal arithmetic, mainly certain end facts about binary and decimal use in computer software;
that they need to have total objectivity at all steps of the way. The proper precedent to draw from,
to inform floating point arithmetic and elementary functions, is not a standard with a small "blind spot",
leading to non sequitur, but two even earlier phenomenon. The first of these states that information and
behaviour can be encoded into a computer, so that such a machine can behave by means of that
information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans.

The second fact is that range complete decimal mathematics is for humans, and binary mathematics
is for computers. Therefore, for a decimal result to have proper meaning, it must be entirely correct within
its (rational, truncated) range. The most efficient and only meaningful thing to do to obtain absolutely all
that is to utilise additional (SEE and similar) registers, with appropriate sub-java code, to use all registry
space, including the extra space if needed for decimal/binary range end straddling values, to produce range
accurate Java results via improved operational logic.

It is known that having a little more registry space past the number (result range) limit, for use and
consideration, is the only range, base-10 perfect way to go. It is certainly better than the available
class approaches, which waste memory, speed, and lack important and appropriate auxiliary use options.

In more recent times, it has become the case that there are a number of OpenJDK-downstream Java vendors.
Some of them of suggested to us that the better thing would be for something to be done at the OpenJDK,
JCP level, so that they could follow.

It is also the general observation that FP changes not need not be default only, but that any number of
"switching" approaches are valid; a runtime switch, maybe even keyword additions for various Java code
spaces, data qualifiers, or qualifiers for main methods, Runnables or Threads, could be used to
enable/disable two different floating point operating phenomena, either separately or together. Even
including code that has been compiled already. If determined enough, both modes of floating point
operation could be made compatible on any level, assuaging any concerns there.

Using such an approach, there need be no concerns about a split in Java, or compatability since all
this means that everything remains "under the same roof". An example of is the changes in Java's
switch syntax, to immediate switch on a String, alongside the inclusion of the switch's -> operator.
People later used the simplest, most appropriate approach under their circumstances, updated their
body of learning (which happens within any java release automatically, anyway), kept coding along,
and everybody continued relating and coding sharing or integrating between one another, just as
concordantly as before.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper workaround, and provide corrected,
defaulting or even specifying-compatible, code compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without any denormal and pronormalvalue inclusions at all?

Sent with [ProtonMail](https://protonmail.com/) secure email.

From duke at openjdk.java.net  Tue Apr 19 08:48:00 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 19 Apr 2022 08:48:00 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails
 with expected [true] but found [false]
Message-ID: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>

Please review these small changes to address intermittent failures, as of JDK-8274517.

- Usage of jdk.test.lib.RandomFactory for reproducible random generation.
- Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
- Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.

While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.

There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

-------------

Commit messages:
 - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]

Changes: https://git.openjdk.java.net/jdk/pull/8290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8290&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274517
  Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8290/head:pull/8290

PR: https://git.openjdk.java.net/jdk/pull/8290

From jiefu at openjdk.java.net  Tue Apr 19 09:02:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 19 Apr 2022 09:02:44 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
Message-ID: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>

Hi all,

The Current Vector API doc for `LSHR` is

Produce a>>>(n&(ESIZE*8-1)). Integral only.


This is misleading which may lead to bugs for Java developers.
This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .

After the patch, the doc for `LSHR` is

Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.


Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8284992: Fix misleading Vector API doc for LSHR operator

Changes: https://git.openjdk.java.net/jdk/pull/8291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284992
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291

PR: https://git.openjdk.java.net/jdk/pull/8291

From tschatzl at openjdk.java.net  Tue Apr 19 09:26:26 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 19 Apr 2022 09:26:26 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <J2NjRCB8GeHlHvPk6tF94Eb6d7B7gmT4ADKbBKAObi4=.7a7e251d-8d66-4b94-b31c-d36d41fc6bcd@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
 <J2NjRCB8GeHlHvPk6tF94Eb6d7B7gmT4ADKbBKAObi4=.7a7e251d-8d66-4b94-b31c-d36d41fc6bcd@github.com>
Message-ID: <LFpNVo9xHQZzswMjTjGpnRTJrd12lq41LHW6ulLt6t8=.9df2c0e5-a8cf-44f2-a660-3559e92e55cb@github.com>

On Mon, 11 Apr 2022 21:51:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Do you really need to define a real `FillerObject.java` class? Can't you use an internal-only variant of a hidden class to represent this?

I am not sure I understand this request, but of course I am open to try different approaches. An existing example would be fine to get me on track; but maybe I am only not understanding your terminology: do you mean to have a special subclass of instanceKlass for `FillerObject`?
I had that, but that has been much much more effort (in terms of code, maintainability, ...) than having such an additional Java class file in the JDK and use the existing macros to use it everywhere.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8156

From alanb at openjdk.java.net  Tue Apr 19 10:52:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Apr 2022 10:52:30 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
 <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>
Message-ID: <slKZHycwN7Mb7Fur0_AoX6YXe5ddnLP98LRVi8hz1cY=.b7e8883c-2d61-45eb-a4a5-aa8d4b202a3e@github.com>

On Tue, 19 Apr 2022 00:09:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61:
> 
>> 59:     private final Condition notEmpty;
>> 60: 
>> 61:     void signal() { notEmpty.signalAll(); }
> 
> `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`.  Good to make them private.

They are overridden so can't be private.

> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206:
> 
>> 204:         throws IllegalArgumentException, InterruptedException {
>> 205:         if (timeout < 0) throw new IllegalArgumentException("Negative timeout value");
>> 206:         if (timeout == 0) return remove();
> 
> Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file.
> 
> 
>         if (timeout < 0)
>             throw new IllegalArgumentException("Negative timeout value");
>         if (timeout == 0)
>             return remove();

okay

> src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655:
> 
>> 653:      * synchronization control.  It might be an expensive operation.
>> 654:      * Its behavior with cycles involving virtual threads is not defined
>> 655:      * in this release.
> 
> What does the current implementation return if the virtual threads are involved in a deadlock?    The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined.    I wonder if it's helpful to include `@implNote` if appropriate.

If there is cycle involving a virtual thread then the thread id of its carrier will be included in array. I think we can do better and include the thread id of the mounted thread.

> src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138:
> 
>> 136:      *
>> 137:      * @param  outputFile the path to the file to create
>> 138:      * @param  format the format to use (TEXT_PLAIN or JSON)
> 
> It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON`

I think it might be better if the description is changed to "the format to use". There is already a link to the ThreadDumpFormat enum in method signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jiefu at openjdk.java.net  Tue Apr 19 11:06:37 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 19 Apr 2022 11:06:37 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <CC5XARcprZ3Q0i9025CzOJZLK4gDqji6FBz8NIsbzGE=.278db2b6-ca50-4c99-a024-19b3defcb7fd@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

We plan to fix the doc: https://github.com/openjdk/jdk/pull/8291 first.
Then, let's see what @PaulSandoz would think of adding a new operator for the scalar `>>>`.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From redestad at openjdk.java.net  Tue Apr 19 13:09:50 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 13:09:50 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches
Message-ID: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>

There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.

Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

-------------

Commit messages:
 - Add tests and micro
 - Simplify latin1 to latin1 locale-independent comparisons in StringLatin1.regionMatchesCI

Changes: https://git.openjdk.java.net/jdk/pull/8292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285001
  Stats: 94 lines in 3 files changed: 88 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8292/head:pull/8292

PR: https://git.openjdk.java.net/jdk/pull/8292

From redestad at openjdk.java.net  Tue Apr 19 13:26:44 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 13:26:44 GMT
Subject: RFR: 8285007: Use correct lookup mode for MethodHandleStatics.UNSAFE
Message-ID: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>

Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.

In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 

This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.

-------------

Commit messages:
 - Use correct lookup mode for MethodHandleStatics.UNSAFE

Changes: https://git.openjdk.java.net/jdk/pull/8297/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8297&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285007
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8297.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8297/head:pull/8297

PR: https://git.openjdk.java.net/jdk/pull/8297

From rriggs at openjdk.java.net  Tue Apr 19 13:40:26 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Apr 2022 13:40:26 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches
In-Reply-To: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
Message-ID: <GrNNpbWTFa3YNwXc_DWYtuXMDOikw6RRz2NpV-1PEZ8=.28df6668-263b-464c-a986-f622068bdf2a@github.com>

On Tue, 19 Apr 2022 08:50:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.
> 
> Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

Nice Catch!

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8292

From rriggs at openjdk.java.net  Tue Apr 19 14:38:35 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Apr 2022 14:38:35 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v7]
In-Reply-To: <DAln8lPtjwxh9fev8Uos8tRfH9r9DY3-wZGs_WtRDMk=.a280b9d7-0536-44ff-9baa-c3f0a6badbb4@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <DAln8lPtjwxh9fev8Uos8tRfH9r9DY3-wZGs_WtRDMk=.a280b9d7-0536-44ff-9baa-c3f0a6badbb4@github.com>
Message-ID: <yN9hTZ2LCFp66kZwZqOjaYwQy5w9H6WSMVFbNaDuol4=.edb2ca7e-daba-4453-b8e0-df3c782be0f2@github.com>

On Fri, 15 Apr 2022 18:47:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Revert to use the default method
>  - Merge branch 'master' into JDK-8279185
>  - Removed unnecessary package names
>  - Modified class desc of `IsoFields`
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Merge branch 'master' into JDK-8279185
>  - Removed the method
>  - Merge branch 'master' into JDK-8279185
>  - Changed to use a type to determine ISO based or not
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/5ee1a816...82339ec6

src/java.base/share/classes/java/time/chrono/Chronology.java line 794:

> 792:      * @since 19
> 793:      */
> 794:     default boolean isIsoBased() {

Can the description be more specific.  Each of the chronologies mentioned
say they have the same number of months, the number of days in each month, and day-of-year and leap years are the same as ISO. The week-based fields in IsoFields also depend ISO defined concepts.

Perhaps it should say that this method should return true only if all of the fields of IsoFields are supported for the chronology.

The chronology names could be links and omit the @see tags, including ISOChronology.

In the @return add ", otherwise return {@code false}."

src/java.base/share/classes/java/time/temporal/IsoFields.java line 600:

> 598:             if (!isIsoBased(temporal)) {
> 599:                 throw new DateTimeException("Resolve requires ISO based chronology: " +
> 600:                         Chronology.from(temporal));

The name change doesn't add much, I'd leave both `ensureIso` and `isIso` method names unchanged.

src/java.base/share/classes/java/time/temporal/IsoFields.java line 739:

> 737: 
> 738:     static boolean isIsoBased(TemporalAccessor temporal) {
> 739:         return Chronology.from(temporal).isIsoBased();

Can this method be private static?

Also, move the `ensureIso` method to be next to `isIso`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From rriggs at openjdk.java.net  Tue Apr 19 14:38:37 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Apr 2022 14:38:37 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]
In-Reply-To: <ucKaEUGnoyUsBcAcaFACas08nOBCiORubc440zNEmsQ=.786716c6-8173-4b91-9218-c518c4b6870e@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <xU_V8M12iPdF1pfq8otYMUBsFo4AImj1lzlBeq5UzGk=.61281911-a2cc-422f-b0e3-bacdcdcf4ef9@github.com>
 <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com>
 <ucKaEUGnoyUsBcAcaFACas08nOBCiORubc440zNEmsQ=.786716c6-8173-4b91-9218-c518c4b6870e@github.com>
Message-ID: <YwL-76hACDXfoEhsR_alWPmZQ7ME7ZcZjFcKhw573jU=.98710694-6b98-41eb-84e4-dc1a1cc12dce@github.com>

On Mon, 7 Mar 2022 18:47:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689:
>> 
>>> 687:      */
>>> 688:     @Override
>>> 689:     public boolean isIsoBased() {
>> 
>> Is this meant to be 'default'?  The CSR indicated adding default methods.
>
> The `default` method has been added to `java.time.chrono.Chronology` interface. This is its overridden method implemented in `IsoChronology` concrete class.

To make navigation easier, change the @code references to be @links and include the IsoField name.

I don't think the @implspec is needed, its redundant with @return.

Apply similar changes to the other ISO chronologies javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From psandoz at openjdk.java.net  Tue Apr 19 15:44:25 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 19 Apr 2022 15:44:25 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <E4T4D4MpAD00_W8qsA_o1OIOIWeO_E96aQWsH-PZgMA=.c4caa0e3-3ca1-4866-a37e-aa1d13a67922@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

I need to discuss with @rose00 on the history behind this before deciding what to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From naoto at openjdk.java.net  Tue Apr 19 15:54:26 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 15:54:26 GMT
Subject: Integrated: 8284856: Add a test case for checking UnicodeScript entity
 numbers
In-Reply-To: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
References: <6uXfswjoFsuQ3suJyGNGYDMpdjGtDrsqvx0-SkcWg6I=.ae99fa14-a12e-48b5-b413-28d08184004f@github.com>
Message-ID: <Gtx5LiUIMised8eSGkD1Vf1-ECj22PQe8U9d58F48rI=.dd1e1c5e-53d5-4f95-b13f-9bfdfe6f4672@github.com>

On Thu, 14 Apr 2022 20:52:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Added the test case, and eliminated the immediate hashmap value, replaced with the ordinal number of `Character.UnicodeScript.UNKNOWN`.

This pull request has now been integrated.

Changeset: eb9c457b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb9c457b4141f2d253be14cbbad844bc4ba8c48d
Stats:     13 lines in 2 files changed: 8 ins; 0 del; 5 mod

8284856: Add a test case for checking UnicodeScript entity numbers

Reviewed-by: iris, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8253

From naoto at openjdk.java.net  Tue Apr 19 16:11:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 16:11:19 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches
In-Reply-To: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
Message-ID: <a5uLr0DnuDHgyHV_e907wnKra0IO3_ajxiZeN_Bl-2c=.831de73b-4ac1-4be8-ab3e-c2076d32f67c@github.com>

On Tue, 19 Apr 2022 08:50:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.
> 
> Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8292

From naoto at openjdk.java.net  Tue Apr 19 16:11:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 16:11:19 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches
In-Reply-To: <GrNNpbWTFa3YNwXc_DWYtuXMDOikw6RRz2NpV-1PEZ8=.28df6668-263b-464c-a986-f622068bdf2a@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
 <GrNNpbWTFa3YNwXc_DWYtuXMDOikw6RRz2NpV-1PEZ8=.28df6668-263b-464c-a986-f622068bdf2a@github.com>
Message-ID: <hWXXcE8jdGPLLe_sUClYIBbscwuJiLWA0cjRwXMh5Y0=.5ed7b65c-4111-4759-b777-8bdf60544e72@github.com>

On Tue, 19 Apr 2022 13:37:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Nice Catch!

+1

-------------

PR: https://git.openjdk.java.net/jdk/pull/8292

From psandoz at openjdk.java.net  Tue Apr 19 16:15:30 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 19 Apr 2022 16:15:30 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <svt0BifkHPai3T6nNZxXClF-igsoocwiJKhUt158qp8=.472349d7-db66-42cc-873a-c183ce071ce7@github.com>

On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

I need to think a little more about this. The specification is not accurate and likely requires a CSR.

My initial thoughts are I would prefer the operation to retain reference to the succinct definition using the logical right shift operator but we add additional specification explaining the cases for `byte` and `short`, namely that the result is widened to an `int` as if by `(a & ((1 << ESIZE) - 1))` and the result narrowed. That's commonly (at least for the widening part) how `>>>` is used with `byte` and `short`, and i think would be clearer to be explicit in that regard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From ihse at openjdk.java.net  Tue Apr 19 16:23:02 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 16:23:02 GMT
Subject: RFR: 8284893: Fix typos in java.base [v2]
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <Vcb9tZcABlUGgWXhs9LrcoItBXL8S-l3Il_sHdcRVAU=.5f044dba-5ff4-45a0-b43b-a00a601ca770@github.com>

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to 3rd party code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8250/files
  - new: https://git.openjdk.java.net/jdk/pull/8250/files/5e3a01c6..31baf0a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=00-01

  Stats: 15 lines in 11 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250

PR: https://git.openjdk.java.net/jdk/pull/8250

From psandoz at openjdk.java.net  Tue Apr 19 16:23:24 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 19 Apr 2022 16:23:24 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE
In-Reply-To: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
Message-ID: <1HcLVCSXZspYBaKJaF_fVxdZWfXBc3wYB6AoSgpMAow=.0208fea4-690b-4563-8266-a52e3df87492@github.com>

On Tue, 19 Apr 2022 13:19:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
> 
> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
> 
> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From ihse at openjdk.java.net  Tue Apr 19 16:24:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 16:24:43 GMT
Subject: RFR: 8284893: Fix typos in java.base [v3]
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com>

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Vertices -> vertices

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8250/files
  - new: https://git.openjdk.java.net/jdk/pull/8250/files/31baf0a3..2b029279

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250

PR: https://git.openjdk.java.net/jdk/pull/8250

From naoto at openjdk.java.net  Tue Apr 19 16:47:26 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 16:47:26 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v8]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <wsuuWbphkLntR88wrJMYFKQtwkDhfyLAsnioE5ThTp0=.20db51a2-e706-4fed-815b-6d3b4fd16ad4@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Revert to use the default method
 - Removed unnecessary package names
 - Modified class desc of `IsoFields`
 - abstract class -> top level interface
 - interface -> abstract class
 - Removed the method
 - Changed to use a type to determine ISO based or not
 - Renamed the new method
 - Addresses review comments
 - copyright year fix
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/583eba4e...c3f15f6a

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/82339ec6..c3f15f6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=06-07

  Stats: 1815 lines in 155 files changed: 1085 ins; 236 del; 494 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From ihse at openjdk.java.net  Tue Apr 19 16:50:12 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 16:50:12 GMT
Subject: RFR: 8284893: Fix typos in java.base [v4]
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Update Oracle copyrights
 - Also revert changes in ASM (3rd party code)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8250/files
  - new: https://git.openjdk.java.net/jdk/pull/8250/files/2b029279..a3f75247

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=02-03

  Stats: 134 lines in 133 files changed: 0 ins; 0 del; 134 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250

PR: https://git.openjdk.java.net/jdk/pull/8250

From ihse at openjdk.java.net  Tue Apr 19 16:50:14 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 16:50:14 GMT
Subject: RFR: 8284893: Fix typos in java.base [v3]
In-Reply-To: <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com>
Message-ID: <VZLeM9LxQdH1sx6qfIlAgaCcavfUnksS_UZ5QIJPxAo=.a35fbc4e-15ab-4ee2-8903-80b118511f8e@github.com>

On Tue, 19 Apr 2022 16:24:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Vertices -> vertices

It's a bit annoying that 3rd party code is not more distinctly handled in the JDK source. :( I reverted the code pointed out by reviewers, but then later found the ASM code as well.

If I feel really motivated (or bored) I might try to submit PRs with these fixes upstream. Or not.

Everybody happy now?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From mchung at openjdk.java.net  Tue Apr 19 16:52:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 16:52:34 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <slKZHycwN7Mb7Fur0_AoX6YXe5ddnLP98LRVi8hz1cY=.b7e8883c-2d61-45eb-a4a5-aa8d4b202a3e@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
 <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>
 <slKZHycwN7Mb7Fur0_AoX6YXe5ddnLP98LRVi8hz1cY=.b7e8883c-2d61-45eb-a4a5-aa8d4b202a3e@github.com>
Message-ID: <CDm9CpNrO0Qb8ocoQZPGewKvbamv8NYmQ4frDeqqGIA=.c03cfd6c-ce07-41c7-8295-22ba63f1e9c5@github.com>

On Tue, 19 Apr 2022 10:49:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61:
>> 
>>> 59:     private final Condition notEmpty;
>>> 60: 
>>> 61:     void signal() { notEmpty.signalAll(); }
>> 
>> `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`.  Good to make them private.
>
> They are overridden so can't be private.

That's right, I missed it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From lancea at openjdk.java.net  Tue Apr 19 17:01:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 19 Apr 2022 17:01:23 GMT
Subject: RFR: 8284893: Fix typos in java.base [v4]
In-Reply-To: <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
Message-ID: <1d8I8AuoQkCXZ8ITDlZS6b_i1JgDD6uS8zsSf_zZvpk=.02aead18-e100-4892-9ddb-d8d6d918625a@github.com>

On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Oracle copyrights
>  - Also revert changes in ASM (3rd party code)

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From mchung at openjdk.java.net  Tue Apr 19 17:05:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 17:05:26 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE
In-Reply-To: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
Message-ID: <10HT4KENwwhpgVn0Xu8mJMt8lenxVhczGhrqtBLNbjQ=.6e42ba1f-0579-451f-8fe0-2cf51f630adc@github.com>

On Tue, 19 Apr 2022 13:19:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
> 
> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
> 
> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 901:

> 899:                     MemberName member = new MemberName(MethodHandleStatics.class, "UNSAFE", Unsafe.class, REF_getStatic);
> 900:                     return new NamedFunction(
> 901:                             MemberName.getFactory().resolveOrFail(REF_getField, member,

`REF_getField` passed to `resolveOrFail` should also be corrected?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From jkuhn at openjdk.java.net  Tue Apr 19 17:08:28 2022
From: jkuhn at openjdk.java.net (Johannes Kuhn)
Date: Tue, 19 Apr 2022 17:08:28 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <FvARsEkurVv5R8gbUBcQH6hZ85tBGMLXBEKAUirn4lY=.58339b91-61f2-4d3e-afc6-0dc81f260dcd@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

About deserializing Proxies, this is currently done in 3 steps:

1. Finding the class
2. Allocating a new instance and invoke the constructor of the **first non-serializable superclass**
3. Setting the fields of the instance

Only step 2 is problematic here:

1. For a proxy, the class is serialized using a TC_PROXYCLASSDESC. when deserialized it invokes `Proxy.getProxyClass` (https://github.com/openjdk/jdk/blob/13fb1eed52f1a9152242119969a9d4a0c0627513/src/java.base/share/classes/java/io/ObjectInputStream.java#L891).  
    For this step, it doesn't matter if `Proxy.getProxyClass` returns a normal class or a hidden class.
2. Allocating and calling the constructor:  
     This part is currently implemented by spinning a class. The generated bytecode looks more or less like this:

        anew ProxyClass
        invokespecial Object.<init>()

    The big lie here is that methods and constructors are different - but constructors are just methods, and the verifier makes sure that a constructor is called only once, exactly once, and that uninitialized instances don't escape.

    This doesn't work for hidden classes - as the hidden class can not be named in an other class.  
    But MethodHandles can do this. Here is one of my old prototypes, based on a prototype for implementing reflection using MethodHandles from Mandy Chung: https://github.com/dasbrain/jdk/compare/ae45c5de7fc635df4dc86b764405158c245d2765...fbb0a63436f696a85e7039c0e109c379dfa1edce

3. Setting the fields uses deep reflection.   
    But the hidden class themself doesn't have any fields - just it's superclass `java.lang.reflect.Proxy.h`.  
    This is not a problem if the class can be instantiated at all (see step 2).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From duke at openjdk.java.net  Tue Apr 19 17:24:22 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 17:24:22 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <p2BSLju1s-AgQVTomerkICbrciYizbG_Jqiy4j7zsnU=.080bd35f-db57-4e25-819e-98380278589d@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

Fixing deserialization is not particularly hard. A longer term goal is to declare a readResolve for proxies (presumably by extra methods on invocation handlers) to convert serialization result to something else

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From mchung at openjdk.java.net  Tue Apr 19 17:30:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 17:30:26 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables [v2]
In-Reply-To: <FVsH-TlrmXY54QTyEtA0Z1OG4h2C56NCVlWGbeymUEs=.4c9a27a1-a17f-4118-8dc0-6a42df808152@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
 <FVsH-TlrmXY54QTyEtA0Z1OG4h2C56NCVlWGbeymUEs=.4c9a27a1-a17f-4118-8dc0-6a42df808152@github.com>
Message-ID: <-zqOehpIA-hU4TB5SIwMn_ZocZ5mZ4A0v11pIV-sh3c=.15985275-bb3e-4445-bc72-7fc24bd9a0c2@github.com>

On Thu, 14 Apr 2022 13:59:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch examines and optimizes `Wrapper` lookups.
>> 
>> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
>> 
>> Micros show benefits across the board for warmed up case:
>> 
>> 
>> Baseline, OOTB
>> Benchmark                  Mode  Cnt   Score   Error  Units
>> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
>> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
>> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
>> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
>> 
>> Patch, OOTB
>> Benchmark                  Mode  Cnt   Score   Error  Units
>> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
>> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
>> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
>> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
>> 
>> 
>> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
>> 
>> 
>> Baseline, -Xint
>> Benchmark                  Mode  Cnt     Score     Error  Units
>> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
>> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
>> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
>> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
>> 
>> Patch, -Xint
>> Benchmark                  Mode  Cnt     Score     Error  Units
>> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
>> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
>> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
>> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add line break in make/test/BuildMicrobenchmark.gmk
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Looks good.    The copyright header end-year needs update before you push.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8242

From redestad at openjdk.java.net  Tue Apr 19 17:33:04 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 17:33:04 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE [v2]
In-Reply-To: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
Message-ID: <Vj4EZiM5UeoomR39VI18NW8HL0SVIQi2yM9Oa9vcgu0=.4f7ee680-6c4e-4e3e-bfcc-a791d9337d91@github.com>

> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
> 
> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
> 
> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missed a spot!

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8297/files
  - new: https://git.openjdk.java.net/jdk/pull/8297/files/fa10026a..e4f37c49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8297&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8297&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8297.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8297/head:pull/8297

PR: https://git.openjdk.java.net/jdk/pull/8297

From mchung at openjdk.java.net  Tue Apr 19 17:33:04 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 17:33:04 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE [v2]
In-Reply-To: <Vj4EZiM5UeoomR39VI18NW8HL0SVIQi2yM9Oa9vcgu0=.4f7ee680-6c4e-4e3e-bfcc-a791d9337d91@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
 <Vj4EZiM5UeoomR39VI18NW8HL0SVIQi2yM9Oa9vcgu0=.4f7ee680-6c4e-4e3e-bfcc-a791d9337d91@github.com>
Message-ID: <VgHOXZ4AUP1DqauR50DQZUKTwi2PQz2AONevjunUwQM=.6556b937-efc8-4f0f-bf6a-bc5b6fa2ead2@github.com>

On Tue, 19 Apr 2022 17:29:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
>> 
>> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
>> 
>> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a spot!

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From redestad at openjdk.java.net  Tue Apr 19 17:33:04 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 17:33:04 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE [v2]
In-Reply-To: <10HT4KENwwhpgVn0Xu8mJMt8lenxVhczGhrqtBLNbjQ=.6e42ba1f-0579-451f-8fe0-2cf51f630adc@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
 <10HT4KENwwhpgVn0Xu8mJMt8lenxVhczGhrqtBLNbjQ=.6e42ba1f-0579-451f-8fe0-2cf51f630adc@github.com>
Message-ID: <R4V1RnPVA11tTMhrnfMNTTYaAvZVaUGh7qQDCrlw4ok=.7cb1de07-de9e-41ab-8bec-749921d0b3e6@github.com>

On Tue, 19 Apr 2022 17:01:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed a spot!
>
> src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 901:
> 
>> 899:                     MemberName member = new MemberName(MethodHandleStatics.class, "UNSAFE", Unsafe.class, REF_getStatic);
>> 900:                     return new NamedFunction(
>> 901:                             MemberName.getFactory().resolveOrFail(REF_getField, member,
> 
> `REF_getField` passed to `resolveOrFail` should also be corrected?

Yes, fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From naoto at openjdk.java.net  Tue Apr 19 17:43:21 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 17:43:21 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v9]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <pxwE71FCKS0jDXc_ovvsX3pyZwdU2yPDQU3mHizjcBA=.45e4dfd9-6d9a-42a5-8fbf-53cd587c49c6@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/c3f15f6a..45edbc3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=07-08

  Stats: 50 lines in 6 files changed: 18 ins; 7 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From psandoz at openjdk.java.net  Tue Apr 19 17:43:26 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 19 Apr 2022 17:43:26 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <615b3xLgbKn1Vsj6JukH2McmpD6CKMvZn3nBIuJox1k=.fbf9da3a-d472-4cf4-8bc0-2cc1ffba06a4@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

Not yet talked with John, but i investigated further. The implementation of the `LSHR` operation is behaving as intended, but is under specified with regards to `byte` and `short` as you noted in #8291.

This is a subtle area, but i am wondering if the user really means to use arithmetic shift in this case? Since is not the following true for all values of `e` and `c`, where `e` is a `byte` and `c` is the right shift count ranging from 0 to 7:


(byte) (e >>> c) == (byte) (e >> c)

?

Then the user can use `VectorOperators.ASHR`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From mchung at openjdk.java.net  Tue Apr 19 18:02:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 19 Apr 2022 18:02:26 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v4]
In-Reply-To: <umlvS44m5FhXPyOycZmzTiVMnqGJDZT3kDEZoljFC2Q=.5eeca768-553d-4c48-8afe-3d4bb9bf7394@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <umlvS44m5FhXPyOycZmzTiVMnqGJDZT3kDEZoljFC2Q=.5eeca768-553d-4c48-8afe-3d4bb9bf7394@github.com>
Message-ID: <1iPG35GO0IkgvatlYQcU5zHGWcDSjkmKi2J4YrwaXO4=.743de52b-8d13-481a-a899-108b0ed912c0@github.com>

On Mon, 11 Apr 2022 00:48:34 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requested changes

Marked as reviewed by mchung (Reviewer).

test/jdk/java/lang/module/exeNullCallerGetResource/exeNullCallerGetResource.c line 95:

> 93:     jclass class_OpenResources = (*env)->FindClass(env, "open/OpenResources");
> 94:     assert(class_OpenResources != NULL);
> 95:     jmethodID mid_OpenResources_fetchClass = (*env)->GetStaticMethodID(env, class_OpenResources, "fetchClass", "()Ljava/lang/Class;" );

It seems that invoking `fetchClass` isn't necessary since you can simply use `class_OpenResources`.  Similarly for `class_ClosedResources`

test/jdk/java/lang/module/exeNullCallerGetResource/exeNullCallerGetResource.c line 183:

> 181:         exit(-1);
> 182:     }
> 183:     assert(in == NULL);

assert is typically used for sanity test.   As part of the test validation, e.g. in this case `in == NULL` or `in != NULL` in line 157,  it may be clearer if it's an explicit check and throw exception to indicate test failure especially in case `#undef NDEBUG` may not be set in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From duke at openjdk.java.net  Tue Apr 19 18:07:27 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 18:07:27 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
Message-ID: <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>

On Mon, 18 Apr 2022 20:08:23 GMT, jmehrens <duke at openjdk.java.net> wrote:

> > @jmehrens what about this then? I think it safe now(actually this mechanism is learned from Reader)
> 
> Reader uses a lock object and it appears that InputStream locks on this (per make/reset) I would assume now that you have some object member fields you need to hold some lock while accessing those. Even though single thread access would be the expected case.

no, we use other way, but yes for we take care of thread safety.

> Not related but, it looks like the static buffer issue has come up a few times. Maybe time to add a test to: https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/InputStream/Skip.java that would fail if the skip buffer is static?

I think it is worthy to add some comments, but a test for it sound a little bit extreme.

> Not really the primary issue but, it seems questionable to me that we don't have to fill the skip buffer with zeros after the last read. That way any sensitive information that was skipped would also be forgotten. Matching with Reader seems more important for now.

Don't think it necessary... I think making it cannot touched by other object (with security manager on) is enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue Apr 19 18:10:50 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 18:10:50 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet
Message-ID: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>

as title.

-------------

Commit messages:
 - 8284780: Need methods to create pre-sized HashSet and LinkedHashSet

Changes: https://git.openjdk.java.net/jdk/pull/8302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284780
  Stats: 34 lines in 2 files changed: 34 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From smarks at openjdk.java.net  Tue Apr 19 18:18:46 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 19 Apr 2022 18:18:46 GMT
Subject: RFR: 8282120: optimal capacity tests and test library need to be
 cleaned up
Message-ID: <oiX4bM6_K8taNDNJp2NY8wf2-QHQ6kIOMEc-YyJQS7Y=.db4fdab4-58d4-49f0-b2f0-1fcb0da55ad7@github.com>

The test `java/lang/Enum/ConstantDirectoryOptimalCapacity.java` was problem-listed by [JDK-8281631](https://bugs.openjdk.java.net/browse/JDK-8281631) and essentially superseded by [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). Given this, the test should simply be removed. This test is the only test that depends on a test library utility `test/lib/jdk/test/lib/util/OptimalCapacity.java` which has a number of issues of its own, so it should simply be removed as well.

See the bug report, in particular the comment

https://bugs.openjdk.java.net/browse/JDK-8282120?focusedCommentId=14489450&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14489450

for detailed discussion.

-------------

Commit messages:
 - Remove test Enum/ConstantDirectoryOptimalCapacity, utility, and problem list entry.

Changes: https://git.openjdk.java.net/jdk/pull/8303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282120
  Stats: 355 lines in 3 files changed: 0 ins; 355 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8303/head:pull/8303

PR: https://git.openjdk.java.net/jdk/pull/8303

From duke at openjdk.java.net  Tue Apr 19 18:23:02 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 18:23:02 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v2]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <UPspAJAWACM8QLwl3sfrElKUmjUmRLrLXCCCBqQ-XYs=.7a87c8ba-390a-4953-ad9d-56c00045898b@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  fix LinkedHashSet constructor

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/436273ed..b139366c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From jlahoda at openjdk.java.net  Tue Apr 19 18:47:16 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 19 Apr 2022 18:47:16 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup - more total -> unconditional pattern renaming.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/311d68a6..dc001541

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Tue Apr 19 18:51:26 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 18:51:26 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
 <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
Message-ID: <CDhMRIL6QOxGC__Qk0xGrikDku7lH1sn2w7EDgqallg=.95ebb5d7-b72a-48bf-8424-ada294677cfb@github.com>

On Tue, 19 Apr 2022 18:04:03 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> Reader uses a lock object and it appears that InputStream locks on this (per make/reset) I would assume now that you have some object member fields you need to hold some lock while accessing those. Even though single thread access would be the expected case.

Locks are expensive. We just use buffers that may or may not be shared by different threads (for the java memory model), because locking objects is too costly performance-wise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Tue Apr 19 19:07:34 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 19 Apr 2022 19:07:34 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v9]
In-Reply-To: <pxwE71FCKS0jDXc_ovvsX3pyZwdU2yPDQU3mHizjcBA=.45e4dfd9-6d9a-42a5-8fbf-53cd587c49c6@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <pxwE71FCKS0jDXc_ovvsX3pyZwdU2yPDQU3mHizjcBA=.45e4dfd9-6d9a-42a5-8fbf-53cd587c49c6@github.com>
Message-ID: <oOffW4JCqcN47r1B0CmVK_XcQquOZKICU30YlLInCwY=.4e66822d-87cb-47a3-971d-fe2e29de2392@github.com>

On Tue, 19 Apr 2022 17:43:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Looks good, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7683

From mullan at openjdk.java.net  Tue Apr 19 19:15:33 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 19 Apr 2022 19:15:33 GMT
Subject: RFR: 8284893: Fix typos in java.base [v4]
In-Reply-To: <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
Message-ID: <ws6xp6IpvqsEvHsuTxlIi7HBHSp18pdWcGBSfE5G2a8=.ae0fb47b-d6a2-4f34-b4da-33f5a6925ce4@github.com>

On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Oracle copyrights
>  - Also revert changes in ASM (3rd party code)

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From naoto at openjdk.java.net  Tue Apr 19 19:43:24 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 19:43:24 GMT
Subject: RFR: 8284893: Fix typos in java.base [v4]
In-Reply-To: <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
 <BF_leLMnF5aw5eceFt3XOLER1ntmKM0638PpSaMMrQY=.0d23d48d-4c2a-4fc7-b9f7-cf1e8f638db9@github.com>
Message-ID: <YlYGbM2Yy8gpyHsdfRFYy2Iet4cmGc2UhNDxkmOmv0o=.0b32c7d7-3789-434c-80a8-fbdc8d52bbe9@github.com>

On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Oracle copyrights
>  - Also revert changes in ASM (3rd party code)

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From duke at openjdk.java.net  Tue Apr 19 20:02:17 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 20:02:17 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v3]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <HTtWjIQ50KTo85hKoA4ZVcVKFv0qpwfq_kaMDlVGYzk=.468b52a4-45f0-4634-a08e-c6c4cecdb7b2@github.com>

> as title.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - migrate HashSet usages
 - migrate LinkedHashSet usage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/b139366c..e052c34f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=01-02

  Stats: 67 lines in 43 files changed: 1 ins; 9 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From naoto at openjdk.java.net  Tue Apr 19 20:07:25 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 19 Apr 2022 20:07:25 GMT
Subject: RFR: 8282120: optimal capacity tests and test library need to be
 cleaned up
In-Reply-To: <oiX4bM6_K8taNDNJp2NY8wf2-QHQ6kIOMEc-YyJQS7Y=.db4fdab4-58d4-49f0-b2f0-1fcb0da55ad7@github.com>
References: <oiX4bM6_K8taNDNJp2NY8wf2-QHQ6kIOMEc-YyJQS7Y=.db4fdab4-58d4-49f0-b2f0-1fcb0da55ad7@github.com>
Message-ID: <hrLSa7b1EyCBrrxkk2d5kenM9Vj5PujzJjJtqAfXvGU=.30fe8814-8fb8-4e8f-8969-4a6b50a8df6d@github.com>

On Tue, 19 Apr 2022 18:12:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> The test `java/lang/Enum/ConstantDirectoryOptimalCapacity.java` was problem-listed by [JDK-8281631](https://bugs.openjdk.java.net/browse/JDK-8281631) and essentially superseded by [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). Given this, the test should simply be removed. This test is the only test that depends on a test library utility `test/lib/jdk/test/lib/util/OptimalCapacity.java` which has a number of issues of its own, so it should simply be removed as well.
> 
> See the bug report, in particular the comment
> 
> https://bugs.openjdk.java.net/browse/JDK-8282120?focusedCommentId=14489450&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14489450
> 
> for detailed discussion.

Good cleanup!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8303

From ihse at openjdk.java.net  Tue Apr 19 20:11:29 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 20:11:29 GMT
Subject: Integrated: 8284893: Fix typos in java.base
In-Reply-To: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
References: <en-CTn2xaGql3Qc4wttWq-LFXBE7dSnUYRxIBuNYXCg=.c78ae2c6-453a-403e-bde7-e02e50c148b2@github.com>
Message-ID: <1JP1QqXE1B7A6L1N5N8p82g_xrIWs1lr8qSVV-QPzA0=.06021c8b-0602-4bd7-a69f-fc9b1af22832@github.com>

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps..

This pull request has now been integrated.

Changeset: fb469fb8
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb469fb894ed84686f9fec5787ac99eb535fdd18
Stats:     369 lines in 162 files changed: 0 ins; 0 del; 369 mod

8284893: Fix typos in java.base

Reviewed-by: iris, wetmore, lancea, mullan, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8250

From duke at openjdk.java.net  Tue Apr 19 20:15:08 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 19 Apr 2022 20:15:08 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>

> as title.

XenoAmess has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - migrate HashSet usages
 - migrate LinkedHashSet usage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/e052c34f..f051c1fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From redestad at openjdk.java.net  Tue Apr 19 20:28:28 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:28:28 GMT
Subject: RFR: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE [v2]
In-Reply-To: <Vj4EZiM5UeoomR39VI18NW8HL0SVIQi2yM9Oa9vcgu0=.4f7ee680-6c4e-4e3e-bfcc-a791d9337d91@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
 <Vj4EZiM5UeoomR39VI18NW8HL0SVIQi2yM9Oa9vcgu0=.4f7ee680-6c4e-4e3e-bfcc-a791d9337d91@github.com>
Message-ID: <IqzuBncLdOfAOqO0lto_blBb78AnSf5tVmLWc4Z2lak=.2c2eda94-cd7a-49b9-814f-189b27e5a7f4@github.com>

On Tue, 19 Apr 2022 17:33:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
>> 
>> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
>> 
>> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a spot!

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From redestad at openjdk.java.net  Tue Apr 19 20:28:29 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:28:29 GMT
Subject: Integrated: 8285007: Use correct lookup mode for
 MethodHandleStatics.UNSAFE
In-Reply-To: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
References: <uPih2CsQBUQzzWwps0deLbLz-kjCWzh1FsaRhbnhK6M=.37760ca4-bae2-4fb7-b25c-c05904897d34@github.com>
Message-ID: <cLuKeo5BDJlwVYpgCBgwTeWdfRkZuSBgFevf3o2U3Z4=.005b58ec-653c-4175-aff4-f47d6bd64dab@github.com>

On Tue, 19 Apr 2022 13:19:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially fix the resolution of the `NF_UNSAFE` named function to use the appropriate lookup mode.
> 
> In [JDK-8187826](https://bugs.openjdk.java.net/browse/JDK-8187826) we changed from regular reflection to use a `NamedFunction` for this field, but it appears the lookup mode came out wrong. This mismatch appears to be benign and ignored by HotSpot, but a user implementing an experimental JVM ran into some issues (and additionally noticed the resolve throws the wrong exception). 
> 
> This patch is a point fix to this particular issue, but I think we should consider following up with a stronger assertion or test for proper staticness of fields somewhere when resolving fields via `MemberName.getFactory().resolveOrNull(..)`.

This pull request has now been integrated.

Changeset: 5d1ec54d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d1ec54d6c20dfe67a459c9d102cdfa0394bcc1e
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8285007: Use correct lookup mode for MethodHandleStatics.UNSAFE

Reviewed-by: psandoz, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8297

From redestad at openjdk.java.net  Tue Apr 19 20:33:07 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:33:07 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches [v2]
In-Reply-To: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
Message-ID: <nvHPbCoreP7RmfX0xa2FsTfXx5wUoX2TvQaHZpfIcp0=.1291d25e-6138-4542-951e-c6abd0cee81b@github.com>

> There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.
> 
> Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8292/files
  - new: https://git.openjdk.java.net/jdk/pull/8292/files/a8894f79..434a0fd2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8292&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8292&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8292/head:pull/8292

PR: https://git.openjdk.java.net/jdk/pull/8292

From redestad at openjdk.java.net  Tue Apr 19 20:33:08 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:33:08 GMT
Subject: Integrated: 8285001: Simplify StringLatin1.regionMatches
In-Reply-To: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
Message-ID: <9_RZjXWGF8JdabHzIJjiCnXDEPoc98zd9lmub7sjUNk=.1474527b-6f7a-49e1-b03d-7d32c48336c2@github.com>

On Tue, 19 Apr 2022 08:50:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.
> 
> Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

This pull request has now been integrated.

Changeset: e307bc86
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e307bc8694462568807021191f9653ee80a93ed1
Stats:     95 lines in 3 files changed: 88 ins; 3 del; 4 mod

8285001: Simplify StringLatin1.regionMatches

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8292

From redestad at openjdk.java.net  Tue Apr 19 20:33:08 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:33:08 GMT
Subject: RFR: 8285001: Simplify StringLatin1.regionMatches
In-Reply-To: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
References: <tDC4NvcVThHJ7d_Qtx1MsBiQ9mRDCCcUgkWRUDMP-5c=.36105a05-b7d0-466e-9c58-f1a525f5b9c1@github.com>
Message-ID: <_nAFPtfP_P6G67_uZ01f8cWga0UtSCt_zg-6K3CTNWE=.4e7f744b-0431-46ee-9417-214bcde652e4@github.com>

On Tue, 19 Apr 2022 08:50:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> There is no pair of character values in the latin1 range (0-255) that will make the condition at line 401 in `StringLatin1.java` true, so this test can be removed.
> 
> Added a test and a microbenchmark (which as expected sees a few ns/op improvement from this change). Took the opportunity to tune the default settings for the micro to reduce runtime from 30+ minutes to 3 with no discernible degradation of quality.

Thanks for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8292

From redestad at openjdk.java.net  Tue Apr 19 20:38:12 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:38:12 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables [v2]
In-Reply-To: <FVsH-TlrmXY54QTyEtA0Z1OG4h2C56NCVlWGbeymUEs=.4c9a27a1-a17f-4118-8dc0-6a42df808152@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
 <FVsH-TlrmXY54QTyEtA0Z1OG4h2C56NCVlWGbeymUEs=.4c9a27a1-a17f-4118-8dc0-6a42df808152@github.com>
Message-ID: <4deQt-_nlLzPgs8mtmSPh9m5JSHXVdntYTYvJ-X35ZM=.9f03ab9c-e556-4c16-94f6-bebb66df1c62@github.com>

On Thu, 14 Apr 2022 13:59:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch examines and optimizes `Wrapper` lookups.
>> 
>> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
>> 
>> Micros show benefits across the board for warmed up case:
>> 
>> 
>> Baseline, OOTB
>> Benchmark                  Mode  Cnt   Score   Error  Units
>> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
>> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
>> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
>> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
>> 
>> Patch, OOTB
>> Benchmark                  Mode  Cnt   Score   Error  Units
>> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
>> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
>> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
>> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
>> 
>> 
>> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
>> 
>> 
>> Baseline, -Xint
>> Benchmark                  Mode  Cnt     Score     Error  Units
>> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
>> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
>> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
>> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
>> 
>> Patch, -Xint
>> Benchmark                  Mode  Cnt     Score     Error  Units
>> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
>> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
>> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
>> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add line break in make/test/BuildMicrobenchmark.gmk
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Thanks for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8242

From redestad at openjdk.java.net  Tue Apr 19 20:38:12 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:38:12 GMT
Subject: RFR: 8284880: Re-examine sun.invoke.util.Wrapper hash tables [v3]
In-Reply-To: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
Message-ID: <RpfLZfzqBHm-JcS4fmSmfNa5aBmzsLWFHQSiSAvI5gA=.c18d1d64-241c-4ca5-a01e-73338b45f6a3@github.com>

> This patch examines and optimizes `Wrapper` lookups.
> 
> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
> 
> Micros show benefits across the board for warmed up case:
> 
> 
> Baseline, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
> 
> Patch, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
> 
> 
> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
> 
> 
> Baseline, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
> 
> Patch, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'wrappers' of https://github.com/cl4es/jdk into wrappers
 - Copyrights

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8242/files
  - new: https://git.openjdk.java.net/jdk/pull/8242/files/97eec9d3..792c37e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8242&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8242&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8242/head:pull/8242

PR: https://git.openjdk.java.net/jdk/pull/8242

From redestad at openjdk.java.net  Tue Apr 19 20:38:14 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 19 Apr 2022 20:38:14 GMT
Subject: Integrated: 8284880: Re-examine sun.invoke.util.Wrapper hash tables
In-Reply-To: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
References: <myAoA_HXil6k1P4y2HdPbbrLsjD5WUYmCBxfazW9Ra0=.4983e3f9-e1f0-412f-aeb5-f85c9d40bf08@github.com>
Message-ID: <zi8qMXt3u1xK7HP6OT1DICKb2v8sMIyY4E6MiktzIek=.8d5d23e3-164f-441f-be87-d2bb30e5652f@github.com>

On Thu, 14 Apr 2022 11:19:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch examines and optimizes `Wrapper` lookups.
> 
> First wrote a few simple microbenchmarks to verify there are actual speedups from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up for the case of `char` -> `Wrapper`, but not when mapping from `Class<?>` -> `Wrapper`, so let's drop those. The `forPrimitiveType` case didn't use the `FROM_CHAR` table for some reason, which is remedied.  
> 
> Micros show benefits across the board for warmed up case:
> 
> 
> Baseline, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.387 ? 0.127  ns/op
> Wrappers.forPrimitive      avgt    5  38.818 ? 0.592  ns/op
> Wrappers.forPrimitiveType  avgt    5  26.085 ? 2.291  ns/op
> Wrappers.forWrapper        avgt    5  44.459 ? 1.635  ns/op
> 
> Patch, OOTB
> Benchmark                  Mode  Cnt   Score   Error  Units
> Wrappers.forBasicType      avgt    5  14.357 ? 0.133  ns/op
> Wrappers.forPrimitive      avgt    5  23.930 ? 0.071  ns/op
> Wrappers.forPrimitiveType  avgt    5  14.343 ? 0.017  ns/op
> Wrappers.forWrapper        avgt    5  27.622 ? 0.022  ns/op
> 
> 
> For `-Xint` case (`Wrapper` use is prominent during warmup, e.g., when spinning up of MHs) there are decent or even great wins in all cases but `forPrimitiveType` - which was changed from a simple switch to use the hash lookup. Since the interpreter penalty is small in absolute terms and the win on JITed code is significant this seems like a reasonable trade-off:
> 
> 
> Baseline, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1246.144 ? 149.933  ns/op
> Wrappers.forPrimitive      avgt    5  4955.297 ? 329.869  ns/op
> Wrappers.forPrimitiveType  avgt    5   716.840 ?  62.568  ns/op
> Wrappers.forWrapper        avgt    5  5774.700 ? 367.627  ns/op
> 
> Patch, -Xint
> Benchmark                  Mode  Cnt     Score     Error  Units
> Wrappers.forBasicType      avgt    5  1068.096 ? 101.728  ns/op
> Wrappers.forPrimitive      avgt    5  1146.670 ?  59.142  ns/op
> Wrappers.forPrimitiveType  avgt    5   998.037 ? 118.144  ns/op
> Wrappers.forWrapper        avgt    5  3581.226 ?  20.167  ns/op

This pull request has now been integrated.

Changeset: 5df8bd6b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5df8bd6b4e15686aa7d72b3f5a977eb51b0befc3
Stats:     259 lines in 3 files changed: 158 ins; 59 del; 42 mod

8284880: Re-examine sun.invoke.util.Wrapper hash tables

Reviewed-by: erikj, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8242

From bpb at openjdk.java.net  Tue Apr 19 21:11:26 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Apr 2022 21:11:26 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <NZjD51lFkj2RsYCCT6lSL4fNoCMnyLiAxDtXAPIIn80=.b8789d0c-5e92-4d4d-8d94-833ca4c947af@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <NZjD51lFkj2RsYCCT6lSL4fNoCMnyLiAxDtXAPIIn80=.b8789d0c-5e92-4d4d-8d94-833ca4c947af@github.com>
Message-ID: <LGXmupPKoJKef743uxRZ5sd__GlaLh7Ai7JrFs_4idw=.9f23d5f0-f0a8-4852-aec4-fc7612ecd460@github.com>

On Thu, 14 Apr 2022 06:23:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> src/java.base/share/native/libjava/io_util.c line 133:
> 
>> 131:             if (nread == 0)
>> 132:                 nread = -1;
>> 133:             break;
> 
> Can you prototype doing the loop in Java rather than in native code so that there is less native code to maintain?

I prototyped doing the read loop in Java and the performance seemed to be about the same. The problem is that the loop needs to exit when the native `read()` function performs a short read, i.e., fewer bytes are read than were requested. Without this, at least one regression test fails. The reason is not completely clear.

To detect such a short read in the Java layer would require some way for the native layer to notify the Java layer. One potential such method is

boolean readBytes(byte[] b, int off, int len, int[] nread) {}

where the return value indicates whether all or only some of the `len` bytes were read. If not all were read, then `nread[0]` would contain the number actually read or `-1`.

Another possibility is

int readBytes(byte[] b, int off, int len, int maxBufferSize) {}

which is identical to the current `readBytes()` except that the maximum transfer buffer size is specified as a method parameter instead of being defined by a symbolic constant in the native layer. In this case a short read would be detected if `len >= maxBufferSize` and the returned value is less than `maxBufferSize`.

As for the read loop being in native code, note that the write loop is also already in native code, so if the read loop were moved to Java, then probably the write loop should be as well.

One advantage of the loops being in native code is that there is only one `malloc()` per Java `read(byte[],int,int)` or `write(byte[],int,int)` invocation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From bpb at openjdk.java.net  Tue Apr 19 21:47:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Apr 2022 21:47:33 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available
In-Reply-To: <PQLG32LE0dPgWyqG2MrICHNy6yFEi5Xqo38MEh-XBfw=.36114622-1ff5-40e9-ae8a-c5aa9701139e@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <PQLG32LE0dPgWyqG2MrICHNy6yFEi5Xqo38MEh-XBfw=.36114622-1ff5-40e9-ae8a-c5aa9701139e@github.com>
Message-ID: <3EpKtIOkN_RCOBV7TgMJiI7gwN3a7HCphv16bxBBmLU=.fb1eb5d1-c395-46e2-a390-5928a3b008b5@github.com>

On Thu, 14 Apr 2022 05:57:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The benchmark results are quite unexpected. Would we benefit from reducing the buffer size even further?

I tested with smaller and smaller buffer sizes until the performance started to be affected which was about 64 KB. I have not changed this value in the patch just yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From duke at openjdk.java.net  Tue Apr 19 22:21:27 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 22:21:27 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
Message-ID: <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>

On Tue, 19 Apr 2022 20:15:08 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - migrate HashSet usages
>  - migrate LinkedHashSet usage

Need to add apiNote documentation section to capacity-based constructors like for maps.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Tue Apr 19 22:26:29 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 22:26:29 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <P3J1Bz_PIuAoxNT1RZR66np38w9tPBq0_mUrj3X-tW4=.93b9c185-d711-4b9b-9d7e-b39014554455@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

@stuart-marks Mind peek at this given you are the assignee of the original JBS issue?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From duke at openjdk.java.net  Tue Apr 19 22:41:27 2022
From: duke at openjdk.java.net (jmehrens)
Date: Tue, 19 Apr 2022 22:41:27 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
 <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
Message-ID: <J11y9Ci5g5NmlLWcWm1qItJ0tVN4sil6bFaa_KF4Dek=.972b61cf-8ff4-440d-826b-ed92049914ca@github.com>

On Tue, 19 Apr 2022 18:04:03 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> no, we use other way, but yes for we take care of thread safety.

Fair enough.

> Don't think it necessary... I think making it cannot touched by other object (with security manager on) is enough.

I was thinking more for heapdumps due to extending the life of the skip buffer in this patch.  At least we don't have to waste more cycles.

Oh I forgot last time but, it looks like MIN_SKIP_BUFFER_SIZE is not used.  Unless I'm missing something I assume that is a bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue Apr 19 22:51:27 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 19 Apr 2022 22:51:27 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
Message-ID: <_YSHsJwOEA7xcvJbHyFvjvWMetGKjLSJwWCpun5HASE=.416f491f-7824-46ce-9f6a-d7083aecf9f0@github.com>

On Fri, 15 Apr 2022 18:56:37 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to liach operation.

src/java.base/share/classes/java/io/InputStream.java line 62:

> 60: 
> 61:     /** Skip buffer, null until allocated */
> 62:     private byte[] skipBuffer = null;

This can be removed too as you have the soft reference already.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From jiefu at openjdk.java.net  Tue Apr 19 23:18:27 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 19 Apr 2022 23:18:27 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <615b3xLgbKn1Vsj6JukH2McmpD6CKMvZn3nBIuJox1k=.fbf9da3a-d472-4cf4-8bc0-2cc1ffba06a4@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <615b3xLgbKn1Vsj6JukH2McmpD6CKMvZn3nBIuJox1k=.fbf9da3a-d472-4cf4-8bc0-2cc1ffba06a4@github.com>
Message-ID: <_VdXUnM_Zjm8XxTbbgbqYvfcTu0pF195xjMJ0y7enq0=.6eb21541-1572-4d6a-a10f-e665298772ca@github.com>

On Tue, 19 Apr 2022 17:40:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Not yet talked with John, but i investigated further. The implementation of the `LSHR` operation is behaving as intended, but is under specified with regards to `byte` and `short` as you noted in #8291.
> 
> This is a subtle area, but i am wondering if the user really means to use arithmetic shift in this case? Since is not the following true for all values of `e` and `c`, where `e` is a `byte` and `c` is the right shift count ranging from 0 to 7:
> 
> ```
> (byte) (e >>> c) == (byte) (e >> c)
> ```
> 
> ?
> 
> Then the user can use `VectorOperators.ASHR`.

Yes, in theory, the user can use `ASHR`.

But people have to be very careful about when to use `AHSR` and when to use `LSHR`, which is really inconvenient and easy to make a mistake.
And not all the people are smart enough to know this skill for bytes/shorts.

So to make it to be programmed more easily and also reduce the possibility to make mistakes, a new operator for scalar `>>>` would be helpful when vectorizing with Vector API.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From bpb at openjdk.java.net  Tue Apr 19 23:32:57 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 19 Apr 2022 23:32:57 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset
Message-ID: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>

Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.

-------------

Commit messages:
 - 8284930: Re-examine FilterInputStream mark/reset

Changes: https://git.openjdk.java.net/jdk/pull/8309/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8309&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284930
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8309/head:pull/8309

PR: https://git.openjdk.java.net/jdk/pull/8309

From darcy at openjdk.java.net  Tue Apr 19 23:41:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 19 Apr 2022 23:41:46 GMT
Subject: RFR: JDK-8280594: Refactor annotation invocation handler handling to
 use Objects.toIdentityString
Message-ID: <Wq8eMXeFC2jbIljboiqIescD9Bvvg6Mrn9BGyq1fKJc=.cbdace95-3615-406d-aeac-b6c7443efa53@github.com>

Simple refactoring to use new-in19 library code.

-------------

Commit messages:
 - JDK-8280594: Refactor annotation invocation handler handling to use Objects.toIdentityString

Changes: https://git.openjdk.java.net/jdk/pull/8310/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8310&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280594
  Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8310.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8310/head:pull/8310

PR: https://git.openjdk.java.net/jdk/pull/8310

From jiefu at openjdk.java.net  Tue Apr 19 23:51:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 19 Apr 2022 23:51:30 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <svt0BifkHPai3T6nNZxXClF-igsoocwiJKhUt158qp8=.472349d7-db66-42cc-873a-c183ce071ce7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <svt0BifkHPai3T6nNZxXClF-igsoocwiJKhUt158qp8=.472349d7-db66-42cc-873a-c183ce071ce7@github.com>
Message-ID: <bhj1GnNvRVa4EyeaaUrwXW7FSEuUDU-EWyOht44Q1jk=.b1155254-95ae-446c-b3c5-f69a8a1df34e@github.com>

On Tue, 19 Apr 2022 16:11:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I need to think a little more about this. The specification is not accurate and likely requires a CSR.
> 
> My initial thoughts are I would prefer the operation to retain reference to the succinct definition using the logical right shift operator but we add additional specification explaining the cases for `byte` and `short`, namely that the result is widened to an `int` as if by `(a & ((1 << ESIZE) - 1))` and the result narrowed. That's commonly (at least for the widening part) how `>>>` is used with `byte` and `short`, and i think would be clearer to be explicit in that regard.

OK.
To avoid confusing I would prefer using the description of `>>>` in the new vector operator, which would perform the same behavior as the scalar `>>>`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From psandoz at openjdk.java.net  Wed Apr 20 00:28:41 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 20 Apr 2022 00:28:41 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <EL0Kvf3wBvydf9ry_xHvJtIXSY-cIGqWFd3AgtcyG6Q=.81dd4036-ea92-4179-8391-86bedc0496ae@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

I am yet to be convinced we a 3rd vector right shift operator. We are talking about narrow cases of correct use which i believe can be supported with the existing operators. The user needs to think very careful when deviating from common right shift patterns on sub-words, which when deviated from can often imply misunderstanding and incorrect use, or an obtuse use. I would prefer to stick the existing operators and clarify their use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From psandoz at openjdk.java.net  Wed Apr 20 00:50:24 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 20 Apr 2022 00:50:24 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <j5JT5U8jVcGrZi9qGem1l1jz9eUtf9TMqWSRaMwYVcY=.a9bc734f-63a2-4ff7-bbea-5d046fb0b184@github.com>

On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

The intended pattern for the operator tokens is to present a short symbolic description using Java operators and common methods. It would be good to try and keep with this pattern, and clarify for the extra cases. Here's what i had in mind:

    /** Produce {@code a>>>(n&(ESIZE*8-1))}.  Integral only. 
      * <p>
      * For operand types {@code byte} and {@code short} the operation behaves as if the operand is first implicitly widened  
      * to an {@code int} value with {@code (a & ((1 << ESIZE) - 1))} the result of which is then applied as the operand to this 
      * operation, the result of the operation is then narrowed from {@code int} to the operand type using an explicit cast.
      */
    public static final /*bitwise*/ Binary LSHR;

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Wed Apr 20 01:03:23 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 20 Apr 2022 01:03:23 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v5]
In-Reply-To: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
Message-ID: <TAqzJVGwDaiNHsqmHnvjG8UQpffLiwwWU4W-iAXbU1o=.f6fdf06a-f5c4-43f3-825a-cfd227e9cf4c@github.com>

> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
> 
> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
> 
> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  some cleanup of the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/c5fef46b..15de2394

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8134&range=03-04

  Stats: 62 lines in 4 files changed: 21 ins; 27 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134

From jiefu at openjdk.java.net  Wed Apr 20 01:30:29 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 20 Apr 2022 01:30:29 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <j5JT5U8jVcGrZi9qGem1l1jz9eUtf9TMqWSRaMwYVcY=.a9bc734f-63a2-4ff7-bbea-5d046fb0b184@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <j5JT5U8jVcGrZi9qGem1l1jz9eUtf9TMqWSRaMwYVcY=.a9bc734f-63a2-4ff7-bbea-5d046fb0b184@github.com>
Message-ID: <oqE8Di3pEeX4CTYiLna4X2f8FejFURaIuNmfY8Z6Lxg=.f2246c83-dd85-4565-8517-db928e74933d@github.com>

On Wed, 20 Apr 2022 00:46:32 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The intended pattern for the operator tokens is to present a short symbolic description using Java operators and common methods. It would be good to try and keep with this pattern, and clarify for the extra cases. Here's what i had in mind:
> 
> ```
> /** Produce {@code a>>>(n&(ESIZE*8-1))}.  Integral only. 
>   * <p>
>   * For operand types {@code byte} and {@code short} the operation behaves as if the operand is first implicitly widened  
>   * to an {@code int} value with {@code (a & ((1 << ESIZE) - 1))} the result of which is then applied as the operand to this 
>   * operation, the result of the operation is then narrowed from {@code int} to the operand type using an explicit cast.
>   */
> public static final /*bitwise*/ Binary LSHR;
> ```

This works only if people would like to read the detailed description of `LSHR` carefully.

Actually, most developers would still see the brief description first.
<img width="1087" alt="image" src="https://user-images.githubusercontent.com/19923746/164127620-90a73d29-868e-46d8-9562-2c5b2021f13b.png">
 
If they don't click out the detailed description further or don't read it carefully, it's still misleading.

Maybe, we'd better not to use `>>>` in the brief description since `LSHR` behaves differently with the common used `>>>`.
What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From bchristi at openjdk.java.net  Wed Apr 20 01:47:00 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 20 Apr 2022 01:47:00 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
Message-ID: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>

Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.

The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.

Details of note: 
1. Some operations need to change the state values (the update() method is probably the most interesting).
2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.

The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.

The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 

Thanks.

-------------

Commit messages:
 - fix whitespace
 - Merge branch 'master' into remove-finalizers
 - Test changes to test new cleaner code
 - Rename test to LdapEnumeration
 - Create copy of AddNewEntry test to test AbstractLdapNamingEnumeration Cleaner
 - Merge branch 'master' into remove-finalizers
 - Replace AbstractLdapNamingEnumeration finalizer with Cleaner

Changes: https://git.openjdk.java.net/jdk/pull/8311/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283660
  Stats: 259 lines in 7 files changed: 192 ins; 20 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From sminervini.prism at protonmail.com  Wed Apr 20 02:40:16 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Wed, 20 Apr 2022 02:40:16 +0000
Subject: Improvement for Java SE/OpenJDK floating point?
Message-ID: <r85ZaaL5vf3naU1XFpGS69ofNuQAlm0kWj__jfgnahdqCplI7z8IjznGvrWtyp0I5G2axIi4Aq2JgHeTZJkx51r8FH_qCoKKfiRrJU5-5Tg=@protonmail.com>

To core-libs-dev and the Java Comunity Process Team,

It remains the case that I and others need Java floating point and StrictMath (the primary double type
calculator class) to be repaired away from all their denormal and pronormal value possibilities. It has been made
clear by a number of publicly available publication sources, irrespective of age, from their date of publication and
into the future, that with hardware registry additions already present in Java platform hardware, namely SSE versions
and beyond, that repair can and must be wrought for Java float and double numeric types utilised in both Java SE and
OpenJDK's runtime environments. This includes float and double ranges, whenever arithmetic operations at all or certain
method calls involving them are made, where the results manage to straddle the edge of those ranges.

float from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).
double from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

The issue is not ascription and reading of possible values in these types, within their ranges. The problem
is with arithmetic operations, +,-,*,/,%,+=,-=,*-,/=,%=, and function calls made upon them that are inside the
StrictMath class, and possibly consequences within any closely bound classes or interfaces, namely those with
Float and Double inside their names.

As we attempted to submit in previous messages to core-libs-dev, IEEE 754 is silent on pertinent matters
around decimal arithmetic, mainly certain end facts about binary and decimal use in computer software;
that they need to have total objectivity at all steps of the way. The proper precedent to draw from,
to inform floating point arithmetic and elementary functions, is not a standard with a small "blind spot",
leading to non sequitur, but two even earlier phenomenon. The first of these states that information and
behaviour can be encoded into a computer, so that such a machine can behave by means of that
information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans.

The second fact is that range complete decimal mathematics is for humans, and binary mathematics
is for computers. Therefore, for a decimal result to have proper meaning, it must be entirely correct within
its (rational, truncated) range. The most efficient and only meaningful thing to do to obtain absolutely all
that is to utilise additional (SEE and similar) registers, with appropriate sub-java code, to use all registry
space, including the extra space if needed for decimal/binary range end straddling values, to produce range
accurate Java results via improved operational logic.

It is known that having a little more registry space past the number (result range) limit, for use and
consideration, is the only range, base-10 perfect way to go. It is certainly better than the available
class approaches, which waste memory, speed, and lack important and appropriate auxiliary use options.

In more recent times, it has become the case that there are a number of OpenJDK-downstream Java vendors.
Some of them of suggested to us that the better thing would be for something to be done at the OpenJDK,
JCP level, so that they could follow.

It is also the general observation that FP changes not need not be default only, but that any number of
"switching" approaches are valid; a runtime switch, maybe even keyword additions for various Java code
spaces, data qualifiers, or qualifiers for main methods, Runnables or Threads, could be used to
enable/disable two different floating point operating phenomena, either separately or together. Even
including code that has been compiled already. If determined enough, both modes of floating point
operation could be made compatible on any level, assuaging any concerns there.

Using such an approach, there need be no concerns about a split in Java, or compatability since all
this means that everything remains "under the same roof". An example of is the changes in Java's
switch syntax, to immediate switch on a String, alongside the inclusion of the switch's -> operator.
People later used the simplest, most appropriate approach under their circumstances, updated their
body of learning (which happens within any java release automatically, anyway), kept coding along,
and everybody continued relating and coding sharing or integrating between one another, just as
concordantly as before.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper workaround, and provide corrected,
defaulting or even specifying-compatible, code compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without any denormal and pronormalvalue inclusions at all?

Sent with [ProtonMail](https://protonmail.com/) secure email.

From xgong at openjdk.java.net  Wed Apr 20 02:49:27 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 20 Apr 2022 02:49:27 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature
In-Reply-To: <CFDqLPf7iBeKTwj_20Imdqm1RbxqV8CA7rgtMZLvkfk=.d5c9224e-e3a3-4db6-b22b-e5b9c873ae26@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <qGT_pT7bJXtmGLdET7zfdn61OCP6K0qO3druyXapADc=.86ab137e-49d0-437c-ae54-90370c270ef6@github.com>
 <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com>
 <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com>
 <kqI-nPVHEWDVrqR16zP0gvSnLZJZhyFAmJ4maHvqqD8=.fec2585b-9785-478c-aa1c-5e80f320863c@github.com>
 <ObTJCUgfcC_HWOapui4POW4nfZ5WljmJtSQaKewL21U=.d4591ddf-0dbe-42b3-99fe-0faf376eaf08@github.com>
 <CFDqLPf7iBeKTwj_20Imdqm1RbxqV8CA7rgtMZLvkfk=.d5c9224e-e3a3-4db6-b22b-e5b9c873ae26@github.com>
Message-ID: <ShLFw_aG07Xu9hESNnl8dRU6l2oLAlSubKfCPRwkYFg=.be04c9e4-d18d-486f-b502-a6c207400d92@github.com>

On Mon, 11 Apr 2022 09:04:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The optimization for masked store is recorded to: https://bugs.openjdk.java.net/browse/JDK-8284050
>
>> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values.
> 
> It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary.  Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios.

Thanks for the comment! So how about adding the check for the valid array range like the masked vector load?
Codes like:

public final
    void intoArray(byte[] a, int offset,
                   VectorMask<Byte> m) {
        if (m.allTrue()) {
            intoArray(a, offset);
        } else {
            ByteSpecies vsp = vspecies();
            if (offset >= 0 && offset <= (a.length - vsp.length())) {     // a full range check
                intoArray0(a, offset, m, /* usePred */ false);                   // can be vectorized by load+blend_store
            } else {
                checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
                intoArray0(a, offset, m, /* usePred */ true);                    // only be vectorized by the predicated store
            }
        }
    }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Wed Apr 20 02:49:28 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 20 Apr 2022 02:49:28 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature
In-Reply-To: <fNRGaO8kqLFhu2LyZVxlocbH5kBHvOQ204gwyW2U0zQ=.605f77a3-bae7-4eb6-b654-2cd1ea8a6610@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <fNRGaO8kqLFhu2LyZVxlocbH5kBHvOQ204gwyW2U0zQ=.605f77a3-bae7-4eb6-b654-2cd1ea8a6610@github.com>
Message-ID: <Whjq4dmC2mgppNr4sCi270HLc-7yvEJnVxZKWlXJ-T0=.8e3449fa-9dc8-4bb2-aa20-1c5e1422dc32@github.com>

On Sat, 9 Apr 2022 00:10:40 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861:
> 
>> 2859:         ByteSpecies vsp = (ByteSpecies) species;
>> 2860:         if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) {
>> 2861:             return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo);
> 
> Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow.

Thanks for the review. I will change it later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From jiefu at openjdk.java.net  Wed Apr 20 03:33:24 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 20 Apr 2022 03:33:24 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <EL0Kvf3wBvydf9ry_xHvJtIXSY-cIGqWFd3AgtcyG6Q=.81dd4036-ea92-4179-8391-86bedc0496ae@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <EL0Kvf3wBvydf9ry_xHvJtIXSY-cIGqWFd3AgtcyG6Q=.81dd4036-ea92-4179-8391-86bedc0496ae@github.com>
Message-ID: <ZgGcSYEoM9PG8ocR9z4oD-WqyJb5AjftMkYfDONxtS0=.10e21e6f-25cd-4af5-8c5b-0e22739ef8c7@github.com>

On Wed, 20 Apr 2022 00:25:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I am yet to be convinced we a 3rd vector right shift operator. We are talking about narrow cases of correct use which i believe can be supported with the existing operators. The user needs to think very careful when deviating from common right shift patterns on sub-words, which when deviated from can often imply misunderstanding and incorrect use, or an obtuse use. I would prefer to stick the existing operators and clarify their use.

As we can see, `VectorOperators` has directly supported all the unary/binary scalar operators in the Java language except for `>>>`.
So it seems strange not to support `>>>` directly.

Since you are a Vector API expert, you know the semantics of `LSHR` precisely.
But for many Java developers, things are different.
I'm afraid most of them don't know Vector API actually has extended semantics of `>>>` upon bytes/shorts with `LSHR`.
To be honest, I didn't know it before my customer's bug even though I had spent enough time reading the Vector API doc.
This is because for ordinary developers, they are only familiar with the common scalar `>>>`.
So it seems easy to write bugs with the only `LSHR`, which is different with `>>>`.

>From the developer's point of view, I strongly suggest providing the `>>>` operator in Vector API.
Not only because `>>>` is one of the basic operators in Java language, but also we can make it to be more friendly to so many ordinary developers.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From iklam at openjdk.java.net  Wed Apr 20 06:32:30 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 20 Apr 2022 06:32:30 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <VJdkV2dbGYIz0B7D-rXf8RbeireXH-5Xco7z5qcFaSs=.fd827181-d1f8-4e60-8965-4000fc0394b5@github.com>

On Mon, 18 Apr 2022 09:07:31 GMT, xpbob <duke at openjdk.java.net> wrote:

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

Both the PR and the bug report are not clear about exactly what the problem is. 

Could you provide a test case that demonstrates the relationship between `memory.memsw.limit_in_bytes` and `memory.swappiness`? It will be best if you can upload a shell script into the bug report so we know the exact steps to reproduce the problem.

Ultimately we should add a new jtreg test case.


# scenario 1
memory.memsw.limit_in_bytes = 1000M
memory.limit_in_bytes = 50M
memory.swappiness = 1

-> "java -Xms60m -XX:+AlwaysPreTouch -version" can successfully complete

# scenario 2
memory.memsw.limit_in_bytes = 1000M
memory.limit_in_bytes = 50M
memory.swappiness = 0

-> "java -Xms60m -XX:+AlwaysPreTouch -version" will be killed by cgroups


Related to your other PR (https://github.com/openjdk/jdk/pull/8256), I think `CgroupV1Subsystem::memory_and_swap_limit_in_bytes()` also need to be changed so that it will return 50M in scenario 2.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From iklam at openjdk.java.net  Wed Apr 20 06:57:23 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 20 Apr 2022 06:57:23 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <yLrox8Oafj87mWSj8y65ngi17I-exRllezE2o1f0dv0=.36f1ba12-2bbe-47f9-8a8d-bf96702ee277@github.com>

On Mon, 18 Apr 2022 09:07:31 GMT, xpbob <duke at openjdk.java.net> wrote:

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

I changed the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8284900) summary to "CgroupV1 detection code should consider memory.swappiness"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From alanb at openjdk.java.net  Wed Apr 20 07:36:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Apr 2022 07:36:30 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset
In-Reply-To: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
Message-ID: <9Y5m6XPcl8-3YPO4YK0n3RdRP8P80sIVrDHp3rpoqUk=.e027a6a6-112a-41e9-87cf-e490bc6284f6@github.com>

On Tue, 19 Apr 2022 23:26:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.

I wonder if it should be removed from InputStream at the same time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From alanb at openjdk.java.net  Wed Apr 20 07:37:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Apr 2022 07:37:36 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v5]
In-Reply-To: <TAqzJVGwDaiNHsqmHnvjG8UQpffLiwwWU4W-iAXbU1o=.f6fdf06a-f5c4-43f3-825a-cfd227e9cf4c@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <TAqzJVGwDaiNHsqmHnvjG8UQpffLiwwWU4W-iAXbU1o=.f6fdf06a-f5c4-43f3-825a-cfd227e9cf4c@github.com>
Message-ID: <JZwVj-wIv00avLntUSQ0q1ozmwYuKJWnNZv4crJ4gE0=.b7a409a4-c7ba-4b45-ab13-7388b99131b4@github.com>

On Wed, 20 Apr 2022 01:03:23 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some cleanup of the test

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From sminervini.prism at protonmail.com  Wed Apr 20 08:15:32 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Wed, 20 Apr 2022 08:15:32 +0000
Subject: core-libs-dev Digest Vol 180 Issue 174 Topic 1
Message-ID: <iWIwzgDRMbtJb08bp90AU83UcY0KHfdwjHq4aHFxGawsnUwjY1bERKpHBclddSmJCkJz6HSMBMDkUv5FETTFf_-mP1aWlhJndc8gedsjyPU=@protonmail.com>

To the Java Community Process, and OpenJDK community,

A number of us have been waiting on serious consideration for apprehension of

core-libs-dev Digest Vol 180 Issue 174 Topic 1

since we have posted, but not received an addressal and apprehending response

in some time. We know that our posting comes soon after Easter. Still, we have

been wondering what the internal state of discussion is on the aforementioned

Topic 1, and are hoping that it can be apprehended, certainly in the compatible

manner it discusses, to gain the advantages discussed, while removing

disadvantages and bringing on board no real disadvantages, for the

Java OpenJDK and the Java Community at the more official level.

We wait with bated breath for a reply in future core-libs-dev

digests for a positive, active reply!

Sent with [ProtonMail](https://protonmail.com/) secure email.

From jdk at fiolino.de  Wed Apr 20 09:03:50 2022
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Wed, 20 Apr 2022 11:03:50 +0200
Subject: core-libs-dev Digest Vol 180 Issue 174 Topic 1
In-Reply-To: <iWIwzgDRMbtJb08bp90AU83UcY0KHfdwjHq4aHFxGawsnUwjY1bERKpHBclddSmJCkJz6HSMBMDkUv5FETTFf_-mP1aWlhJndc8gedsjyPU=@protonmail.com>
References: <iWIwzgDRMbtJb08bp90AU83UcY0KHfdwjHq4aHFxGawsnUwjY1bERKpHBclddSmJCkJz6HSMBMDkUv5FETTFf_-mP1aWlhJndc8gedsjyPU=@protonmail.com>
Message-ID: <fa1b4347-14b5-4b5a-8bad-2d6b8f623ac6@fiolino.de>

On 4/20/22 10:15, sminervini.prism wrote:
 > To the Java Community Process, and OpenJDK community,
 >
 > A number of us have been waiting on serious consideration for 
apprehension of
 >
 > core-libs-dev Digest Vol 180 Issue 174 Topic 1
 >
 > since we have posted, but not received an addressal and apprehending 
response
 >
 > in some time. We know that our posting comes soon after Easter. 
Still, we have
 >
 > been wondering what the internal state of discussion is on the 
aforementioned
 >
 > Topic 1, and are hoping that it can be apprehended, certainly in the 
compatible
 >
 > manner it discusses, to gain the advantages discussed, while removing
 >
 > disadvantages and bringing on board no real disadvantages, for the
 >
 > Java OpenJDK and the Java Community at the more official level.
 >
 > We wait with bated breath for a reply in future core-libs-dev
 >
 > digests for a positive, active reply!
 >
 > Sent with [ProtonMail](https://protonmail.com/) secure email.


Heeeh???? I don't understand a single word.
What is this "core-libs-dev Digest Vol 180 Issue 174 Topic 1" stuff you 
are talking about? It would help to refer to a concrete message instead 
of some digest number.

The only thing I can remember is that you were spamming the list with at 
least three identical postings which has been answered by Andrew right 
after the first message already.

If this is what you're asking for, here is what he wrote:

On 4/16/22 09:04, sminervini.prism wrote:
 > It is still the case that I and others need Java floating point and 
StrictMath
 > (the key double type calculator class) to be repaired.

If you are going to pursue this line of reasoning, you must be aware
of some things.

Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

 > May the Java Community Process reconsider the present floating point
 > operations and method calls situation, based on an imperfect
 > standard and improper workaround, and provide corrected, defaulting
 > or specifying-compatible waya for Java floating point arithmetic and
 > Calculator class method results to always cohere in their ranges,
 > without denormal and pronormal inclusion?

In a word, no. That possibility is so unlikely that it is not worthy
of consideration.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



From jpai at openjdk.java.net  Wed Apr 20 12:01:23 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 20 Apr 2022 12:01:23 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset
In-Reply-To: <9Y5m6XPcl8-3YPO4YK0n3RdRP8P80sIVrDHp3rpoqUk=.e027a6a6-112a-41e9-87cf-e490bc6284f6@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <9Y5m6XPcl8-3YPO4YK0n3RdRP8P80sIVrDHp3rpoqUk=.e027a6a6-112a-41e9-87cf-e490bc6284f6@github.com>
Message-ID: <LxP302SRDR3lxXUOSYN2aEm4J0y78-zzFGi1b56lffs=.f26d48c7-69ae-4f15-9260-28c3be314972@github.com>

On Wed, 20 Apr 2022 07:33:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if it should be removed from InputStream at the same time.

Interesting. I hadn't noticed `InputStream` had those two methods synchronized. I suspect removing synchronization from those two methods on `InputStream` is probably a lot more "simpler" (i.e. shouldn't impact any other code) since the `mark` was an empty implementation and `reset` throws an `IOException` stating mark/reset isn't supported. So if any subclasses of `InputStream` did indeed rely on mark/reset capability, then they would have already overridden these methods and dealt with any necessary synchronization themselves in those methods. So removing `synchronized` from these two methods in `InputStream`, I think is a good idea.

As for the changes to `FilterInputStream`, would this change require a CSR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From dfuchs at openjdk.java.net  Wed Apr 20 13:36:38 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Apr 2022 13:36:38 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset
In-Reply-To: <LxP302SRDR3lxXUOSYN2aEm4J0y78-zzFGi1b56lffs=.f26d48c7-69ae-4f15-9260-28c3be314972@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <9Y5m6XPcl8-3YPO4YK0n3RdRP8P80sIVrDHp3rpoqUk=.e027a6a6-112a-41e9-87cf-e490bc6284f6@github.com>
 <LxP302SRDR3lxXUOSYN2aEm4J0y78-zzFGi1b56lffs=.f26d48c7-69ae-4f15-9260-28c3be314972@github.com>
Message-ID: <zVOnFwLuansx1UFq4mD_2zJVrPING6i8twDZl1ZUbH0=.c9340990-7535-4d54-93e0-199086f85255@github.com>

On Wed, 20 Apr 2022 11:56:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> As for the changes to `FilterInputStream`, would this change require a CSR?

There might be a case where a subclass of `FilterInputStream` has overridden all other methods to add `synchronized` but has not overridden `mark` and `reset`, relying on the synchronization of the super class. I have skimmed over subclasses in the JDK, and have found no evidence of such behavior (though I have not looked exhaustively at all subclasses). Of course such subclasses could exist in the wild, but that would be both odd and fragile, since synchronization is not specified. In this particular case I don't believe that we would need a CSR to remove a synchronized keyword: whether a method is synchronized or not is not documented and not part of the spec: https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/io/FilterInputStream.html#mark(int) - and `FilterInputStream` says nothing about synchronization.

I agree with Alan that `InputStream` should be modified similarly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From rriggs at openjdk.java.net  Wed Apr 20 13:36:39 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 13:36:39 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset
In-Reply-To: <LxP302SRDR3lxXUOSYN2aEm4J0y78-zzFGi1b56lffs=.f26d48c7-69ae-4f15-9260-28c3be314972@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <9Y5m6XPcl8-3YPO4YK0n3RdRP8P80sIVrDHp3rpoqUk=.e027a6a6-112a-41e9-87cf-e490bc6284f6@github.com>
 <LxP302SRDR3lxXUOSYN2aEm4J0y78-zzFGi1b56lffs=.f26d48c7-69ae-4f15-9260-28c3be314972@github.com>
Message-ID: <XVu4dPchvN2fez5Vc9PT_r8_1C_kySBixib6ApPcgXw=.28d977f3-b1fd-4dd6-a545-4730899ba52d@github.com>

On Wed, 20 Apr 2022 11:56:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I wonder if it should be removed from InputStream at the same time.

I took the presence of synchronized on those empty methods as a hint to subclasses that they too should be synchronized.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From kevinw at openjdk.java.net  Wed Apr 20 14:04:32 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 20 Apr 2022 14:04:32 GMT
Subject: RFR: 8284853: Fix various 'expected' typo [v2]
In-Reply-To: <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>
References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com>
 <bisAVGnhNiqxb9oNb7lsqrjIO84qDRUeqyfw7p7jSME=.e2b1b6c3-fc70-4b5b-8cb2-d1987de9a7dd@github.com>
 <rNQ6IxlRdqzXlRKEfw2Hnyn7pI5_h3ydBV_grUrKfe0=.82d95656-bdd3-4607-a12d-5964ac33f53a@github.com>
 <b2zhGMW2RG0f8ZRDrnI8nSfW-JeuZx8-DNvJaGRXu4g=.dcfbe0fb-6f7c-4f46-8fbe-458a42f7ca21@github.com>
Message-ID: <eqgDmfDmNbkCo4R5oiilfxQxAs12V1ZP453zph4DSms=.1595dc28-ee07-43e1-b36d-4e2bc0fb3e36@github.com>

On Thu, 14 Apr 2022 18:04:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948) ...

I didn't think "JVMInvokeMethodSlack" was a typo.  I think it's the idea of "slack space" meaning leftover space.  We require a certain amount of this space.  We need some slack on the stack, in order to invoke.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8231

From vromero at openjdk.java.net  Wed Apr 20 14:54:28 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 14:54:28 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

nit: just ran langtools tests as part of my routine and these seem to be failing, CheckExamples.java due to:
test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java and
test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java

and this one too:
test/langtools/tools/javac/patterns/InstanceofTotalPattern.java (seems to be a golden file issue)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From bpb at openjdk.java.net  Wed Apr 20 15:33:26 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 20 Apr 2022 15:33:26 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
Message-ID: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>

> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8284930: Also remove synchronized keyword from mark() and reset() of InputStream

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8309/files
  - new: https://git.openjdk.java.net/jdk/pull/8309/files/85546c9e..f210cbf5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8309&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8309&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8309/head:pull/8309

PR: https://git.openjdk.java.net/jdk/pull/8309

From vromero at openjdk.java.net  Wed Apr 20 15:37:28 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 15:37:28 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <kRIP4DuRuPFxvGGHNRYrVvZ_w1E104zlFIwbNRnIcJ0=.427ef7ac-7bc7-4bcf-abc0-fc959dd0b776@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 20222, Oracle and/or its affiliates. All rights reserved.

typo: `20222` instead of `2022`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Wed Apr 20 16:03:17 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:03:17 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16
Message-ID: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>

some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/

            if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
                continue;
            }

should be changed to 

            if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
                continue;
            }

as:

1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

-------------

Commit messages:
 - 9073087: refine StringLatin1.regionMatchesCI_UTF16

Changes: https://git.openjdk.java.net/jdk/pull/8308/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8308&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285255
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8308.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8308/head:pull/8308

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Wed Apr 20 16:07:17 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:07:17 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v8]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <563ZJ4Mi8vbpr_S4GRL5O3bkFELb84nW44zNiVKKxG0=.e5eec151-8946-4bde-8e1c-c3e4677aaa3e@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  remove useless skipBuffer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/9854f523..31652c3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:07:18 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:07:18 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <_YSHsJwOEA7xcvJbHyFvjvWMetGKjLSJwWCpun5HASE=.416f491f-7824-46ce-9f6a-d7083aecf9f0@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <_YSHsJwOEA7xcvJbHyFvjvWMetGKjLSJwWCpun5HASE=.416f491f-7824-46ce-9f6a-d7083aecf9f0@github.com>
Message-ID: <OKWtcFX9AMK0n5mTYliO02O0_I3Uz4GSHTzfoORyvI8=.47724ff3-99ca-44e5-b3fa-44d2361d7014@github.com>

On Tue, 19 Apr 2022 22:47:42 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change to liach operation.
>
> src/java.base/share/classes/java/io/InputStream.java line 62:
> 
>> 60: 
>> 61:     /** Skip buffer, null until allocated */
>> 62:     private byte[] skipBuffer = null;
> 
> This can be removed too as you have the soft reference already.

@liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:07:42 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:07:42 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
Message-ID: <oCgYeid2PelAhcQ-Ac_9mgqjZDIlloHE0AuDa22gTy8=.1d36340a-a305-418f-8579-2b7f194bcd38@github.com>

On Tue, 19 Apr 2022 20:15:08 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - migrate HashSet usages
>  - migrate LinkedHashSet usage

> /csr needed

@stuart-marks csr please

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Wed Apr 20 16:17:41 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 20 Apr 2022 16:17:41 GMT
Subject: RFR: JDK-8280594: Refactor annotation invocation handler handling
 to use Objects.toIdentityString
In-Reply-To: <Wq8eMXeFC2jbIljboiqIescD9Bvvg6Mrn9BGyq1fKJc=.cbdace95-3615-406d-aeac-b6c7443efa53@github.com>
References: <Wq8eMXeFC2jbIljboiqIescD9Bvvg6Mrn9BGyq1fKJc=.cbdace95-3615-406d-aeac-b6c7443efa53@github.com>
Message-ID: <Nd4BHp8ecwmNxjw5e1GgJSPI8Za5HKBtDI8xXLJp0dw=.d436b9e0-d842-47be-94f8-14a38514e818@github.com>

On Tue, 19 Apr 2022 23:34:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple refactoring to use new-in19 library code.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8310

From duke at openjdk.java.net  Wed Apr 20 16:18:44 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:18:44 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v5]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <CYj6-GyaAxErc9z6pGis8ZClYKdtPArDCKi00VfsVpo=.a7d3e0b8-e6bb-4ad2-bfda-2dfcb5b26a17@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add apiNote s

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/f051c1fa..26bb5792

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=03-04

  Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Apr 20 16:18:47 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:18:47 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
 <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>
Message-ID: <9PqOY0Ho6mgINFO8ya5NeaZZB3RaATgWx7LJ-ESRSds=.37fdca9a-7af5-4ba5-8c85-baf9d33013ac@github.com>

On Tue, 19 Apr 2022 22:17:54 GMT, liach <duke at openjdk.java.net> wrote:

> Need to add apiNote documentation section to capacity-based constructors like for maps.

@liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Apr 20 16:19:37 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 20 Apr 2022 16:19:37 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v8]
In-Reply-To: <563ZJ4Mi8vbpr_S4GRL5O3bkFELb84nW44zNiVKKxG0=.e5eec151-8946-4bde-8e1c-c3e4677aaa3e@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <563ZJ4Mi8vbpr_S4GRL5O3bkFELb84nW44zNiVKKxG0=.e5eec151-8946-4bde-8e1c-c3e4677aaa3e@github.com>
Message-ID: <UY9zIV1VMI4o2ebyqNFvdJk9a88NcJDfLY7LrH-MHDI=.e01596c0-22c1-4f15-b355-174a1bd20202@github.com>

On Wed, 20 Apr 2022 16:07:17 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove useless skipBuffer

src/java.base/share/classes/java/io/InputStream.java line 57:

> 55:     private static final int MAX_SKIP_BUFFER_SIZE = 2048;
> 56: 
> 57:     private static final int MIN_SKIP_BUFFER_SIZE = 128;

@jmehrens mentioned that this one can be removed as well since it's not used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From darcy at openjdk.java.net  Wed Apr 20 16:24:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 20 Apr 2022 16:24:29 GMT
Subject: Integrated: JDK-8280594: Refactor annotation invocation handler
 handling to use Objects.toIdentityString
In-Reply-To: <Wq8eMXeFC2jbIljboiqIescD9Bvvg6Mrn9BGyq1fKJc=.cbdace95-3615-406d-aeac-b6c7443efa53@github.com>
References: <Wq8eMXeFC2jbIljboiqIescD9Bvvg6Mrn9BGyq1fKJc=.cbdace95-3615-406d-aeac-b6c7443efa53@github.com>
Message-ID: <BG4pxZ-cbCTDHZexqz9ok_Z8x6vxQM4VoxRQZHADS5k=.ae5cfd26-7aa3-4cbd-b06c-bb71e9fd6682@github.com>

On Tue, 19 Apr 2022 23:34:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple refactoring to use new-in19 library code.

This pull request has now been integrated.

Changeset: e6c5f288
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6c5f2886c39a95e660dd3d83d894fd3761b7468
Stats:     10 lines in 1 file changed: 0 ins; 9 del; 1 mod

8280594: Refactor annotation invocation handler handling to use Objects.toIdentityString

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8310

From duke at openjdk.java.net  Wed Apr 20 16:30:19 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:30:19 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v9]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <sIVEitjxoJr-HpNYH62Ojl0eiH7Jg88RGp8PVz8Cffg=.1524bc24-8d06-4419-a39a-5a10e9151c8c@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  remove uselsee MIN_SKIP_BUFFER_SIZE

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/31652c3a..696aa53b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:30:20 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:30:20 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v8]
In-Reply-To: <UY9zIV1VMI4o2ebyqNFvdJk9a88NcJDfLY7LrH-MHDI=.e01596c0-22c1-4f15-b355-174a1bd20202@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <563ZJ4Mi8vbpr_S4GRL5O3bkFELb84nW44zNiVKKxG0=.e5eec151-8946-4bde-8e1c-c3e4677aaa3e@github.com>
 <UY9zIV1VMI4o2ebyqNFvdJk9a88NcJDfLY7LrH-MHDI=.e01596c0-22c1-4f15-b355-174a1bd20202@github.com>
Message-ID: <Vdo9tRfUZQzCcRt6shOenHEvV8W7R3s7qyclQOQTP5A=.11206452-0d47-4f31-a474-ccc31c72d568@github.com>

On Wed, 20 Apr 2022 16:16:05 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove useless skipBuffer
>
> src/java.base/share/classes/java/io/InputStream.java line 57:
> 
>> 55:     private static final int MAX_SKIP_BUFFER_SIZE = 2048;
>> 56: 
>> 57:     private static final int MIN_SKIP_BUFFER_SIZE = 128;
> 
> @jmehrens mentioned that this one can be removed as well since it's not used.

@jmehrens @liach you are correct. done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From alexey.semenyuk at oracle.com  Wed Apr 20 16:38:37 2022
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 20 Apr 2022 12:38:37 -0400
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <e0e83867dd51406d2e70d6a8c62619f6a607edd7.camel@gmx.net>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
 <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
 <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>
 <3039fd70-e60f-33a7-23c8-29dae8327d1b@oracle.com>
 <e0e83867dd51406d2e70d6a8c62619f6a607edd7.camel@gmx.net>
Message-ID: <9cdecf04-78b2-bb13-6c8a-768b65fc4a35@oracle.com>



On 4/18/2022 7:06 PM, Hiran Chaudhuri wrote:
> On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote:
>> I've filed [1] and [2] CRs to track the issues.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8284973
>> [2] https://bugs.openjdk.java.net/browse/JDK-8284974
>>
>> - Alexey
> Sounds great. Thank you.
>
> While we are at improving JPackage, there are a few more items I
> stumbled over:
>
> a) When running jpackage on Linux, a freedesktop.org style starter file
> is created - but one more line in there would make it a lot more
> usable:
> https://urldefense.com/v3/__https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzhG0W4A9$
>
> b) The solution is to override resource files. Meanwhile I found out
> the resource files are templates, and jpackage replaces specific
> strings in these files. This however is nowhere mentioned in the
> documentation.
Must the value of "StartupWMClass" property in .desktop file be 
synchronized with the value used in the app or it can be any unique value?
If the latter, jpackage can create unique value for every launcher based 
on package and launcher names.
Otherwise, if the value must be synchronized with the value used in the 
app it must be supplied to jpackage. In this case, overriding .desktop 
template is the way to go.

>
> c) Running jpackage in two phases as I do (1: create app-image, 2:
> create final package) I learned that --name has to be specified in both
> runs. When running jpackage on MacOS however the second run needs the
> application name postfixed with .app otherwise jpackage won't find the
> directory it created in the first run. See the logs
> https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzplJmV2G$
> and
> https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8Dzmh3le2h$
--name is optional parameter in both runs. Check out 
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java 
testing this feature.
I guess you mean "--app-image" parameter, not "--name" parameter. ".app" 
suffix in app image name on macOS is a legacy jpackage inherited from 
JavaFX's javapackager.

I've filed [1] to track this issue. It may be discarded for the sake of 
backward compatibility though.

[1] https://bugs.openjdk.java.net/browse/JDK-8285265

- Alexey

>
> Hiran
>


From duke at openjdk.java.net  Wed Apr 20 16:39:28 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:39:28 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v10]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <EQ3L7FPATA5rPD35_ZhYwUZr6Drz6MPQFE6MT74Z6co=.47de7317-5ca2-4cb0-83f4-ee609aa8b9eb@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  comment added.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/696aa53b..878deebf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=08-09

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:39:29 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:39:29 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <J11y9Ci5g5NmlLWcWm1qItJ0tVN4sil6bFaa_KF4Dek=.972b61cf-8ff4-440d-826b-ed92049914ca@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
 <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
 <J11y9Ci5g5NmlLWcWm1qItJ0tVN4sil6bFaa_KF4Dek=.972b61cf-8ff4-440d-826b-ed92049914ca@github.com>
Message-ID: <eIV170ZddGZdrvsmFhGKOgTV0z2flhzUFpg1Q2V6nvg=.de4a7f39-829e-4cf0-9213-d1cb8cfd0c24@github.com>

On Tue, 19 Apr 2022 22:37:21 GMT, jmehrens <duke at openjdk.java.net> wrote:

>>> > @jmehrens what about this then? I think it safe now(actually this mechanism is learned from Reader)
>>> 
>>> Reader uses a lock object and it appears that InputStream locks on this (per make/reset) I would assume now that you have some object member fields you need to hold some lock while accessing those. Even though single thread access would be the expected case.
>> 
>> no, we use other way, but yes for we take care of thread safety.
>> 
>>> Not related but, it looks like the static buffer issue has come up a few times. Maybe time to add a test to: https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/InputStream/Skip.java that would fail if the skip buffer is static?
>> 
>> I think it is worthy to add some comments, but a test for it sound a little bit extreme.
>> 
>>> Not really the primary issue but, it seems questionable to me that we don't have to fill the skip buffer with zeros after the last read. That way any sensitive information that was skipped would also be forgotten. Matching with Reader seems more important for now.
>> 
>> Don't think it necessary... I think making it cannot touched by other object (with security manager on) is enough.
>
>> no, we use other way, but yes for we take care of thread safety.
> 
> Fair enough.
> 
>> Don't think it necessary... I think making it cannot touched by other object (with security manager on) is enough.
> 
> I was thinking more for heapdumps due to extending the life of the skip buffer in this patch.  At least we don't have to waste more cycles.
> 
> Oh I forgot last time but, it looks like MIN_SKIP_BUFFER_SIZE is not used.  Unless I'm missing something I assume that is a bug.

@jmehrens comments about not making it static added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:39:30 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 20 Apr 2022 16:39:30 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v9]
In-Reply-To: <sIVEitjxoJr-HpNYH62Ojl0eiH7Jg88RGp8PVz8Cffg=.1524bc24-8d06-4419-a39a-5a10e9151c8c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <sIVEitjxoJr-HpNYH62Ojl0eiH7Jg88RGp8PVz8Cffg=.1524bc24-8d06-4419-a39a-5a10e9151c8c@github.com>
Message-ID: <KzWPXxLOKXtY9h-z3_kdG0P6k77nAGIU8oaYmWLx_aI=.7c8ae1a3-609a-4d60-a5bb-e33300dd5141@github.com>

On Wed, 20 Apr 2022 16:30:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove uselsee MIN_SKIP_BUFFER_SIZE

src/java.base/share/classes/java/io/InputStream.java line 62:

> 60: 
> 61:     private byte[] skipBufferReference(long remaining) {
> 62:         int size = (int) Math.min(MAX_SKIP_BUFFER_SIZE, remaining);

This is now redundant. Can change parameter to (int size) directly

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:43:18 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:43:18 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v11]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <JKrYL0SrSe8Z9uI-zYjQZO8gZ_BuhBuurA1bVqDNxSQ=.76a1e902-0902-4546-ae01-72d9d915f12a@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  skipBufferReference(long) -> skipBufferReference(int)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/878deebf..47d8e195

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:52:35 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:52:35 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v9]
In-Reply-To: <KzWPXxLOKXtY9h-z3_kdG0P6k77nAGIU8oaYmWLx_aI=.7c8ae1a3-609a-4d60-a5bb-e33300dd5141@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <sIVEitjxoJr-HpNYH62Ojl0eiH7Jg88RGp8PVz8Cffg=.1524bc24-8d06-4419-a39a-5a10e9151c8c@github.com>
 <KzWPXxLOKXtY9h-z3_kdG0P6k77nAGIU8oaYmWLx_aI=.7c8ae1a3-609a-4d60-a5bb-e33300dd5141@github.com>
Message-ID: <OaqXjiL4jK6FoqerWz4b_6pUBBf-XYqTQxkpEoK1iaU=.1ab94d39-b87e-47e4-8e0f-0839ea3c4c07@github.com>

On Wed, 20 Apr 2022 16:35:25 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove uselsee MIN_SKIP_BUFFER_SIZE
>
> src/java.base/share/classes/java/io/InputStream.java line 62:
> 
>> 60: 
>> 61:     private byte[] skipBufferReference(long remaining) {
>> 62:         int size = (int) Math.min(MAX_SKIP_BUFFER_SIZE, remaining);
> 
> This is now redundant. Can change parameter to (int size) directly

@liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Wed Apr 20 16:52:31 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 16:52:31 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v12]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add documents

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/47d8e195..fbc24743

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=10-11

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From rriggs at openjdk.java.net  Wed Apr 20 16:53:28 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 16:53:28 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <-3MYLP5SNupUW8X6mrRsxJdtY3-GP_mJNSkrDn4O4WI=.091adee5-e986-494b-973f-9f3ce3349702@github.com>

On Tue, 19 Apr 2022 21:15:29 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

Point 1 make sense.
Point 2 adds a branch and branches aren't free.
Can you show some jmh data for these cases?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From mchung at openjdk.java.net  Wed Apr 20 17:02:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Apr 2022 17:02:26 GMT
Subject: RFR: JDK-8281006 Module::getResourceAsStream should check if the
 resource is open unconditionally when caller is null [v5]
In-Reply-To: <TAqzJVGwDaiNHsqmHnvjG8UQpffLiwwWU4W-iAXbU1o=.f6fdf06a-f5c4-43f3-825a-cfd227e9cf4c@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
 <TAqzJVGwDaiNHsqmHnvjG8UQpffLiwwWU4W-iAXbU1o=.f6fdf06a-f5c4-43f3-825a-cfd227e9cf4c@github.com>
Message-ID: <YVwkcnAGNybtk4aFojbyw3ITDzOuxu2Z7y8uvap0ud8=.1533a02e-f9d3-4543-84b0-9e35023fcbde@github.com>

On Wed, 20 Apr 2022 01:03:23 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
>> 
>> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
>> 
>> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
>> 
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>> 
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>> 
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>> 
>> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some cleanup of the test

Thanks for the test update.  Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8134

From duke at openjdk.java.net  Wed Apr 20 17:06:30 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 20 Apr 2022 17:06:30 GMT
Subject: Integrated: JDK-8281006 Module::getResourceAsStream should check if
 the resource is open unconditionally when caller is null
In-Reply-To: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
References: <YyXsx-l3Drd7JTjlwOzY1xEuFZenFYaLDzPeitMFKZI=.e7a47005-d304-4a87-8085-1e7b764a17d6@github.com>
Message-ID: <2UJT7EFSM63m1fASTLLZHENf3R5dX99RukacafHMKwU=.11f2bb9c-4b84-4357-b09c-ef0af220eb6c@github.com>

On Thu, 7 Apr 2022 00:38:07 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> Created a test called NullCallerGetResource to test Module::getResourceAsStream and Class::getResourceAsStream from the native level.
> 
> At the java level the test builds a test module called 'n' which opens the package 'open' to everyone. There is also a package 'closed' which is neither opened or exported. Both packages have a text file called 'test.txt'. The open package has a class called OpenResources and the closed package has a class called ClosedResources. The native test is launched with the test module n added.
> 
> At the native level the test tries to read both the open and closed resource from both the classes and the module. It performs the equivalent of the following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The Module class was fixed by removing the fragment with the (caller == null) test in getResourceAsStream, and changing the call to isOpen(String,Module) to use EVERYONE_MODULE if the caller module is null.

This pull request has now been integrated.

Changeset: e8016f74
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8016f74438ca5c64a8aab81e2fc2533e9b9f8ad
Stats:     393 lines in 8 files changed: 385 ins; 0 del; 8 mod

8281006: Module::getResourceAsStream should check if the resource is open unconditionally when caller is null

Reviewed-by: alanb, erikj, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8134

From vromero at openjdk.java.net  Wed Apr 20 17:13:41 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 20 Apr 2022 17:13:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
Message-ID: <ZY82MogWcdxTCmL8iecfLJagbR9XGGz6uIO1xY88c3g=.65814a1b-4063-4793-9502-41eb9030681e@github.com>

On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - more total -> unconditional pattern renaming.

I don't have any other comments, looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8182

From psandoz at openjdk.java.net  Wed Apr 20 17:28:27 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 20 Apr 2022 17:28:27 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <MUPQmersb0YhbyWhFJoVqAvCwrvnqjIzZY8OfLVn634=.8baec30e-434e-4c49-9abd-9fa5ac88ef5a@github.com>

On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

We can raise attention to that:

/** Produce {@code a>>>(n&(ESIZE*8-1))} 
  * (The operand and result are converted if the operand type is {@code byte} or {@code short}, see below).  Integral only.
  * ...
  */

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Wed Apr 20 17:30:27 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 17:30:27 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <-3MYLP5SNupUW8X6mrRsxJdtY3-GP_mJNSkrDn4O4WI=.091adee5-e986-494b-973f-9f3ce3349702@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <-3MYLP5SNupUW8X6mrRsxJdtY3-GP_mJNSkrDn4O4WI=.091adee5-e986-494b-973f-9f3ce3349702@github.com>
Message-ID: <XAhuT_PW5ZA5RoRhT6Pq6aE2ZiCSSsQW9NV5hnUaa6I=.2ef31f83-da8f-4463-99a3-61afbb5391dc@github.com>

On Wed, 20 Apr 2022 16:50:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Point 1 make sense. Point 2 adds a branch and branches aren't free. Can you show some jmh data for these cases?

@RogerRiggs

Bad news is I don't know how to make a jmh benchmark for a not-public class...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From rriggs at openjdk.java.net  Wed Apr 20 17:44:27 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 17:44:27 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <dESxxoqe4j6jBleKqEVwtH-JbL6EsckHRmkWRioicqA=.7019786f-5bab-4b26-a25d-aa5298babe73@github.com>

On Tue, 19 Apr 2022 21:15:29 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

The test should be able to use public string classes with selected Latin1 and utf-16 arguments.
The implementation of regionMatches will end up using the corresponding implementations.
The JMH in PR#8292 might be a start.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From joehw at openjdk.java.net  Wed Apr 20 17:49:52 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 17:49:52 GMT
Subject: RFR: 8284920: Incorrect Token type causes XPath expression to return
 incorrect results
Message-ID: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>

Patch note:

The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. 
While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR).

Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result.

Test: all XML tests passed.

-------------

Commit messages:
 - 8284920: Incorrect Token type causes XPath expression to return incorrect results

Changes: https://git.openjdk.java.net/jdk/pull/8321/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8321&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284920
  Stats: 113 lines in 3 files changed: 111 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8321.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8321/head:pull/8321

PR: https://git.openjdk.java.net/jdk/pull/8321

From duke at openjdk.java.net  Wed Apr 20 18:18:25 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 20 Apr 2022 18:18:25 GMT
Subject: RFR: 8284950: Swappiness disables swap space usage [v2]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <TADeHt5arKp8t1c9TlHmYZQHHMHslhlD_h0VxZpl-uY=.899e478f-53cd-49d1-b606-b8a7c311feea@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  add test and hotspot data

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/52cd6411..cda7f85b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=00-01

  Stats: 23 lines in 2 files changed: 19 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From joehw at openjdk.java.net  Wed Apr 20 18:28:19 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 18:28:19 GMT
Subject: RFR: 8284920: Incorrect Token type causes XPath expression to
 return incorrect results [v2]
In-Reply-To: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
References: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
Message-ID: <B1NbvPKx0UsxWtFL5wzsY4U3X-vHbNxWkT0BZsOY5t0=.83c50b3c-4dbc-4060-a02e-dc72e2eb3dee@github.com>

> Patch note:
> 
> The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. 
> While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR).
> 
> Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result.
> 
> Test: all XML tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add test cases for the self axis

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8321/files
  - new: https://git.openjdk.java.net/jdk/pull/8321/files/cb5e5ec3..3b61789e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8321&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8321&range=00-01

  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8321.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8321/head:pull/8321

PR: https://git.openjdk.java.net/jdk/pull/8321

From naoto at openjdk.java.net  Wed Apr 20 18:33:27 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 20 Apr 2022 18:33:27 GMT
Subject: RFR: 8284920: Incorrect Token type causes XPath expression to
 return incorrect results [v2]
In-Reply-To: <B1NbvPKx0UsxWtFL5wzsY4U3X-vHbNxWkT0BZsOY5t0=.83c50b3c-4dbc-4060-a02e-dc72e2eb3dee@github.com>
References: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
 <B1NbvPKx0UsxWtFL5wzsY4U3X-vHbNxWkT0BZsOY5t0=.83c50b3c-4dbc-4060-a02e-dc72e2eb3dee@github.com>
Message-ID: <kLWCJ1XI9gxmlN2FpHcyRpyeOz7qdGRe1lNjsCZvrp8=.baa05bf4-3a4f-4ce7-88d7-a909435835c7@github.com>

On Wed, 20 Apr 2022 18:28:19 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Patch note:
>> 
>> The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. 
>> While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR).
>> 
>> Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result.
>> 
>> Test: all XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test cases for the self axis

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8321

From alanb at openjdk.java.net  Wed Apr 20 18:43:24 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Apr 2022 18:43:24 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <JYOF1wrS39ylvPLErV7qw6N4vHkVS8KE9tJgUHDhu3o=.7ff08dbd-8ce1-426d-bf50-751ced96af8a@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Thanks for the update. I can't think how anything could depend on this but unfortunately it's been like that since early JDK releases. We will need a release note, I'm sure Joe will give his opinion on whether a CSR should be created.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From sgehwolf at openjdk.java.net  Wed Apr 20 18:44:30 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 20 Apr 2022 18:44:30 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v2]
In-Reply-To: <TADeHt5arKp8t1c9TlHmYZQHHMHslhlD_h0VxZpl-uY=.899e478f-53cd-49d1-b606-b8a7c311feea@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <TADeHt5arKp8t1c9TlHmYZQHHMHslhlD_h0VxZpl-uY=.899e478f-53cd-49d1-b606-b8a7c311feea@github.com>
Message-ID: <P6PlMMu9iwGo-izm-fb820IDCMlXm7Y61m1pkCIqVJs=.f35f29f8-6a7b-4359-bc0f-7c0523307df9@github.com>

On Wed, 20 Apr 2022 18:18:25 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test and hotspot data

Changes requested by sgehwolf (Reviewer).

test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 164:

> 162:             opts.addDockerOpts("--memory-swappiness", "0");
> 163:         } else {
> 164:             opts.addDockerOpts("--memory-swappiness", "60");

Unfortunately this breaks on a cgroups v2 system as `--memory-swappiness` is not supported there. I'd prefer if this wouldn't piggy back on the existing test, but actually assert that swap is properly reported as the same as the memory limit if `--memory-swappiness=0`. Also, this test only verifies the Java (core-libs) change, not the hotspot change. That would have to be done via some `TestMisc` variant which uses `print_container_info()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From lancea at openjdk.java.net  Wed Apr 20 18:46:36 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 20 Apr 2022 18:46:36 GMT
Subject: RFR: 8284920: Incorrect Token type causes XPath expression to
 return incorrect results [v2]
In-Reply-To: <B1NbvPKx0UsxWtFL5wzsY4U3X-vHbNxWkT0BZsOY5t0=.83c50b3c-4dbc-4060-a02e-dc72e2eb3dee@github.com>
References: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
 <B1NbvPKx0UsxWtFL5wzsY4U3X-vHbNxWkT0BZsOY5t0=.83c50b3c-4dbc-4060-a02e-dc72e2eb3dee@github.com>
Message-ID: <a2M_q3mg3X1sFs5m7OW_Mqz35Fkh6ceh0qbHIDDlXjA=.ae9a794d-ff94-42b2-ad8a-89d6fbd7d2a6@github.com>

On Wed, 20 Apr 2022 18:28:19 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Patch note:
>> 
>> The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. 
>> While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR).
>> 
>> Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result.
>> 
>> Test: all XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test cases for the self axis

Looks good to me Joe

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8321

From smarks at openjdk.java.net  Wed Apr 20 18:47:32 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 20 Apr 2022 18:47:32 GMT
Subject: Integrated: 8282120: optimal capacity tests and test library need to
 be cleaned up
In-Reply-To: <oiX4bM6_K8taNDNJp2NY8wf2-QHQ6kIOMEc-YyJQS7Y=.db4fdab4-58d4-49f0-b2f0-1fcb0da55ad7@github.com>
References: <oiX4bM6_K8taNDNJp2NY8wf2-QHQ6kIOMEc-YyJQS7Y=.db4fdab4-58d4-49f0-b2f0-1fcb0da55ad7@github.com>
Message-ID: <iXs9349emSNwDIopVSAAKh64TLpY6e69MS9WrYWA8rc=.ceed23aa-6eb1-44bf-be58-bfc51529da8c@github.com>

On Tue, 19 Apr 2022 18:12:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> The test `java/lang/Enum/ConstantDirectoryOptimalCapacity.java` was problem-listed by [JDK-8281631](https://bugs.openjdk.java.net/browse/JDK-8281631) and essentially superseded by [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). Given this, the test should simply be removed. This test is the only test that depends on a test library utility `test/lib/jdk/test/lib/util/OptimalCapacity.java` which has a number of issues of its own, so it should simply be removed as well.
> 
> See the bug report, in particular the comment
> 
> https://bugs.openjdk.java.net/browse/JDK-8282120?focusedCommentId=14489450&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14489450
> 
> for detailed discussion.

This pull request has now been integrated.

Changeset: b2c33f0f
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2c33f0f86174f5a8cf2229a3f766a2a8cff9d27
Stats:     355 lines in 3 files changed: 0 ins; 355 del; 0 mod

8282120: optimal capacity tests and test library need to be cleaned up

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8303

From rriggs at openjdk.java.net  Wed Apr 20 18:57:45 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 18:57:45 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <MqKT48FIA2CEwIkV8eM6LoC-uenYsptAnBV50x40Q8s=.aad4cc23-b422-4c01-a07e-4acca06fc215@github.com>

On Wed, 20 Apr 2022 00:32:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 59:

> 57:      * cleanup, which happens by calling cleanup(), or is done by the Cleaner.
> 58:      */
> 59:     private static class CleaningAction implements Runnable {

This nested class might be more aptly named  `EnumCtx` since it is used during the enumeration process.

The mention of the `cleanup()` method in the nested class javadoc is a bit ambiguous, it seems there should be a cleanup() method in the class, but it is in AbstractLdapNamingEnumeration.

The `state` field might also be renamed `enumCtx`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From rriggs at openjdk.java.net  Wed Apr 20 19:02:25 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 19:02:25 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <ehWialERbBFTAG-_0yG3bXFFPK08e-bEwkslFK2xfZY=.663a14a1-12dc-4876-930a-b1e4b04585f6@github.com>

On Wed, 20 Apr 2022 00:32:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 132:

> 130:             this.state = new CleaningAction(homeCtx, answer, homeCtx.clnt);
> 131:             // Ensures that context won't get closed from underneath us
> 132:             this.state.homeCtx.incEnumCount();

Readability might be improved by using the new `homeCtx()` method instead of `state.homeCtx` in this file.
It would then be consistent with how subclasses access it.
It depends which style you prefer to be more consistent with.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From duke at openjdk.java.net  Wed Apr 20 19:11:23 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 19:11:23 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v6]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <4ZAKiQvQu3hWXEiRIFx-ueVLZ8qu0BN5ygrorjqEefg=.255bc46c-7f8c-4d83-acc0-bfa384bc4992@github.com>

> as title.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - add more replaces
 - add more replaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/26bb5792..53fdb7cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=04-05

  Stats: 28 lines in 16 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Apr 20 19:16:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 19:16:33 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v7]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <K6vFuKKWeeUv7NwV298xZ6l_Uenag9MaXRmDK65_v6M=.734bd1e1-e786-47c6-ba7e-f58c3b9ff436@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add more replaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/53fdb7cd..704e895b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From joehw at openjdk.java.net  Wed Apr 20 19:25:34 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 19:25:34 GMT
Subject: Integrated: 8284920: Incorrect Token type causes XPath expression to
 return incorrect results
In-Reply-To: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
References: <sObXUHSmLSCIciHunFRXfEIH4NfcyjjF0aclTKJZDDc=.e1a3355f-cfd0-445b-aa09-f872fccb9f9a@github.com>
Message-ID: <1UOIZluZZJ5vJCeS_ajla0uiEVFYoavNj2BpKIeNWZQ=.1bd19725-ebd3-4de9-84e0-887fb5de2fa3@github.com>

On Wed, 20 Apr 2022 17:40:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Patch note:
> 
> The previous patch changed all literal tokens to use constants. However, replacing "." with Token.DOT introduced this bug. 
> While tokens with a single char are inherently of type char, due to the different implementation of the overloaded method "tokenIs" that takes String or char, a wrong input type will produce incorrect result. It may be worth it to take a closer look at the overloaded method, but for now, a quick fix is to reverse the input type back to String (DOT_STR).
> 
> Test: the issue affect the processing of the short form of the parent axis "..". The test verifies that all form of the parent axis shall return the same result.
> 
> Test: all XML tests passed.

This pull request has now been integrated.

Changeset: 81a8e2f8
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81a8e2f8b32ad27aed45c4f6966e8d9ecf8b0fc9
Stats:     124 lines in 3 files changed: 122 ins; 0 del; 2 mod

8284920: Incorrect Token type causes XPath expression to return incorrect results

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8321

From duke at openjdk.java.net  Wed Apr 20 19:29:09 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 19:29:09 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v8]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <s2etJdGtI6DEcK_DRhefOW4kO0zBw7Tj6wlh-BKUHGA=.e722cd7e-ce12-4f94-b7a9-e0cf2a7a1658@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add more replaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/704e895b..363fcc50

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From aturbanov at openjdk.java.net  Wed Apr 20 19:38:47 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 20 Apr 2022 19:38:47 GMT
Subject: RFR: 8285285: Avoid redundant allocations in WindowsPreferences
Message-ID: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>

1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better.
2. Unused String array is allocated in `childrenNamesSpi` method

-------------

Commit messages:
 - [PATCH] Avoid redundant allocations in WindowsPreferences
 - [PATCH] Avoid redundant String allocation in WindowsPreferences.toJavaName

Changes: https://git.openjdk.java.net/jdk/pull/8322/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8322&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285285
  Stats: 20 lines in 1 file changed: 0 ins; 2 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8322.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8322/head:pull/8322

PR: https://git.openjdk.java.net/jdk/pull/8322

From hiran.chaudhuri at gmx.net  Wed Apr 20 19:49:03 2022
From: hiran.chaudhuri at gmx.net (Hiran Chaudhuri)
Date: Wed, 20 Apr 2022 21:49:03 +0200
Subject: [External] : Re: jpackage usage problems
In-Reply-To: <9cdecf04-78b2-bb13-6c8a-768b65fc4a35@oracle.com>
References: <862006dcdb62bf94b165823e3ffa685df1948742.camel@gmx.net>
 <a2c07022-4129-2141-dce5-e828f7afa26a@oracle.com>
 <b103e8785d578838e6ce977af4e08c5cd58a615d.camel@gmx.net>
 <4970a2feeaeb459f42d01ee920e7142f220069c6.camel@gmx.net>
 <90c29050-6bf4-762c-3f02-f87c609f0efd@oracle.com>
 <3fad60a277fe04f56528704950ce589812709fdd.camel@gmx.net>
 <1beec523-b449-2675-d4fd-2cca9f21cb31@oracle.com>
 <29113cacd071b528dad4bc28e7b950300c7232a4.camel@gmx.net>
 <3039fd70-e60f-33a7-23c8-29dae8327d1b@oracle.com>
 <e0e83867dd51406d2e70d6a8c62619f6a607edd7.camel@gmx.net>
 <9cdecf04-78b2-bb13-6c8a-768b65fc4a35@oracle.com>
Message-ID: <3acda59cd783020c05d96b28c3315cb7fc84689a.camel@gmx.net>

On Wed, 2022-04-20 at 12:38 -0400, Alexey Semenyuk wrote:
>
> On 4/18/2022 7:06 PM, Hiran Chaudhuri wrote:
> > On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote:
> > > I've filed [1] and [2] CRs to track the issues.
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8284973
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8284974
> > >
> > > - Alexey
> > Sounds great. Thank you.
> >
> > While we are at improving JPackage, there are a few more items I
> > stumbled over:
> >
> > a) When running jpackage on Linux, a freedesktop.org style starter
> > file
> > is created - but one more line in there would make it a lot more
> > usable:
> > https://urldefense.com/v3/__https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzhG0W4A9$
> >
> > b) The solution is to override resource files. Meanwhile I found
> > out
> > the resource files are templates, and jpackage replaces specific
> > strings in these files. This however is nowhere mentioned in the
> > documentation.
> Must the value of "StartupWMClass" property in .desktop file be
> synchronized with the value used in the app or it can be any unique
> value?
> If the latter, jpackage can create unique value for every launcher
> based
> on package and launcher names.
> Otherwise, if the value must be synchronized with the value used in
> the
> app it must be supplied to jpackage. In this case, overriding
> .desktop
> template is the way to go.

The WMClass of a swing application cannot be configured by the
developer. Yet as much as I saw it is related to the fully qualified
class name that resembles the swing window. So if you use something
like

package org.myproject.mypackage;

public class MyWindow extends JFrame {
    ...
}

and display an instance of that, it will carry the WMClass parameter as

org-myproject-mypackage-MyWindow

In many cases this class the is the main class at the same time, which
is either specified on the JPackage command line or via the executable
jar's manifest.

I think a reasonable default could be to derive the name from the main
class, with a way to override allowing coverage of exceptional cases.
Most IDEs generate the JFrame classes with a main method. If not
handled you'd force every developer to override resources. If that
becomes the mainstream use case I guess the documentation should be
improved.

>
> > c) Running jpackage in two phases as I do (1: create app-image, 2:
> > create final package) I learned that --name has to be specified in
> > both
> > runs. When running jpackage on MacOS however the second run needs
> > the
> > application name postfixed with .app otherwise jpackage won't find
> > the
> > directory it created in the first run. See the logs
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzplJmV2G$
> > and
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8Dzmh3le2h$
> --name is optional parameter in both runs. Check out
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java
> testing this feature.
> I guess you mean "--app-image" parameter, not "--name" parameter.
> ".app"
> suffix in app image name on macOS is a legacy jpackage inherited
> from
> JavaFX's javapackager.
>
> I've filed [1] to track this issue. It may be discarded for the sake
> of
> backward compatibility though.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8285265
>

Oh you are right. I am talking about app-image.

Somehow I'd like to have a more homogenous behaviour across the
platforms. It would allow to keep the build files simple.
This may be difficult to achieve as they impose different requirements.
After all I also stumbled across version numbers on MacOS which are
more restrictive than even on Linux.

Breaking backwards compatibility is a huge pain. Someone will have to
take a decision here.

Thank you for considering. :-)

Hiran



From darcy at openjdk.java.net  Wed Apr 20 20:05:25 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 20 Apr 2022 20:05:25 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <JYOF1wrS39ylvPLErV7qw6N4vHkVS8KE9tJgUHDhu3o=.7ff08dbd-8ce1-426d-bf50-751ced96af8a@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
 <JYOF1wrS39ylvPLErV7qw6N4vHkVS8KE9tJgUHDhu3o=.7ff08dbd-8ce1-426d-bf50-751ced96af8a@github.com>
Message-ID: <-9XFVvQotMJOTmJ2oPLuM-VOVP10M9eh94yawyzPdj0=.c436a70a-76dd-40f6-b048-74b9492f8149@github.com>

On Wed, 20 Apr 2022 18:40:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for the update. I can't think how anything could depend on this but unfortunately it's been like that since early JDK releases. We will need a release note, I'm sure Joe will give his opinion on whether a CSR should be created.

Hmm. It is true that the presence or absence of the "synchronized" modifier is not part of a method's contract. However, the multi-thread safety, or not, of a class is part of its behavioral contract.

Without a lot of investigation, my current inclination is to run a CSR for this change for the (small) behavioral compatibility hazard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From duke at openjdk.java.net  Wed Apr 20 20:09:06 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 20:09:06 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v2]
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add jmh test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8308/files
  - new: https://git.openjdk.java.net/jdk/pull/8308/files/9371519f..ac6d75e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8308&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8308&range=00-01

  Stats: 59 lines in 1 file changed: 59 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8308.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8308/head:pull/8308

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Wed Apr 20 20:09:07 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 20:09:07 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <62nN8OAwQTe69C_P0_9pIKNGrGUc5KfJeYfvIIPXSoU=.13d25f71-f80e-4c42-ad83-c1b6ea18f873@github.com>

On Tue, 19 Apr 2022 21:15:29 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

<details>
<summary>Jmh Result(with = check)</summary>
<p>

# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.charAt

# Run progress: 0.00% complete, ETA 00:06:00
# Fork: 1 of 3
# Warmup Iteration   1: 72.769 ns/op
# Warmup Iteration   2: 74.375 ns/op
# Warmup Iteration   3: 72.471 ns/op
# Warmup Iteration   4: 73.477 ns/op
# Warmup Iteration   5: 74.972 ns/op
# Warmup Iteration   6: 73.593 ns/op
# Warmup Iteration   7: 74.270 ns/op
# Warmup Iteration   8: 74.981 ns/op
# Warmup Iteration   9: 74.273 ns/op
# Warmup Iteration  10: 71.556 ns/op
Iteration   1: 73.743 ns/op
Iteration   2: 72.647 ns/op
Iteration   3: 73.701 ns/op
Iteration   4: 74.033 ns/op
Iteration   5: 73.786 ns/op

# Run progress: 4.17% complete, ETA 00:05:52
# Fork: 2 of 3
# Warmup Iteration   1: 75.489 ns/op
# Warmup Iteration   2: 73.533 ns/op
# Warmup Iteration   3: 72.524 ns/op
# Warmup Iteration   4: 73.259 ns/op
# Warmup Iteration   5: 73.346 ns/op
# Warmup Iteration   6: 72.259 ns/op
# Warmup Iteration   7: 73.705 ns/op
# Warmup Iteration   8: 71.332 ns/op
# Warmup Iteration   9: 70.587 ns/op
# Warmup Iteration  10: 69.392 ns/op
Iteration   1: 67.762 ns/op
Iteration   2: 73.029 ns/op
Iteration   3: 69.133 ns/op
Iteration   4: 70.344 ns/op
Iteration   5: 72.041 ns/op

# Run progress: 8.33% complete, ETA 00:05:37
# Fork: 3 of 3
# Warmup Iteration   1: 74.307 ns/op
# Warmup Iteration   2: 74.440 ns/op
# Warmup Iteration   3: 73.053 ns/op
# Warmup Iteration   4: 74.739 ns/op
# Warmup Iteration   5: 75.348 ns/op
# Warmup Iteration   6: 72.801 ns/op
# Warmup Iteration   7: 73.524 ns/op
# Warmup Iteration   8: 73.278 ns/op
# Warmup Iteration   9: 74.633 ns/op
# Warmup Iteration  10: 73.481 ns/op
Iteration   1: 73.787 ns/op
Iteration   2: 73.809 ns/op
Iteration   3: 74.020 ns/op
Iteration   4: 73.751 ns/op
Iteration   5: 73.674 ns/op


Result "org.openjdk.bench.java.lang.StringOther.charAt":
  72.617 ?(99.9%) 2.106 ns/op [Average]
  (min, avg, max) = (67.762, 72.617, 74.033), stdev = 1.970
  CI (99.9%): [70.511, 74.724] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.compareTo

# Run progress: 12.50% complete, ETA 00:05:21
# Fork: 1 of 3
# Warmup Iteration   1: 7.600 ns/op
# Warmup Iteration   2: 7.552 ns/op
# Warmup Iteration   3: 7.001 ns/op
# Warmup Iteration   4: 7.529 ns/op
# Warmup Iteration   5: 7.541 ns/op
# Warmup Iteration   6: 7.531 ns/op
# Warmup Iteration   7: 7.524 ns/op
# Warmup Iteration   8: 7.507 ns/op
# Warmup Iteration   9: 7.506 ns/op
# Warmup Iteration  10: 7.184 ns/op
Iteration   1: 7.119 ns/op
Iteration   2: 7.111 ns/op
Iteration   3: 7.125 ns/op
Iteration   4: 7.113 ns/op
Iteration   5: 7.111 ns/op

# Run progress: 16.67% complete, ETA 00:05:06
# Fork: 2 of 3
# Warmup Iteration   1: 7.616 ns/op
# Warmup Iteration   2: 7.503 ns/op
# Warmup Iteration   3: 7.013 ns/op
# Warmup Iteration   4: 7.543 ns/op
# Warmup Iteration   5: 7.530 ns/op
# Warmup Iteration   6: 7.489 ns/op
# Warmup Iteration   7: 7.513 ns/op
# Warmup Iteration   8: 7.495 ns/op
# Warmup Iteration   9: 7.493 ns/op
# Warmup Iteration  10: 7.124 ns/op
Iteration   1: 7.156 ns/op
Iteration   2: 7.119 ns/op
Iteration   3: 7.111 ns/op
Iteration   4: 7.099 ns/op
Iteration   5: 7.171 ns/op

# Run progress: 20.83% complete, ETA 00:04:50
# Fork: 3 of 3
# Warmup Iteration   1: 7.576 ns/op
# Warmup Iteration   2: 7.575 ns/op
# Warmup Iteration   3: 6.999 ns/op
# Warmup Iteration   4: 7.559 ns/op
# Warmup Iteration   5: 7.551 ns/op
# Warmup Iteration   6: 7.512 ns/op
# Warmup Iteration   7: 7.651 ns/op
# Warmup Iteration   8: 7.608 ns/op
# Warmup Iteration   9: 7.605 ns/op
# Warmup Iteration  10: 7.178 ns/op
Iteration   1: 7.121 ns/op
Iteration   2: 7.110 ns/op
Iteration   3: 7.155 ns/op
Iteration   4: 7.157 ns/op
Iteration   5: 7.176 ns/op


Result "org.openjdk.bench.java.lang.StringOther.compareTo":
  7.130 ?(99.9%) 0.027 ns/op [Average]
  (min, avg, max) = (7.099, 7.130, 7.176), stdev = 0.025
  CI (99.9%): [7.103, 7.157] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.internUnique

# Run progress: 25.00% complete, ETA 00:04:35
# Fork: 1 of 3
# Warmup Iteration   1: 690.789 ns/op
# Warmup Iteration   2: 695.665 ns/op
# Warmup Iteration   3: 684.139 ns/op
# Warmup Iteration   4: 910.126 ns/op
# Warmup Iteration   5: 1192.552 ns/op
# Warmup Iteration   6: 1404.659 ns/op
# Warmup Iteration   7: 1592.178 ns/op
# Warmup Iteration   8: 1757.206 ns/op
# Warmup Iteration   9: 1885.201 ns/op
# Warmup Iteration  10: 2027.096 ns/op
Iteration   1: 2138.939 ns/op
Iteration   2: 2266.500 ns/op
Iteration   3: 2385.430 ns/op
Iteration   4: 2484.336 ns/op
Iteration   5: 2606.155 ns/op

# Run progress: 29.17% complete, ETA 00:04:20
# Fork: 2 of 3
# Warmup Iteration   1: 696.620 ns/op
# Warmup Iteration   2: 698.178 ns/op
# Warmup Iteration   3: 687.792 ns/op
# Warmup Iteration   4: 906.615 ns/op
# Warmup Iteration   5: 1194.699 ns/op
# Warmup Iteration   6: 1420.135 ns/op
# Warmup Iteration   7: 1598.611 ns/op
# Warmup Iteration   8: 1762.909 ns/op
# Warmup Iteration   9: 1911.581 ns/op
# Warmup Iteration  10: 2043.476 ns/op
Iteration   1: 2166.752 ns/op
Iteration   2: 2296.340 ns/op
Iteration   3: 2385.133 ns/op
Iteration   4: 2505.501 ns/op
Iteration   5: 2611.215 ns/op

# Run progress: 33.33% complete, ETA 00:04:05
# Fork: 3 of 3
# Warmup Iteration   1: 703.260 ns/op
# Warmup Iteration   2: 720.669 ns/op
# Warmup Iteration   3: 713.056 ns/op
# Warmup Iteration   4: 886.028 ns/op
# Warmup Iteration   5: 1181.698 ns/op
# Warmup Iteration   6: 1396.434 ns/op
# Warmup Iteration   7: 1585.894 ns/op
# Warmup Iteration   8: 1751.506 ns/op
# Warmup Iteration   9: 1883.964 ns/op
# Warmup Iteration  10: 2021.091 ns/op
Iteration   1: 2141.785 ns/op
Iteration   2: 2260.051 ns/op
Iteration   3: 2359.247 ns/op
Iteration   4: 2479.794 ns/op
Iteration   5: 2590.482 ns/op


Result "org.openjdk.bench.java.lang.StringOther.internUnique":
  2378.511 ?(99.9%) 176.258 ns/op [Average]
  (min, avg, max) = (2138.939, 2378.511, 2611.215), stdev = 164.872
  CI (99.9%): [2202.253, 2554.769] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1

# Run progress: 37.50% complete, ETA 00:03:49
# Fork: 1 of 3
# Warmup Iteration   1: 27.511 ns/op
# Warmup Iteration   2: 27.409 ns/op
# Warmup Iteration   3: 26.737 ns/op
# Warmup Iteration   4: 27.359 ns/op
# Warmup Iteration   5: 27.382 ns/op
# Warmup Iteration   6: 27.300 ns/op
# Warmup Iteration   7: 27.180 ns/op
# Warmup Iteration   8: 27.194 ns/op
# Warmup Iteration   9: 27.276 ns/op
# Warmup Iteration  10: 26.196 ns/op
Iteration   1: 26.219 ns/op
Iteration   2: 26.314 ns/op
Iteration   3: 26.186 ns/op
Iteration   4: 26.504 ns/op
Iteration   5: 26.431 ns/op

# Run progress: 41.67% complete, ETA 00:03:34
# Fork: 2 of 3
# Warmup Iteration   1: 27.082 ns/op
# Warmup Iteration   2: 26.591 ns/op
# Warmup Iteration   3: 26.323 ns/op
# Warmup Iteration   4: 26.773 ns/op
# Warmup Iteration   5: 26.742 ns/op
# Warmup Iteration   6: 26.632 ns/op
# Warmup Iteration   7: 26.820 ns/op
# Warmup Iteration   8: 26.771 ns/op
# Warmup Iteration   9: 26.907 ns/op
# Warmup Iteration  10: 26.011 ns/op
Iteration   1: 25.982 ns/op
Iteration   2: 26.053 ns/op
Iteration   3: 26.188 ns/op
Iteration   4: 25.960 ns/op
Iteration   5: 26.140 ns/op

# Run progress: 45.83% complete, ETA 00:03:19
# Fork: 3 of 3
# Warmup Iteration   1: 27.288 ns/op
# Warmup Iteration   2: 27.050 ns/op
# Warmup Iteration   3: 26.629 ns/op
# Warmup Iteration   4: 26.941 ns/op
# Warmup Iteration   5: 26.953 ns/op
# Warmup Iteration   6: 26.933 ns/op
# Warmup Iteration   7: 26.828 ns/op
# Warmup Iteration   8: 26.963 ns/op
# Warmup Iteration   9: 26.843 ns/op
# Warmup Iteration  10: 26.320 ns/op
Iteration   1: 26.145 ns/op
Iteration   2: 26.107 ns/op
Iteration   3: 26.145 ns/op
Iteration   4: 26.126 ns/op
Iteration   5: 26.218 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1":
  26.181 ?(99.9%) 0.158 ns/op [Average]
  (min, avg, max) = (25.960, 26.181, 26.504), stdev = 0.147
  CI (99.9%): [26.024, 26.339] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL

# Run progress: 50.00% complete, ETA 00:03:03
# Fork: 1 of 3
# Warmup Iteration   1: 383.221 ns/op
# Warmup Iteration   2: 384.145 ns/op
# Warmup Iteration   3: 186.489 ns/op
# Warmup Iteration   4: 385.039 ns/op
# Warmup Iteration   5: 385.782 ns/op
# Warmup Iteration   6: 383.717 ns/op
# Warmup Iteration   7: 386.026 ns/op
# Warmup Iteration   8: 383.559 ns/op
# Warmup Iteration   9: 386.779 ns/op
# Warmup Iteration  10: 186.426 ns/op
Iteration   1: 186.458 ns/op
Iteration   2: 186.303 ns/op
Iteration   3: 187.232 ns/op
Iteration   4: 186.618 ns/op
Iteration   5: 188.988 ns/op

# Run progress: 54.17% complete, ETA 00:02:48
# Fork: 2 of 3
# Warmup Iteration   1: 382.730 ns/op
# Warmup Iteration   2: 383.619 ns/op
# Warmup Iteration   3: 186.757 ns/op
# Warmup Iteration   4: 382.995 ns/op
# Warmup Iteration   5: 386.450 ns/op
# Warmup Iteration   6: 383.026 ns/op
# Warmup Iteration   7: 386.532 ns/op
# Warmup Iteration   8: 388.434 ns/op
# Warmup Iteration   9: 383.317 ns/op
# Warmup Iteration  10: 186.436 ns/op
Iteration   1: 186.552 ns/op
Iteration   2: 187.692 ns/op
Iteration   3: 187.207 ns/op
Iteration   4: 188.653 ns/op
Iteration   5: 188.379 ns/op

# Run progress: 58.33% complete, ETA 00:02:33
# Fork: 3 of 3
# Warmup Iteration   1: 386.772 ns/op
# Warmup Iteration   2: 386.801 ns/op
# Warmup Iteration   3: 190.100 ns/op
# Warmup Iteration   4: 389.759 ns/op
# Warmup Iteration   5: 387.729 ns/op
# Warmup Iteration   6: 383.583 ns/op
# Warmup Iteration   7: 388.694 ns/op
# Warmup Iteration   8: 387.119 ns/op
# Warmup Iteration   9: 383.802 ns/op
# Warmup Iteration  10: 187.168 ns/op
Iteration   1: 186.468 ns/op
Iteration   2: 186.142 ns/op
Iteration   3: 186.300 ns/op
Iteration   4: 187.378 ns/op
Iteration   5: 188.505 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL":
  187.258 ?(99.9%) 1.038 ns/op [Average]
  (min, avg, max) = (186.142, 187.258, 188.988), stdev = 0.971
  CI (99.9%): [186.220, 188.297] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU

# Run progress: 62.50% complete, ETA 00:02:17
# Fork: 1 of 3
# Warmup Iteration   1: 1808.439 ns/op
# Warmup Iteration   2: 1767.006 ns/op
# Warmup Iteration   3: 2598.387 ns/op
# Warmup Iteration   4: 1766.816 ns/op
# Warmup Iteration   5: 1743.078 ns/op
# Warmup Iteration   6: 1756.696 ns/op
# Warmup Iteration   7: 1756.846 ns/op
# Warmup Iteration   8: 1743.495 ns/op
# Warmup Iteration   9: 1759.004 ns/op
# Warmup Iteration  10: 2583.316 ns/op
Iteration   1: 2578.140 ns/op
Iteration   2: 2586.399 ns/op
Iteration   3: 2595.297 ns/op
Iteration   4: 2577.773 ns/op
Iteration   5: 2590.910 ns/op

# Run progress: 66.67% complete, ETA 00:02:02
# Fork: 2 of 3
# Warmup Iteration   1: 1820.105 ns/op
# Warmup Iteration   2: 1761.995 ns/op
# Warmup Iteration   3: 2592.068 ns/op
# Warmup Iteration   4: 1750.519 ns/op
# Warmup Iteration   5: 1759.997 ns/op
# Warmup Iteration   6: 1766.899 ns/op
# Warmup Iteration   7: 1763.529 ns/op
# Warmup Iteration   8: 1766.331 ns/op
# Warmup Iteration   9: 1752.448 ns/op
# Warmup Iteration  10: 2579.290 ns/op
Iteration   1: 2583.389 ns/op
Iteration   2: 2595.761 ns/op
Iteration   3: 2580.752 ns/op
Iteration   4: 2591.410 ns/op
Iteration   5: 2605.863 ns/op

# Run progress: 70.83% complete, ETA 00:01:47
# Fork: 3 of 3
# Warmup Iteration   1: 1793.036 ns/op
# Warmup Iteration   2: 1758.022 ns/op
# Warmup Iteration   3: 2592.707 ns/op
# Warmup Iteration   4: 1749.634 ns/op
# Warmup Iteration   5: 1758.032 ns/op
# Warmup Iteration   6: 1748.079 ns/op
# Warmup Iteration   7: 1760.812 ns/op
# Warmup Iteration   8: 1755.140 ns/op
# Warmup Iteration   9: 1748.580 ns/op
# Warmup Iteration  10: 2586.600 ns/op
Iteration   1: 2583.574 ns/op
Iteration   2: 2593.630 ns/op
Iteration   3: 2587.690 ns/op
Iteration   4: 2599.723 ns/op
Iteration   5: 2597.187 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU":
  2589.833 ?(99.9%) 8.823 ns/op [Average]
  (min, avg, max) = (2577.773, 2589.833, 2605.863), stdev = 8.253
  CI (99.9%): [2581.010, 2598.657] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL

# Run progress: 75.00% complete, ETA 00:01:31
# Fork: 1 of 3
# Warmup Iteration   1: 1782.462 ns/op
# Warmup Iteration   2: 1752.012 ns/op
# Warmup Iteration   3: 2380.621 ns/op
# Warmup Iteration   4: 1743.210 ns/op
# Warmup Iteration   5: 1744.448 ns/op
# Warmup Iteration   6: 1755.656 ns/op
# Warmup Iteration   7: 1744.958 ns/op
# Warmup Iteration   8: 1747.890 ns/op
# Warmup Iteration   9: 1756.824 ns/op
# Warmup Iteration  10: 2386.359 ns/op
Iteration   1: 2375.206 ns/op
Iteration   2: 2381.558 ns/op
Iteration   3: 2378.714 ns/op
Iteration   4: 2375.443 ns/op
Iteration   5: 2384.942 ns/op

# Run progress: 79.17% complete, ETA 00:01:16
# Fork: 2 of 3
# Warmup Iteration   1: 1790.976 ns/op
# Warmup Iteration   2: 1749.313 ns/op
# Warmup Iteration   3: 2373.999 ns/op
# Warmup Iteration   4: 1727.657 ns/op
# Warmup Iteration   5: 1733.681 ns/op
# Warmup Iteration   6: 1745.252 ns/op
# Warmup Iteration   7: 1742.418 ns/op
# Warmup Iteration   8: 1736.290 ns/op
# Warmup Iteration   9: 1743.422 ns/op
# Warmup Iteration  10: 2379.393 ns/op
Iteration   1: 2375.139 ns/op
Iteration   2: 2374.890 ns/op
Iteration   3: 2375.229 ns/op
Iteration   4: 2378.850 ns/op
Iteration   5: 2396.568 ns/op

# Run progress: 83.33% complete, ETA 00:01:01
# Fork: 3 of 3
# Warmup Iteration   1: 1790.161 ns/op
# Warmup Iteration   2: 1755.700 ns/op
# Warmup Iteration   3: 2389.256 ns/op
# Warmup Iteration   4: 1734.317 ns/op
# Warmup Iteration   5: 1754.969 ns/op
# Warmup Iteration   6: 1752.956 ns/op
# Warmup Iteration   7: 1743.547 ns/op
# Warmup Iteration   8: 1742.636 ns/op
# Warmup Iteration   9: 1752.264 ns/op
# Warmup Iteration  10: 2371.152 ns/op
Iteration   1: 2382.148 ns/op
Iteration   2: 2378.250 ns/op
Iteration   3: 2372.130 ns/op
Iteration   4: 2380.523 ns/op
Iteration   5: 2385.087 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL":
  2379.645 ?(99.9%) 6.481 ns/op [Average]
  (min, avg, max) = (2372.130, 2379.645, 2396.568), stdev = 6.062
  CI (99.9%): [2373.164, 2386.126] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU

# Run progress: 87.50% complete, ETA 00:00:45
# Fork: 1 of 3
# Warmup Iteration   1: 385.542 ns/op
# Warmup Iteration   2: 402.016 ns/op
# Warmup Iteration   3: 188.558 ns/op
# Warmup Iteration   4: 391.182 ns/op
# Warmup Iteration   5: 404.047 ns/op
# Warmup Iteration   6: 391.660 ns/op
# Warmup Iteration   7: 387.864 ns/op
# Warmup Iteration   8: 401.734 ns/op
# Warmup Iteration   9: 390.811 ns/op
# Warmup Iteration  10: 193.879 ns/op
Iteration   1: 191.808 ns/op
Iteration   2: 190.770 ns/op
Iteration   3: 187.111 ns/op
Iteration   4: 190.040 ns/op
Iteration   5: 187.351 ns/op

# Run progress: 91.67% complete, ETA 00:00:30
# Fork: 2 of 3
# Warmup Iteration   1: 389.080 ns/op
# Warmup Iteration   2: 386.598 ns/op
# Warmup Iteration   3: 188.687 ns/op
# Warmup Iteration   4: 388.477 ns/op
# Warmup Iteration   5: 388.952 ns/op
# Warmup Iteration   6: 387.221 ns/op
# Warmup Iteration   7: 389.056 ns/op
# Warmup Iteration   8: 387.642 ns/op
# Warmup Iteration   9: 390.166 ns/op
# Warmup Iteration  10: 188.666 ns/op
Iteration   1: 187.776 ns/op
Iteration   2: 213.099 ns/op
Iteration   3: 198.493 ns/op
Iteration   4: 193.155 ns/op
Iteration   5: 190.390 ns/op

# Run progress: 95.83% complete, ETA 00:00:15
# Fork: 3 of 3
# Warmup Iteration   1: 390.556 ns/op
# Warmup Iteration   2: 388.024 ns/op
# Warmup Iteration   3: 188.315 ns/op
# Warmup Iteration   4: 388.357 ns/op
# Warmup Iteration   5: 385.902 ns/op
# Warmup Iteration   6: 385.977 ns/op
# Warmup Iteration   7: 385.849 ns/op
# Warmup Iteration   8: 386.678 ns/op
# Warmup Iteration   9: 386.514 ns/op
# Warmup Iteration  10: 187.926 ns/op
Iteration   1: 189.464 ns/op
Iteration   2: 188.584 ns/op
Iteration   3: 187.770 ns/op
Iteration   4: 188.467 ns/op
Iteration   5: 189.521 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU":
  191.587 ?(99.9%) 7.069 ns/op [Average]
  (min, avg, max) = (187.111, 191.587, 213.099), stdev = 6.612
  CI (99.9%): [184.518, 198.655] (assumes normal distribution)


# Run complete. Total time: 00:06:07

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.

Benchmark                         Mode  Cnt     Score     Error  Units
StringOther.charAt                avgt   15    72.617 ?   2.106  ns/op
StringOther.compareTo             avgt   15     7.130 ?   0.027  ns/op
StringOther.internUnique          avgt   15  2378.511 ? 176.258  ns/op
StringOther.regionMatchesLatin1   avgt   15    26.181 ?   0.158  ns/op
StringOther.regionMatchesU1024LL  avgt   15   187.258 ?   1.038  ns/op
StringOther.regionMatchesU1024LU  avgt   15  2589.833 ?   8.823  ns/op
StringOther.regionMatchesU1024UL  avgt   15  2379.645 ?   6.481  ns/op
StringOther.regionMatchesU1024UU  avgt   15   191.587 ?   7.069  ns/op


</p>
</details>

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From joehw at openjdk.java.net  Wed Apr 20 20:14:59 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 20:14:59 GMT
Subject: RFR: 8284548: Invalid XPath expression causes
 StringIndexOutOfBoundsException
Message-ID: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>

Patch note:

    A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected.
    
Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant.

-------------

Commit messages:
 - 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException

Changes: https://git.openjdk.java.net/jdk/pull/8323/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8323&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284548
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8323.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8323/head:pull/8323

PR: https://git.openjdk.java.net/jdk/pull/8323

From duke at openjdk.java.net  Wed Apr 20 20:17:26 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 20:17:26 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v2]
In-Reply-To: <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>
Message-ID: <s-aL_l5VRKx0FoUBWaTh1XfcQpxD5mh5B9LPS7oQJlI=.a53d2ac5-5804-419b-bdc6-d81f4b36c6e6@github.com>

On Wed, 20 Apr 2022 20:09:06 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
>> 
>>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> should be changed to 
>> 
>>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> as:
>> 
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jmh test

<details>
<summary>Jmh Result(without = check)</summary>
<p>

# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.charAt

# Run progress: 0.00% complete, ETA 00:06:00
# Fork: 1 of 3
# Warmup Iteration   1: 74.478 ns/op
# Warmup Iteration   2: 72.357 ns/op
# Warmup Iteration   3: 72.555 ns/op
# Warmup Iteration   4: 73.901 ns/op
# Warmup Iteration   5: 73.573 ns/op
# Warmup Iteration   6: 73.771 ns/op
# Warmup Iteration   7: 70.427 ns/op
# Warmup Iteration   8: 75.018 ns/op
# Warmup Iteration   9: 74.755 ns/op
# Warmup Iteration  10: 69.792 ns/op
Iteration   1: 72.330 ns/op
Iteration   2: 73.277 ns/op
Iteration   3: 73.678 ns/op
Iteration   4: 68.865 ns/op
Iteration   5: 74.953 ns/op

# Run progress: 4.17% complete, ETA 00:05:52
# Fork: 2 of 3
# Warmup Iteration   1: 74.439 ns/op
# Warmup Iteration   2: 73.358 ns/op
# Warmup Iteration   3: 71.799 ns/op
# Warmup Iteration   4: 70.913 ns/op
# Warmup Iteration   5: 71.575 ns/op
# Warmup Iteration   6: 69.340 ns/op
# Warmup Iteration   7: 69.536 ns/op
# Warmup Iteration   8: 69.717 ns/op
# Warmup Iteration   9: 70.526 ns/op
# Warmup Iteration  10: 74.645 ns/op
Iteration   1: 73.770 ns/op
Iteration   2: 74.756 ns/op
Iteration   3: 73.574 ns/op
Iteration   4: 72.319 ns/op
Iteration   5: 72.092 ns/op

# Run progress: 8.33% complete, ETA 00:05:36
# Fork: 3 of 3
# Warmup Iteration   1: 73.593 ns/op
# Warmup Iteration   2: 69.462 ns/op
# Warmup Iteration   3: 72.013 ns/op
# Warmup Iteration   4: 68.641 ns/op
# Warmup Iteration   5: 73.384 ns/op
# Warmup Iteration   6: 69.624 ns/op
# Warmup Iteration   7: 73.325 ns/op
# Warmup Iteration   8: 72.080 ns/op
# Warmup Iteration   9: 73.454 ns/op
# Warmup Iteration  10: 73.144 ns/op
Iteration   1: 66.782 ns/op
Iteration   2: 73.245 ns/op
Iteration   3: 73.835 ns/op
Iteration   4: 67.903 ns/op
Iteration   5: 72.810 ns/op


Result "org.openjdk.bench.java.lang.StringOther.charAt":
  72.279 ?(99.9%) 2.632 ns/op [Average]
  (min, avg, max) = (66.782, 72.279, 74.953), stdev = 2.462
  CI (99.9%): [69.648, 74.911] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.compareTo

# Run progress: 12.50% complete, ETA 00:05:21
# Fork: 1 of 3
# Warmup Iteration   1: 7.684 ns/op
# Warmup Iteration   2: 7.539 ns/op
# Warmup Iteration   3: 7.072 ns/op
# Warmup Iteration   4: 7.529 ns/op
# Warmup Iteration   5: 7.712 ns/op
# Warmup Iteration   6: 7.514 ns/op
# Warmup Iteration   7: 7.935 ns/op
# Warmup Iteration   8: 7.585 ns/op
# Warmup Iteration   9: 7.511 ns/op
# Warmup Iteration  10: 7.243 ns/op
Iteration   1: 7.202 ns/op
Iteration   2: 7.207 ns/op
Iteration   3: 7.122 ns/op
Iteration   4: 7.140 ns/op
Iteration   5: 7.291 ns/op

# Run progress: 16.67% complete, ETA 00:05:06
# Fork: 2 of 3
# Warmup Iteration   1: 7.665 ns/op
# Warmup Iteration   2: 7.611 ns/op
# Warmup Iteration   3: 6.974 ns/op
# Warmup Iteration   4: 7.627 ns/op
# Warmup Iteration   5: 7.605 ns/op
# Warmup Iteration   6: 7.526 ns/op
# Warmup Iteration   7: 7.535 ns/op
# Warmup Iteration   8: 7.581 ns/op
# Warmup Iteration   9: 7.624 ns/op
# Warmup Iteration  10: 7.116 ns/op
Iteration   1: 7.104 ns/op
Iteration   2: 7.112 ns/op
Iteration   3: 7.163 ns/op
Iteration   4: 7.113 ns/op
Iteration   5: 7.182 ns/op

# Run progress: 20.83% complete, ETA 00:04:50
# Fork: 3 of 3
# Warmup Iteration   1: 7.590 ns/op
# Warmup Iteration   2: 7.580 ns/op
# Warmup Iteration   3: 7.038 ns/op
# Warmup Iteration   4: 7.576 ns/op
# Warmup Iteration   5: 7.560 ns/op
# Warmup Iteration   6: 7.579 ns/op
# Warmup Iteration   7: 7.538 ns/op
# Warmup Iteration   8: 7.521 ns/op
# Warmup Iteration   9: 7.568 ns/op
# Warmup Iteration  10: 7.304 ns/op
Iteration   1: 7.272 ns/op
Iteration   2: 7.244 ns/op
Iteration   3: 7.247 ns/op
Iteration   4: 7.270 ns/op
Iteration   5: 7.335 ns/op


Result "org.openjdk.bench.java.lang.StringOther.compareTo":
  7.200 ?(99.9%) 0.079 ns/op [Average]
  (min, avg, max) = (7.104, 7.200, 7.335), stdev = 0.074
  CI (99.9%): [7.121, 7.279] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.internUnique

# Run progress: 25.00% complete, ETA 00:04:35
# Fork: 1 of 3
# Warmup Iteration   1: 711.210 ns/op
# Warmup Iteration   2: 715.546 ns/op
# Warmup Iteration   3: 719.641 ns/op
# Warmup Iteration   4: 880.842 ns/op
# Warmup Iteration   5: 1208.438 ns/op
# Warmup Iteration   6: 1412.411 ns/op
# Warmup Iteration   7: 1556.071 ns/op
# Warmup Iteration   8: 1757.619 ns/op
# Warmup Iteration   9: 1870.034 ns/op
# Warmup Iteration  10: 2005.351 ns/op
Iteration   1: 2145.538 ns/op
Iteration   2: 2269.473 ns/op
Iteration   3: 2378.031 ns/op
Iteration   4: 2471.040 ns/op
Iteration   5: 2619.508 ns/op

# Run progress: 29.17% complete, ETA 00:04:20
# Fork: 2 of 3
# Warmup Iteration   1: 720.517 ns/op
# Warmup Iteration   2: 729.418 ns/op
# Warmup Iteration   3: 764.210 ns/op
# Warmup Iteration   4: 873.379 ns/op
# Warmup Iteration   5: 1168.143 ns/op
# Warmup Iteration   6: 1380.917 ns/op
# Warmup Iteration   7: 1593.366 ns/op
# Warmup Iteration   8: 1736.498 ns/op
# Warmup Iteration   9: 1850.467 ns/op
# Warmup Iteration  10: 2017.632 ns/op
Iteration   1: 2147.386 ns/op
Iteration   2: 2264.158 ns/op
Iteration   3: 2398.126 ns/op
Iteration   4: 2449.589 ns/op
Iteration   5: 2595.557 ns/op

# Run progress: 33.33% complete, ETA 00:04:05
# Fork: 3 of 3
# Warmup Iteration   1: 704.568 ns/op
# Warmup Iteration   2: 719.501 ns/op
# Warmup Iteration   3: 727.100 ns/op
# Warmup Iteration   4: 890.044 ns/op
# Warmup Iteration   5: 1187.037 ns/op
# Warmup Iteration   6: 1411.096 ns/op
# Warmup Iteration   7: 1581.086 ns/op
# Warmup Iteration   8: 1760.902 ns/op
# Warmup Iteration   9: 1920.568 ns/op
# Warmup Iteration  10: 2043.275 ns/op
Iteration   1: 2154.441 ns/op
Iteration   2: 2269.279 ns/op
Iteration   3: 2388.032 ns/op
Iteration   4: 2499.567 ns/op
Iteration   5: 2616.938 ns/op


Result "org.openjdk.bench.java.lang.StringOther.internUnique":
  2377.777 ?(99.9%) 177.415 ns/op [Average]
  (min, avg, max) = (2145.538, 2377.777, 2619.508), stdev = 165.954
  CI (99.9%): [2200.362, 2555.193] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1

# Run progress: 37.50% complete, ETA 00:03:49
# Fork: 1 of 3
# Warmup Iteration   1: 27.488 ns/op
# Warmup Iteration   2: 26.757 ns/op
# Warmup Iteration   3: 26.459 ns/op
# Warmup Iteration   4: 27.101 ns/op
# Warmup Iteration   5: 26.924 ns/op
# Warmup Iteration   6: 27.383 ns/op
# Warmup Iteration   7: 27.290 ns/op
# Warmup Iteration   8: 26.916 ns/op
# Warmup Iteration   9: 26.846 ns/op
# Warmup Iteration  10: 26.165 ns/op
Iteration   1: 26.528 ns/op
Iteration   2: 26.675 ns/op
Iteration   3: 26.470 ns/op
Iteration   4: 26.133 ns/op
Iteration   5: 27.045 ns/op

# Run progress: 41.67% complete, ETA 00:03:34
# Fork: 2 of 3
# Warmup Iteration   1: 27.435 ns/op
# Warmup Iteration   2: 27.139 ns/op
# Warmup Iteration   3: 26.260 ns/op
# Warmup Iteration   4: 27.203 ns/op
# Warmup Iteration   5: 27.275 ns/op
# Warmup Iteration   6: 26.786 ns/op
# Warmup Iteration   7: 26.793 ns/op
# Warmup Iteration   8: 26.812 ns/op
# Warmup Iteration   9: 26.998 ns/op
# Warmup Iteration  10: 26.521 ns/op
Iteration   1: 26.258 ns/op
Iteration   2: 26.302 ns/op
Iteration   3: 26.298 ns/op
Iteration   4: 26.283 ns/op
Iteration   5: 26.819 ns/op

# Run progress: 45.83% complete, ETA 00:03:19
# Fork: 3 of 3
# Warmup Iteration   1: 27.275 ns/op
# Warmup Iteration   2: 27.129 ns/op
# Warmup Iteration   3: 26.404 ns/op
# Warmup Iteration   4: 26.708 ns/op
# Warmup Iteration   5: 26.969 ns/op
# Warmup Iteration   6: 27.077 ns/op
# Warmup Iteration   7: 26.732 ns/op
# Warmup Iteration   8: 27.090 ns/op
# Warmup Iteration   9: 26.974 ns/op
# Warmup Iteration  10: 26.679 ns/op
Iteration   1: 26.379 ns/op
Iteration   2: 26.171 ns/op
Iteration   3: 26.151 ns/op
Iteration   4: 26.234 ns/op
Iteration   5: 26.382 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1":
  26.409 ?(99.9%) 0.279 ns/op [Average]
  (min, avg, max) = (26.133, 26.409, 27.045), stdev = 0.261
  CI (99.9%): [26.129, 26.688] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL

# Run progress: 50.00% complete, ETA 00:03:03
# Fork: 1 of 3
# Warmup Iteration   1: 303.144 ns/op
# Warmup Iteration   2: 296.744 ns/op
# Warmup Iteration   3: 186.968 ns/op
# Warmup Iteration   4: 300.451 ns/op
# Warmup Iteration   5: 297.590 ns/op
# Warmup Iteration   6: 296.346 ns/op
# Warmup Iteration   7: 300.523 ns/op
# Warmup Iteration   8: 295.685 ns/op
# Warmup Iteration   9: 303.034 ns/op
# Warmup Iteration  10: 185.710 ns/op
Iteration   1: 185.747 ns/op
Iteration   2: 185.476 ns/op
Iteration   3: 185.970 ns/op
Iteration   4: 186.685 ns/op
Iteration   5: 190.241 ns/op

# Run progress: 54.17% complete, ETA 00:02:48
# Fork: 2 of 3
# Warmup Iteration   1: 306.968 ns/op
# Warmup Iteration   2: 300.146 ns/op
# Warmup Iteration   3: 189.228 ns/op
# Warmup Iteration   4: 297.168 ns/op
# Warmup Iteration   5: 296.126 ns/op
# Warmup Iteration   6: 295.891 ns/op
# Warmup Iteration   7: 295.972 ns/op
# Warmup Iteration   8: 295.817 ns/op
# Warmup Iteration   9: 300.546 ns/op
# Warmup Iteration  10: 186.313 ns/op
Iteration   1: 187.967 ns/op
Iteration   2: 186.222 ns/op
Iteration   3: 185.710 ns/op
Iteration   4: 187.249 ns/op
Iteration   5: 188.887 ns/op

# Run progress: 58.33% complete, ETA 00:02:33
# Fork: 3 of 3
# Warmup Iteration   1: 303.105 ns/op
# Warmup Iteration   2: 299.711 ns/op
# Warmup Iteration   3: 187.263 ns/op
# Warmup Iteration   4: 298.838 ns/op
# Warmup Iteration   5: 298.997 ns/op
# Warmup Iteration   6: 296.007 ns/op
# Warmup Iteration   7: 296.305 ns/op
# Warmup Iteration   8: 296.056 ns/op
# Warmup Iteration   9: 299.125 ns/op
# Warmup Iteration  10: 187.975 ns/op
Iteration   1: 187.091 ns/op
Iteration   2: 189.476 ns/op
Iteration   3: 188.990 ns/op
Iteration   4: 189.501 ns/op
Iteration   5: 190.764 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL":
  187.732 ?(99.9%) 1.914 ns/op [Average]
  (min, avg, max) = (185.476, 187.732, 190.764), stdev = 1.790
  CI (99.9%): [185.818, 189.646] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU

# Run progress: 62.50% complete, ETA 00:02:17
# Fork: 1 of 3
# Warmup Iteration   1: 1792.067 ns/op
# Warmup Iteration   2: 1840.234 ns/op
# Warmup Iteration   3: 1536.619 ns/op
# Warmup Iteration   4: 1867.624 ns/op
# Warmup Iteration   5: 1878.742 ns/op
# Warmup Iteration   6: 1835.980 ns/op
# Warmup Iteration   7: 1837.200 ns/op
# Warmup Iteration   8: 1836.986 ns/op
# Warmup Iteration   9: 1838.710 ns/op
# Warmup Iteration  10: 1305.558 ns/op
Iteration   1: 1324.687 ns/op
Iteration   2: 1317.813 ns/op
Iteration   3: 1331.293 ns/op
Iteration   4: 1331.446 ns/op
Iteration   5: 1336.226 ns/op

# Run progress: 66.67% complete, ETA 00:02:02
# Fork: 2 of 3
# Warmup Iteration   1: 1792.898 ns/op
# Warmup Iteration   2: 1871.357 ns/op
# Warmup Iteration   3: 1527.959 ns/op
# Warmup Iteration   4: 1859.196 ns/op
# Warmup Iteration   5: 1837.751 ns/op
# Warmup Iteration   6: 1868.952 ns/op
# Warmup Iteration   7: 1838.721 ns/op
# Warmup Iteration   8: 1838.604 ns/op
# Warmup Iteration   9: 1864.258 ns/op
# Warmup Iteration  10: 1322.919 ns/op
Iteration   1: 1325.401 ns/op
Iteration   2: 1316.595 ns/op
Iteration   3: 1316.863 ns/op
Iteration   4: 1314.357 ns/op
Iteration   5: 1332.473 ns/op

# Run progress: 70.83% complete, ETA 00:01:47
# Fork: 3 of 3
# Warmup Iteration   1: 1802.783 ns/op
# Warmup Iteration   2: 1864.955 ns/op
# Warmup Iteration   3: 1525.647 ns/op
# Warmup Iteration   4: 1865.719 ns/op
# Warmup Iteration   5: 1855.859 ns/op
# Warmup Iteration   6: 1840.375 ns/op
# Warmup Iteration   7: 1836.324 ns/op
# Warmup Iteration   8: 1840.356 ns/op
# Warmup Iteration   9: 1837.068 ns/op
# Warmup Iteration  10: 1316.856 ns/op
Iteration   1: 1308.652 ns/op
Iteration   2: 1312.048 ns/op
Iteration   3: 1327.190 ns/op
Iteration   4: 1317.060 ns/op
Iteration   5: 1350.241 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU":
  1324.156 ?(99.9%) 11.761 ns/op [Average]
  (min, avg, max) = (1308.652, 1324.156, 1350.241), stdev = 11.001
  CI (99.9%): [1312.396, 1335.917] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL

# Run progress: 75.00% complete, ETA 00:01:31
# Fork: 1 of 3
# Warmup Iteration   1: 1876.966 ns/op
# Warmup Iteration   2: 1956.101 ns/op
# Warmup Iteration   3: 1329.634 ns/op
# Warmup Iteration   4: 1960.647 ns/op
# Warmup Iteration   5: 1945.769 ns/op
# Warmup Iteration   6: 1939.349 ns/op
# Warmup Iteration   7: 1962.894 ns/op
# Warmup Iteration   8: 1965.710 ns/op
# Warmup Iteration   9: 1962.636 ns/op
# Warmup Iteration  10: 1303.857 ns/op
Iteration   1: 1325.286 ns/op
Iteration   2: 1315.074 ns/op
Iteration   3: 1311.516 ns/op
Iteration   4: 1380.285 ns/op
Iteration   5: 1374.154 ns/op

# Run progress: 79.17% complete, ETA 00:01:16
# Fork: 2 of 3
# Warmup Iteration   1: 1949.514 ns/op
# Warmup Iteration   2: 2007.440 ns/op
# Warmup Iteration   3: 1367.116 ns/op
# Warmup Iteration   4: 1990.732 ns/op
# Warmup Iteration   5: 1958.976 ns/op
# Warmup Iteration   6: 1965.754 ns/op
# Warmup Iteration   7: 1971.913 ns/op
# Warmup Iteration   8: 1974.948 ns/op
# Warmup Iteration   9: 1963.292 ns/op
# Warmup Iteration  10: 1345.950 ns/op
Iteration   1: 1323.690 ns/op
Iteration   2: 1340.325 ns/op
Iteration   3: 1340.706 ns/op
Iteration   4: 1324.195 ns/op
Iteration   5: 1339.104 ns/op

# Run progress: 83.33% complete, ETA 00:01:01
# Fork: 3 of 3
# Warmup Iteration   1: 1893.688 ns/op
# Warmup Iteration   2: 1963.501 ns/op
# Warmup Iteration   3: 1332.057 ns/op
# Warmup Iteration   4: 1994.072 ns/op
# Warmup Iteration   5: 1981.262 ns/op
# Warmup Iteration   6: 1978.875 ns/op
# Warmup Iteration   7: 1975.539 ns/op
# Warmup Iteration   8: 1976.051 ns/op
# Warmup Iteration   9: 1965.054 ns/op
# Warmup Iteration  10: 1309.543 ns/op
Iteration   1: 1321.755 ns/op
Iteration   2: 1318.766 ns/op
Iteration   3: 1311.904 ns/op
Iteration   4: 1314.272 ns/op
Iteration   5: 1336.825 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL":
  1331.857 ?(99.9%) 22.509 ns/op [Average]
  (min, avg, max) = (1311.516, 1331.857, 1380.285), stdev = 21.055
  CI (99.9%): [1309.348, 1354.366] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU

# Run progress: 87.50% complete, ETA 00:00:45
# Fork: 1 of 3
# Warmup Iteration   1: 301.524 ns/op
# Warmup Iteration   2: 298.614 ns/op
# Warmup Iteration   3: 188.084 ns/op
# Warmup Iteration   4: 297.548 ns/op
# Warmup Iteration   5: 297.762 ns/op
# Warmup Iteration   6: 298.255 ns/op
# Warmup Iteration   7: 298.128 ns/op
# Warmup Iteration   8: 297.294 ns/op
# Warmup Iteration   9: 301.427 ns/op
# Warmup Iteration  10: 188.916 ns/op
Iteration   1: 187.242 ns/op
Iteration   2: 187.279 ns/op
Iteration   3: 186.889 ns/op
Iteration   4: 187.419 ns/op
Iteration   5: 186.700 ns/op

# Run progress: 91.67% complete, ETA 00:00:30
# Fork: 2 of 3
# Warmup Iteration   1: 309.555 ns/op
# Warmup Iteration   2: 299.977 ns/op
# Warmup Iteration   3: 190.319 ns/op
# Warmup Iteration   4: 300.650 ns/op
# Warmup Iteration   5: 300.809 ns/op
# Warmup Iteration   6: 304.232 ns/op
# Warmup Iteration   7: 303.104 ns/op
# Warmup Iteration   8: 298.601 ns/op
# Warmup Iteration   9: 304.347 ns/op
# Warmup Iteration  10: 190.332 ns/op
Iteration   1: 190.087 ns/op
Iteration   2: 189.434 ns/op
Iteration   3: 187.803 ns/op
Iteration   4: 186.678 ns/op
Iteration   5: 188.202 ns/op

# Run progress: 95.83% complete, ETA 00:00:15
# Fork: 3 of 3
# Warmup Iteration   1: 306.889 ns/op
# Warmup Iteration   2: 306.172 ns/op
# Warmup Iteration   3: 190.313 ns/op
# Warmup Iteration   4: 300.543 ns/op
# Warmup Iteration   5: 304.967 ns/op
# Warmup Iteration   6: 302.572 ns/op
# Warmup Iteration   7: 297.677 ns/op
# Warmup Iteration   8: 303.316 ns/op
# Warmup Iteration   9: 304.080 ns/op
# Warmup Iteration  10: 190.553 ns/op
Iteration   1: 191.023 ns/op
Iteration   2: 192.502 ns/op
Iteration   3: 187.058 ns/op
Iteration   4: 192.817 ns/op
Iteration   5: 191.955 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU":
  188.872 ?(99.9%) 2.396 ns/op [Average]
  (min, avg, max) = (186.678, 188.872, 192.817), stdev = 2.241
  CI (99.9%): [186.477, 191.268] (assumes normal distribution)


# Run complete. Total time: 00:06:07

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.

Benchmark                         Mode  Cnt     Score     Error  Units
StringOther.charAt                avgt   15    72.279 ?   2.632  ns/op
StringOther.compareTo             avgt   15     7.200 ?   0.079  ns/op
StringOther.internUnique          avgt   15  2377.777 ? 177.415  ns/op
StringOther.regionMatchesLatin1   avgt   15    26.409 ?   0.279  ns/op
StringOther.regionMatchesU1024LL  avgt   15   187.732 ?   1.914  ns/op
StringOther.regionMatchesU1024LU  avgt   15  1324.156 ?  11.761  ns/op
StringOther.regionMatchesU1024UL  avgt   15  1331.857 ?  22.509  ns/op
StringOther.regionMatchesU1024UU  avgt   15   188.872 ?   2.396  ns/op


</p>
</details>

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From naoto at openjdk.java.net  Wed Apr 20 20:22:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 20 Apr 2022 20:22:35 GMT
Subject: RFR: 8284548: Invalid XPath expression causes
 StringIndexOutOfBoundsException
In-Reply-To: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
References: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
Message-ID: <qoAqIQnpd7S5LojTlBpbizUvuLLW2FoxX5-2C4XfftY=.8c0e1873-1690-4ffb-817d-0581ec77b763@github.com>

On Wed, 20 Apr 2022 20:08:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Patch note:
> 
>     A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected.
>     
> Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8323

From jlahoda at openjdk.java.net  Wed Apr 20 20:40:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 20 Apr 2022 20:40:29 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v5]
In-Reply-To: <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <1hsu9DxEMSminkhNmYR6nnCuaQixxDxb19VUa2tnSVw=.2421b142-4ec1-4aab-beaf-cd2aa0b11b5a@github.com>
 <bbg-44aXfR92Yb5TiPjNVX8of7_ojMRWFhFGMRpTt2U=.6157ad9c-5370-4f07-9eae-8c3439460490@github.com>
Message-ID: <TNWbdN07GHTzgZlV0DbxNY5fLSSMQrxzqaqEEVn1EqM=.b98007e6-b6e8-4e9a-860d-91ffb8eab7f4@github.com>

On Wed, 20 Apr 2022 14:50:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> nit: just ran langtools tests as part of my routine and these seem to be failing, `CheckExamples.java` due to:
> 
> ```
> test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java and
> test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java
> ```
> 
> and this one too:
> 
> ```
> test/langtools/tools/javac/patterns/InstanceofTotalPattern.java (seems to be a golden file issue)
> ```

Thanks for checking and sorry for that. Will fix in next update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From rriggs at openjdk.java.net  Wed Apr 20 21:00:25 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 21:00:25 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v2]
In-Reply-To: <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>
Message-ID: <M4qwoJ9XCVsCGDcavBvHk470DR4N881jFrrZsX2p9Ck=.0e52a2a3-1ce7-4dcb-b4e5-9f8ca41187ee@github.com>

On Wed, 20 Apr 2022 20:09:06 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
>> 
>>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> should be changed to 
>> 
>>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> as:
>> 
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jmh test

Thanks for the JMH tests and data.

The only part needed from the JMH run is the last 9 lines.  The rest is noise.
If it was formatted as a literal it would be easier to read.

What I see is that the run with == is quite a bit slower.

With the == check:


StringOther.regionMatchesU1024LL  avgt   15   187.258 ?   1.038  ns/op
StringOther.regionMatchesU1024LU  avgt   15  2589.833 ?   8.823  ns/op
StringOther.regionMatchesU1024UL  avgt   15  2379.645 ?   6.481  ns/op
StringOther.regionMatchesU1024UU  avgt   15   191.587 ?   7.069  ns/op


Without the == check:


StringOther.regionMatchesU1024LL  avgt   15   187.732 ?   1.914  ns/op
StringOther.regionMatchesU1024LU  avgt   15  1324.156 ?  11.761  ns/op
StringOther.regionMatchesU1024UL  avgt   15  1331.857 ?  22.509  ns/op
StringOther.regionMatchesU1024UU  avgt   15   188.872 ?   2.396  ns/op


In the JMH cases, does the long prefix of latin1 characters distort the timings?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Wed Apr 20 21:08:19 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 21:08:19 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  remove = check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8308/files
  - new: https://git.openjdk.java.net/jdk/pull/8308/files/ac6d75e4..58a1732c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8308&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8308&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8308.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8308/head:pull/8308

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Wed Apr 20 21:08:19 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 21:08:19 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v2]
In-Reply-To: <M4qwoJ9XCVsCGDcavBvHk470DR4N881jFrrZsX2p9Ck=.0e52a2a3-1ce7-4dcb-b4e5-9f8ca41187ee@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <-GYRyP07f4XJ9MIvBJXTiGmypQfawlgtyOpNsT4eAX4=.c67110f5-0d06-4c4f-8caa-e22b291fbd1e@github.com>
 <M4qwoJ9XCVsCGDcavBvHk470DR4N881jFrrZsX2p9Ck=.0e52a2a3-1ce7-4dcb-b4e5-9f8ca41187ee@github.com>
Message-ID: <268WL-KpgGkLkhqLrLkiHp4hlgAWI8GTy_sio2YrfT0=.04d2fbee-32d6-4f51-991e-b888f0e91f65@github.com>

On Wed, 20 Apr 2022 20:56:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add jmh test
>
> Thanks for the JMH tests and data.
> 
> The only part needed from the JMH run is the last 9 lines.  The rest is noise.
> If it was formatted as a literal it would be easier to read.
> 
> What I see is that the run with == is quite a bit slower.
> 
> With the == check:
> 
> 
> StringOther.regionMatchesU1024LL  avgt   15   187.258 ?   1.038  ns/op
> StringOther.regionMatchesU1024LU  avgt   15  2589.833 ?   8.823  ns/op
> StringOther.regionMatchesU1024UL  avgt   15  2379.645 ?   6.481  ns/op
> StringOther.regionMatchesU1024UU  avgt   15   191.587 ?   7.069  ns/op
> 
> 
> Without the == check:
> 
> 
> StringOther.regionMatchesU1024LL  avgt   15   187.732 ?   1.914  ns/op
> StringOther.regionMatchesU1024LU  avgt   15  1324.156 ?  11.761  ns/op
> StringOther.regionMatchesU1024UL  avgt   15  1331.857 ?  22.509  ns/op
> StringOther.regionMatchesU1024UU  avgt   15   188.872 ?   2.396  ns/op
> 
> 
> In the JMH cases, does the long prefix of latin1 characters distort the timings?

@RogerRiggs

> What I see is that the run with == is quite a bit slower.

Yes, the result is amazing to me. Before you reply I re-run several times but similar result. So I respect the truth.

> In the JMH cases, does the long prefix of latin1 characters distort the timings?

No, the long prefix part is where real difference comes.

So according to jmh result, the = check removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From rriggs at openjdk.java.net  Wed Apr 20 21:22:24 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 20 Apr 2022 21:22:24 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
Message-ID: <yLQXgvB3SBCwRq9o9n7QKq3mZvYkvDhs_FbSF23nPws=.6642d692-0696-4450-a633-1f1f9873299d@github.com>

On Wed, 20 Apr 2022 21:08:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
>> 
>>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> should be changed to 
>> 
>>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> as:
>> 
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove = check

Can you run the JMH against the code before either change (or an existing JDK).
It would be interesting to quantify the improvements of going straight to Latin1.

(Understanding current hardware architectures and their parallelism is hard to understand well.
They do clever things with branch prediction and potentially optimistically executing both paths
and then discarding the non-branch case.  The existing code for toLower and toUpper already includes a branch or two; adding one more branch to the sequence likely can't be optimized.)

These interactions at the instruction level is why measuring is important.
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From some-java-user-99206970363698485155 at vodafonemail.de  Wed Apr 20 21:30:07 2022
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Wed, 20 Apr 2022 23:30:07 +0200
Subject: Improve `finally` block exception handling
In-Reply-To: <3f4e5d059fec471f89972683e14123a7@vodafonemail.de>
Message-ID: <4c1e4a7f65ec4051b40215c826b7cd3f@vodafonemail.de>

Thanks a lot for your feedback! My original message was a bit vague in parts, sorry for that.

The proposal consists of the following:
1. Forbidding usage of `break`, `continue`, `yield` and `return` in `finally` blocks
2. Adding exceptions as suppressed exceptions:
   If exception E1 led to execution of the `finally` block and the block is left due to
   another exception E2, then either E1 or E2 should be thrown with the other one added
   as suppressed exception. For consistency with try-with-resources and because E1 is
   most likely more relevant ideally E1 would be thrown and E2 should be suppressed. But
   if you think the impact on backward compatibility would be too large, then E2 should
   be thrown (the current behavior), but E1 should at least be added as suppressed exception.

The following replies to your comments hopefully make the rationale for these proposed
changes clearer.


> The behaviour of try/catch/finally is not "obvious at all", you have to read what it means
> and when you do that you clearly see what happens regarding exceptions.

For try-catch you see that the code catches some specific exception and then handles it in a
certain way, whether that is by rethrowing, logging or itentionally ignoring it.
The issue with `finally` is that in its current form, exceptions which occurred in the `try`
block might just silently disappear. Consider this simple example:
```
try {
    throw new RuntimeException();
} finally {
    return true;
}
```
Here it is not clear at all, unless you have read the JLS in detail, that the thrown exception
just vanishes. There is no explicit indication that the `finally` has any effect on the
thrown exception. Of course this is a contrived example, but consider the same situation where
the `try` block calls a method which might throw an exception (or the general case that a
VirtualMachineError occurs), and that the `return` (or any of the other affected statements)
is not the only statement in the `finally` block.

Similar confusing code can be written where the `try` or `catch` block returns a value
(or continues or breaks loop iteration), but the `finally` block overwrites that action:
```
try {
    return 1;
} finally {
    return 2;
}
```
Again, contrived, but consider the same code with additional statements in the `try` and
`finally` blocks. This breaks fundamental assumptions one has about the behavior of the
statements, such as `return`.

>> Are there any plans to forbid usage of `break`, `continue`, `yield` and `return` in
>> `finally` blocks?
>
> Why would we do that? What would that gain?

It would prevent code such as the one shown above, where code, most likely unintentionally,
discards exceptions. Now also consider that inside the `try` block a VirtualMachineError
(or a subclass of it) may occur which you really should not catch. Yet the code in the
`finally` block silently discards it without you ever noticing the error, before it occurs
later in another part of the application again and has possibly already corrupted the state
of the application.


>> Similarly for `throw` and any implicitly thrown exceptions, is there a plan to at least
>> add the original exception as suppressed one to the newly thrown?
>
> That suggestion is not completely without merit, but nor is it a "slam-dunk" obvious thing to do. The semantic implications of the exceptions matter, and semantics come from the programmers intent. There's no reasonable way to automagically determine that when an exception is created that another exception (that led to the finally block) should be inserted as a "suppressed exception". That would actually be completely wrong to do in many circumstances you would instead need to act when the exception would terminate the finally block and then add the original exception as the "suppressed" exception.

To clarify my suggestion: If a `finally` block is entered due to an exception E1, and is
exited due to an exception E2 (regardless of whether explicitly thrown by a `throw` statement),
and E1 != E2, then both exceptions should be preserved, with one being added as suppressed
exception to the other one.


> But really the programmer is in the best position to decide how exceptions need to be handled.

Except that in a `finally` block they don't have access to the exception which led to execution
of the `finally` block, unless they write verbose hacky code to first have a `catch (Throwable)`
which stores the caught exception in a local variable. To me it appears for many `finally`
blocks in existing code it was not actively decided how exception handling should be done,
but rather it was forgotten that the original exception might get discarded when the `finally`
throws a new exception; or that behavior was considered acceptable because currently Java does
not allow you to handle it in a better way (which is one of the main points of this proposal).

>> Of course one could argue that the same applies to `catch` clauses whose body accidentally
>> causes an exception which discards the caught one. However the main difference is that
>
> Yes exactly the same.

This point was mainly a safeguard in my proposal to avoid someone extending the scope of
this proposal to `catch` clauses as well, which then could cause this proposal as a whole
to be turned down. Therefore I am explicitly not arguing for any changes to `catch` clauses
exception handling / suppression here, because there it is at least somewhat more obvious
what is going on with the exceptions.

>> there, only a specific exception type is caught (and discarded), whereas for `finally`
>> exceptions of _any_ type are discarded. It could also be argued that adding suppressed
>
> We have multi-catch now so that argument is somewhat weaker.

The point here was that you explicitly write the exception type, whether that is a single type
or a union type in case of a multi-catch, in constrast to how `finally` discards any exception
type without you explicitly naming the type.

>> exceptions decreases performance or causes memory leaks, but one the other hand
>> this behavior was explicitly included try-with-resources statements, most likely because the
>> value this adds was considered more important than any performance issues this
>> might cause.
>
> try-with-resources added support for suppressed exceptions because the automatic closing of the resource could throw an exception, and that had to be factored in to the whole mechanism.

Yes, but I think the scenarios are exactly identical:
try-with-resources:
  1. Original exception E1 occurs
  2. Resource cleanup is done, here through implicit `close()`
  3. `close()` throws an exception E2
  4. E2 is added as suppressed to E1

Current `finally` block behavior:
  1. Original exception E1 occurs
  2. Resource cleanup is done, here manually in `finally` block
  3. `finally` block throws an exception E2
  4. !! E1 is silently lost !!

Why is it here acceptable to lose the original exception E1, even though the use
cases are exactly the same?

I assume the reason why they behave differently is historic, because `finally` blocks
exist way longer than suppressed exceptions. However, that does in my opinion not
preclude updating it retroactively, especially when it is unlikely that the difference
will have a visible negative effect at runtime, but instead makes understanding
application failures easier.

Kind regards



From duke at openjdk.java.net  Wed Apr 20 21:55:24 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 20 Apr 2022 21:55:24 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <yLQXgvB3SBCwRq9o9n7QKq3mZvYkvDhs_FbSF23nPws=.6642d692-0696-4450-a633-1f1f9873299d@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
 <yLQXgvB3SBCwRq9o9n7QKq3mZvYkvDhs_FbSF23nPws=.6642d692-0696-4450-a633-1f1f9873299d@github.com>
Message-ID: <2NKuBNB04G8LfWxsKSO5wqyeNgUNrygqH3U9H0hMUf0=.6c9911cb-b3c7-4dfa-bd56-649aec7738e9@github.com>

On Wed, 20 Apr 2022 21:19:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove = check
>
> Can you run the JMH against the code before either change (or an existing JDK).
> It would be interesting to quantify the improvements of going straight to Latin1.
> 
> (Understanding current hardware architectures and their parallelism is hard to understand well.
> They do clever things with branch prediction and potentially optimistically executing both paths
> and then discarding the non-branch case.  The existing code for toLower and toUpper already includes a branch or two; adding one more branch to the sequence likely can't be optimized.)
> 
> These interactions at the instruction level is why measuring is important.
> Thanks

@RogerRiggs 

seems all 4 tests related runs very very slightlier slower in original codes, before change it to CharacterDataLatin1.instance

<details>
<summary>Jmh Result (original)</summary>
<p>

# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.charAt

# Run progress: 0.00% complete, ETA 00:06:00
# Fork: 1 of 3
# Warmup Iteration   1: 70.457 ns/op
# Warmup Iteration   2: 73.255 ns/op
# Warmup Iteration   3: 71.446 ns/op
# Warmup Iteration   4: 73.454 ns/op
# Warmup Iteration   5: 73.618 ns/op
# Warmup Iteration   6: 72.853 ns/op
# Warmup Iteration   7: 74.493 ns/op
# Warmup Iteration   8: 74.862 ns/op
# Warmup Iteration   9: 74.323 ns/op
# Warmup Iteration  10: 73.759 ns/op
Iteration   1: 73.053 ns/op
Iteration   2: 70.180 ns/op
Iteration   3: 70.337 ns/op
Iteration   4: 73.237 ns/op
Iteration   5: 73.156 ns/op

# Run progress: 4.17% complete, ETA 00:05:52
# Fork: 2 of 3
# Warmup Iteration   1: 72.617 ns/op
# Warmup Iteration   2: 71.344 ns/op
# Warmup Iteration   3: 73.582 ns/op
# Warmup Iteration   4: 73.309 ns/op
# Warmup Iteration   5: 74.078 ns/op
# Warmup Iteration   6: 75.177 ns/op
# Warmup Iteration   7: 72.578 ns/op
# Warmup Iteration   8: 72.028 ns/op
# Warmup Iteration   9: 72.897 ns/op
# Warmup Iteration  10: 69.317 ns/op
Iteration   1: 69.303 ns/op
Iteration   2: 69.157 ns/op
Iteration   3: 69.078 ns/op
Iteration   4: 69.142 ns/op
Iteration   5: 70.084 ns/op

# Run progress: 8.33% complete, ETA 00:05:36
# Fork: 3 of 3
# Warmup Iteration   1: 72.149 ns/op
# Warmup Iteration   2: 73.753 ns/op
# Warmup Iteration   3: 70.621 ns/op
# Warmup Iteration   4: 74.384 ns/op
# Warmup Iteration   5: 71.787 ns/op
# Warmup Iteration   6: 74.946 ns/op
# Warmup Iteration   7: 74.463 ns/op
# Warmup Iteration   8: 73.403 ns/op
# Warmup Iteration   9: 71.675 ns/op
# Warmup Iteration  10: 72.550 ns/op
Iteration   1: 66.963 ns/op
Iteration   2: 72.209 ns/op
Iteration   3: 71.639 ns/op
Iteration   4: 71.262 ns/op
Iteration   5: 74.514 ns/op


Result "org.openjdk.bench.java.lang.StringOther.charAt":
  70.888 ?(99.9%) 2.207 ns/op [Average]
  (min, avg, max) = (66.963, 70.888, 74.514), stdev = 2.064
  CI (99.9%): [68.681, 73.094] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.compareTo

# Run progress: 12.50% complete, ETA 00:05:21
# Fork: 1 of 3
# Warmup Iteration   1: 7.648 ns/op
# Warmup Iteration   2: 7.576 ns/op
# Warmup Iteration   3: 7.024 ns/op
# Warmup Iteration   4: 7.595 ns/op
# Warmup Iteration   5: 7.605 ns/op
# Warmup Iteration   6: 7.555 ns/op
# Warmup Iteration   7: 7.573 ns/op
# Warmup Iteration   8: 7.592 ns/op
# Warmup Iteration   9: 7.673 ns/op
# Warmup Iteration  10: 7.255 ns/op
Iteration   1: 7.268 ns/op
Iteration   2: 7.183 ns/op
Iteration   3: 7.267 ns/op
Iteration   4: 7.253 ns/op
Iteration   5: 7.248 ns/op

# Run progress: 16.67% complete, ETA 00:05:06
# Fork: 2 of 3
# Warmup Iteration   1: 7.654 ns/op
# Warmup Iteration   2: 7.626 ns/op
# Warmup Iteration   3: 7.006 ns/op
# Warmup Iteration   4: 7.610 ns/op
# Warmup Iteration   5: 7.564 ns/op
# Warmup Iteration   6: 7.566 ns/op
# Warmup Iteration   7: 7.561 ns/op
# Warmup Iteration   8: 7.554 ns/op
# Warmup Iteration   9: 7.525 ns/op
# Warmup Iteration  10: 7.156 ns/op
Iteration   1: 7.137 ns/op
Iteration   2: 7.173 ns/op
Iteration   3: 7.180 ns/op
Iteration   4: 7.168 ns/op
Iteration   5: 7.239 ns/op

# Run progress: 20.83% complete, ETA 00:04:50
# Fork: 3 of 3
# Warmup Iteration   1: 7.595 ns/op
# Warmup Iteration   2: 7.556 ns/op
# Warmup Iteration   3: 6.966 ns/op
# Warmup Iteration   4: 7.513 ns/op
# Warmup Iteration   5: 7.546 ns/op
# Warmup Iteration   6: 7.415 ns/op
# Warmup Iteration   7: 7.449 ns/op
# Warmup Iteration   8: 7.557 ns/op
# Warmup Iteration   9: 7.485 ns/op
# Warmup Iteration  10: 7.210 ns/op
Iteration   1: 7.234 ns/op
Iteration   2: 7.165 ns/op
Iteration   3: 7.194 ns/op
Iteration   4: 7.195 ns/op
Iteration   5: 7.255 ns/op


Result "org.openjdk.bench.java.lang.StringOther.compareTo":
  7.210 ?(99.9%) 0.046 ns/op [Average]
  (min, avg, max) = (7.137, 7.210, 7.268), stdev = 0.043
  CI (99.9%): [7.164, 7.257] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.internUnique

# Run progress: 25.00% complete, ETA 00:04:35
# Fork: 1 of 3
# Warmup Iteration   1: 721.255 ns/op
# Warmup Iteration   2: 738.384 ns/op
# Warmup Iteration   3: 787.659 ns/op
# Warmup Iteration   4: 855.374 ns/op
# Warmup Iteration   5: 1162.055 ns/op
# Warmup Iteration   6: 1366.581 ns/op
# Warmup Iteration   7: 1576.950 ns/op
# Warmup Iteration   8: 1707.555 ns/op
# Warmup Iteration   9: 1909.602 ns/op
# Warmup Iteration  10: 1991.609 ns/op
Iteration   1: 2126.098 ns/op
Iteration   2: 2247.201 ns/op
Iteration   3: 2365.506 ns/op
Iteration   4: 2481.897 ns/op
Iteration   5: 2602.970 ns/op

# Run progress: 29.17% complete, ETA 00:04:20
# Fork: 2 of 3
# Warmup Iteration   1: 732.419 ns/op
# Warmup Iteration   2: 734.784 ns/op
# Warmup Iteration   3: 776.857 ns/op
# Warmup Iteration   4: 862.338 ns/op
# Warmup Iteration   5: 1161.400 ns/op
# Warmup Iteration   6: 1390.485 ns/op
# Warmup Iteration   7: 1564.553 ns/op
# Warmup Iteration   8: 1740.864 ns/op
# Warmup Iteration   9: 1886.047 ns/op
# Warmup Iteration  10: 1996.744 ns/op
Iteration   1: 2134.201 ns/op
Iteration   2: 2237.158 ns/op
Iteration   3: 2373.474 ns/op
Iteration   4: 2480.673 ns/op
Iteration   5: 2600.095 ns/op

# Run progress: 33.33% complete, ETA 00:04:05
# Fork: 3 of 3
# Warmup Iteration   1: 723.303 ns/op
# Warmup Iteration   2: 730.116 ns/op
# Warmup Iteration   3: 747.244 ns/op
# Warmup Iteration   4: 870.327 ns/op
# Warmup Iteration   5: 1163.600 ns/op
# Warmup Iteration   6: 1391.905 ns/op
# Warmup Iteration   7: 1609.695 ns/op
# Warmup Iteration   8: 1747.073 ns/op
# Warmup Iteration   9: 1901.428 ns/op
# Warmup Iteration  10: 2037.695 ns/op
Iteration   1: 2138.309 ns/op
Iteration   2: 2261.873 ns/op
Iteration   3: 2379.407 ns/op
Iteration   4: 2495.306 ns/op
Iteration   5: 2598.640 ns/op


Result "org.openjdk.bench.java.lang.StringOther.internUnique":
  2368.187 ?(99.9%) 183.667 ns/op [Average]
  (min, avg, max) = (2126.098, 2368.187, 2602.970), stdev = 171.803
  CI (99.9%): [2184.520, 2551.855] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1

# Run progress: 37.50% complete, ETA 00:03:49
# Fork: 1 of 3
# Warmup Iteration   1: 27.793 ns/op
# Warmup Iteration   2: 27.260 ns/op
# Warmup Iteration   3: 26.885 ns/op
# Warmup Iteration   4: 26.953 ns/op
# Warmup Iteration   5: 27.178 ns/op
# Warmup Iteration   6: 26.945 ns/op
# Warmup Iteration   7: 27.820 ns/op
# Warmup Iteration   8: 27.217 ns/op
# Warmup Iteration   9: 27.922 ns/op
# Warmup Iteration  10: 27.038 ns/op
Iteration   1: 26.504 ns/op
Iteration   2: 26.891 ns/op
Iteration   3: 26.936 ns/op
Iteration   4: 26.798 ns/op
Iteration   5: 26.750 ns/op

# Run progress: 41.67% complete, ETA 00:03:34
# Fork: 2 of 3
# Warmup Iteration   1: 27.393 ns/op
# Warmup Iteration   2: 27.862 ns/op
# Warmup Iteration   3: 26.308 ns/op
# Warmup Iteration   4: 27.392 ns/op
# Warmup Iteration   5: 27.782 ns/op
# Warmup Iteration   6: 27.679 ns/op
# Warmup Iteration   7: 27.454 ns/op
# Warmup Iteration   8: 26.879 ns/op
# Warmup Iteration   9: 27.335 ns/op
# Warmup Iteration  10: 26.984 ns/op
Iteration   1: 26.375 ns/op
Iteration   2: 26.432 ns/op
Iteration   3: 26.588 ns/op
Iteration   4: 26.340 ns/op
Iteration   5: 26.378 ns/op

# Run progress: 45.83% complete, ETA 00:03:19
# Fork: 3 of 3
# Warmup Iteration   1: 27.703 ns/op
# Warmup Iteration   2: 27.526 ns/op
# Warmup Iteration   3: 26.139 ns/op
# Warmup Iteration   4: 27.495 ns/op
# Warmup Iteration   5: 27.239 ns/op
# Warmup Iteration   6: 27.491 ns/op
# Warmup Iteration   7: 26.857 ns/op
# Warmup Iteration   8: 27.469 ns/op
# Warmup Iteration   9: 27.390 ns/op
# Warmup Iteration  10: 26.636 ns/op
Iteration   1: 26.784 ns/op
Iteration   2: 26.685 ns/op
Iteration   3: 26.630 ns/op
Iteration   4: 26.664 ns/op
Iteration   5: 26.914 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesLatin1":
  26.645 ?(99.9%) 0.217 ns/op [Average]
  (min, avg, max) = (26.340, 26.645, 26.936), stdev = 0.203
  CI (99.9%): [26.427, 26.862] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL

# Run progress: 50.00% complete, ETA 00:03:03
# Fork: 1 of 3
# Warmup Iteration   1: 384.034 ns/op
# Warmup Iteration   2: 386.145 ns/op
# Warmup Iteration   3: 192.375 ns/op
# Warmup Iteration   4: 385.160 ns/op
# Warmup Iteration   5: 388.339 ns/op
# Warmup Iteration   6: 394.354 ns/op
# Warmup Iteration   7: 389.876 ns/op
# Warmup Iteration   8: 392.541 ns/op
# Warmup Iteration   9: 396.471 ns/op
# Warmup Iteration  10: 189.031 ns/op
Iteration   1: 191.889 ns/op
Iteration   2: 191.517 ns/op
Iteration   3: 189.627 ns/op
Iteration   4: 189.437 ns/op
Iteration   5: 188.183 ns/op

# Run progress: 54.17% complete, ETA 00:02:48
# Fork: 2 of 3
# Warmup Iteration   1: 386.763 ns/op
# Warmup Iteration   2: 387.674 ns/op
# Warmup Iteration   3: 188.244 ns/op
# Warmup Iteration   4: 386.972 ns/op
# Warmup Iteration   5: 394.980 ns/op
# Warmup Iteration   6: 393.451 ns/op
# Warmup Iteration   7: 385.662 ns/op
# Warmup Iteration   8: 386.794 ns/op
# Warmup Iteration   9: 388.771 ns/op
# Warmup Iteration  10: 188.608 ns/op
Iteration   1: 191.659 ns/op
Iteration   2: 190.469 ns/op
Iteration   3: 190.416 ns/op
Iteration   4: 191.333 ns/op
Iteration   5: 193.085 ns/op

# Run progress: 58.33% complete, ETA 00:02:33
# Fork: 3 of 3
# Warmup Iteration   1: 386.921 ns/op
# Warmup Iteration   2: 386.713 ns/op
# Warmup Iteration   3: 192.961 ns/op
# Warmup Iteration   4: 388.269 ns/op
# Warmup Iteration   5: 396.061 ns/op
# Warmup Iteration   6: 392.936 ns/op
# Warmup Iteration   7: 392.474 ns/op
# Warmup Iteration   8: 397.539 ns/op
# Warmup Iteration   9: 395.017 ns/op
# Warmup Iteration  10: 192.466 ns/op
Iteration   1: 188.695 ns/op
Iteration   2: 189.254 ns/op
Iteration   3: 189.562 ns/op
Iteration   4: 191.183 ns/op
Iteration   5: 191.548 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LL":
  190.524 ?(99.9%) 1.462 ns/op [Average]
  (min, avg, max) = (188.183, 190.524, 193.085), stdev = 1.368
  CI (99.9%): [189.061, 191.986] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU

# Run progress: 62.50% complete, ETA 00:02:17
# Fork: 1 of 3
# Warmup Iteration   1: 1886.842 ns/op
# Warmup Iteration   2: 1951.907 ns/op
# Warmup Iteration   3: 1336.138 ns/op
# Warmup Iteration   4: 1969.057 ns/op
# Warmup Iteration   5: 1977.544 ns/op
# Warmup Iteration   6: 1955.080 ns/op
# Warmup Iteration   7: 1955.399 ns/op
# Warmup Iteration   8: 1948.878 ns/op
# Warmup Iteration   9: 1974.372 ns/op
# Warmup Iteration  10: 1325.548 ns/op
Iteration   1: 1324.446 ns/op
Iteration   2: 1317.174 ns/op
Iteration   3: 1320.426 ns/op
Iteration   4: 1322.694 ns/op
Iteration   5: 1354.689 ns/op

# Run progress: 66.67% complete, ETA 00:02:02
# Fork: 2 of 3
# Warmup Iteration   1: 1881.938 ns/op
# Warmup Iteration   2: 1940.219 ns/op
# Warmup Iteration   3: 1331.686 ns/op
# Warmup Iteration   4: 1966.264 ns/op
# Warmup Iteration   5: 1959.955 ns/op
# Warmup Iteration   6: 1943.985 ns/op
# Warmup Iteration   7: 1960.606 ns/op
# Warmup Iteration   8: 1950.825 ns/op
# Warmup Iteration   9: 1953.092 ns/op
# Warmup Iteration  10: 1325.135 ns/op
Iteration   1: 1329.842 ns/op
Iteration   2: 1324.868 ns/op
Iteration   3: 1335.141 ns/op
Iteration   4: 1341.477 ns/op
Iteration   5: 1345.784 ns/op

# Run progress: 70.83% complete, ETA 00:01:47
# Fork: 3 of 3
# Warmup Iteration   1: 1726.861 ns/op
# Warmup Iteration   2: 1760.492 ns/op
# Warmup Iteration   3: 1338.569 ns/op
# Warmup Iteration   4: 1762.623 ns/op
# Warmup Iteration   5: 1767.371 ns/op
# Warmup Iteration   6: 1749.098 ns/op
# Warmup Iteration   7: 1748.149 ns/op
# Warmup Iteration   8: 1768.330 ns/op
# Warmup Iteration   9: 1777.755 ns/op
# Warmup Iteration  10: 1335.878 ns/op
Iteration   1: 1313.298 ns/op
Iteration   2: 1326.874 ns/op
Iteration   3: 1334.138 ns/op
Iteration   4: 1324.629 ns/op
Iteration   5: 1333.529 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024LU":
  1329.934 ?(99.9%) 11.886 ns/op [Average]
  (min, avg, max) = (1313.298, 1329.934, 1354.689), stdev = 11.118
  CI (99.9%): [1318.048, 1341.820] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL

# Run progress: 75.00% complete, ETA 00:01:31
# Fork: 1 of 3
# Warmup Iteration   1: 1698.300 ns/op
# Warmup Iteration   2: 1792.648 ns/op
# Warmup Iteration   3: 1362.651 ns/op
# Warmup Iteration   4: 1793.508 ns/op
# Warmup Iteration   5: 1776.535 ns/op
# Warmup Iteration   6: 1734.500 ns/op
# Warmup Iteration   7: 1749.249 ns/op
# Warmup Iteration   8: 1733.342 ns/op
# Warmup Iteration   9: 1767.894 ns/op
# Warmup Iteration  10: 1452.358 ns/op
Iteration   1: 1508.769 ns/op
Iteration   2: 1396.692 ns/op
Iteration   3: 1359.459 ns/op
Iteration   4: 1381.066 ns/op
Iteration   5: 1333.066 ns/op

# Run progress: 79.17% complete, ETA 00:01:16
# Fork: 2 of 3
# Warmup Iteration   1: 1722.288 ns/op
# Warmup Iteration   2: 1759.843 ns/op
# Warmup Iteration   3: 1329.077 ns/op
# Warmup Iteration   4: 1746.541 ns/op
# Warmup Iteration   5: 1780.978 ns/op
# Warmup Iteration   6: 1754.303 ns/op
# Warmup Iteration   7: 1755.167 ns/op
# Warmup Iteration   8: 1758.167 ns/op
# Warmup Iteration   9: 1753.601 ns/op
# Warmup Iteration  10: 1318.156 ns/op
Iteration   1: 1336.835 ns/op
Iteration   2: 1307.115 ns/op
Iteration   3: 1318.644 ns/op
Iteration   4: 1319.236 ns/op
Iteration   5: 1328.117 ns/op

# Run progress: 83.33% complete, ETA 00:01:01
# Fork: 3 of 3
# Warmup Iteration   1: 1687.909 ns/op
# Warmup Iteration   2: 1761.530 ns/op
# Warmup Iteration   3: 1325.844 ns/op
# Warmup Iteration   4: 1760.050 ns/op
# Warmup Iteration   5: 1846.705 ns/op
# Warmup Iteration   6: 1831.452 ns/op
# Warmup Iteration   7: 1756.480 ns/op
# Warmup Iteration   8: 1751.992 ns/op
# Warmup Iteration   9: 1737.721 ns/op
# Warmup Iteration  10: 1305.649 ns/op
Iteration   1: 1307.646 ns/op
Iteration   2: 1316.020 ns/op
Iteration   3: 1305.341 ns/op
Iteration   4: 1322.055 ns/op
Iteration   5: 1311.291 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UL":
  1343.423 ?(99.9%) 56.946 ns/op [Average]
  (min, avg, max) = (1305.341, 1343.423, 1508.769), stdev = 53.267
  CI (99.9%): [1286.478, 1400.369] (assumes normal distribution)


# JMH version: 1.34
# VM version: JDK 19-internal, OpenJDK 64-Bit Server VM, 19-internal-adhoc..jdk
# VM invoker: F:\workspace\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
# VM options: -Djava.library.path=f:\workspace\jdk\build\windows-x86_64-server-release\images\test\micro\native
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 10 iterations, 1000 ms each
# Measurement: 5 iterations, 1000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU

# Run progress: 87.50% complete, ETA 00:00:45
# Fork: 1 of 3
# Warmup Iteration   1: 384.307 ns/op
# Warmup Iteration   2: 393.025 ns/op
# Warmup Iteration   3: 188.918 ns/op
# Warmup Iteration   4: 388.716 ns/op
# Warmup Iteration   5: 389.077 ns/op
# Warmup Iteration   6: 393.182 ns/op
# Warmup Iteration   7: 396.038 ns/op
# Warmup Iteration   8: 386.322 ns/op
# Warmup Iteration   9: 388.637 ns/op
# Warmup Iteration  10: 188.833 ns/op
Iteration   1: 189.554 ns/op
Iteration   2: 191.854 ns/op
Iteration   3: 190.570 ns/op
Iteration   4: 192.731 ns/op
Iteration   5: 193.851 ns/op

# Run progress: 91.67% complete, ETA 00:00:30
# Fork: 2 of 3
# Warmup Iteration   1: 383.292 ns/op
# Warmup Iteration   2: 390.798 ns/op
# Warmup Iteration   3: 188.544 ns/op
# Warmup Iteration   4: 386.818 ns/op
# Warmup Iteration   5: 385.428 ns/op
# Warmup Iteration   6: 391.337 ns/op
# Warmup Iteration   7: 392.357 ns/op
# Warmup Iteration   8: 395.916 ns/op
# Warmup Iteration   9: 394.474 ns/op
# Warmup Iteration  10: 190.443 ns/op
Iteration   1: 190.693 ns/op
Iteration   2: 191.330 ns/op
Iteration   3: 191.545 ns/op
Iteration   4: 189.648 ns/op
Iteration   5: 190.392 ns/op

# Run progress: 95.83% complete, ETA 00:00:15
# Fork: 3 of 3
# Warmup Iteration   1: 387.182 ns/op
# Warmup Iteration   2: 387.931 ns/op
# Warmup Iteration   3: 191.014 ns/op
# Warmup Iteration   4: 389.244 ns/op
# Warmup Iteration   5: 389.680 ns/op
# Warmup Iteration   6: 387.478 ns/op
# Warmup Iteration   7: 386.103 ns/op
# Warmup Iteration   8: 393.928 ns/op
# Warmup Iteration   9: 394.937 ns/op
# Warmup Iteration  10: 189.155 ns/op
Iteration   1: 189.103 ns/op
Iteration   2: 188.165 ns/op
Iteration   3: 190.563 ns/op
Iteration   4: 192.239 ns/op
Iteration   5: 192.589 ns/op


Result "org.openjdk.bench.java.lang.StringOther.regionMatchesU1024UU":
  190.988 ?(99.9%) 1.634 ns/op [Average]
  (min, avg, max) = (188.165, 190.988, 193.851), stdev = 1.529
  CI (99.9%): [189.354, 192.623] (assumes normal distribution)


# Run complete. Total time: 00:06:07

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.

Benchmark                         Mode  Cnt     Score     Error  Units
StringOther.charAt                avgt   15    70.888 ?   2.207  ns/op
StringOther.compareTo             avgt   15     7.210 ?   0.046  ns/op
StringOther.internUnique          avgt   15  2368.187 ? 183.667  ns/op
StringOther.regionMatchesLatin1   avgt   15    26.645 ?   0.217  ns/op
StringOther.regionMatchesU1024LL  avgt   15   190.524 ?   1.462  ns/op
StringOther.regionMatchesU1024LU  avgt   15  1329.934 ?  11.886  ns/op
StringOther.regionMatchesU1024UL  avgt   15  1343.423 ?  56.946  ns/op
StringOther.regionMatchesU1024UU  avgt   15   190.988 ?   1.634  ns/op


</p>
</details>

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From joehw at openjdk.java.net  Wed Apr 20 21:58:29 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 21:58:29 GMT
Subject: RFR: 8284548: Invalid XPath expression causes
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
References: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
Message-ID: <LpXBcY-WQ4___uG01fZZdgdjIptSKC77pRrRNauuMs4=.e13068c8-8beb-4070-a5c2-dc1c6fb83b15@github.com>

> Patch note:
> 
> A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected.
>     
> Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8323/files
  - new: https://git.openjdk.java.net/jdk/pull/8323/files/4205ea6f..17b8c3e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8323&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8323&range=00-01

  Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8323.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8323/head:pull/8323

PR: https://git.openjdk.java.net/jdk/pull/8323

From lancea at openjdk.java.net  Wed Apr 20 21:58:29 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 20 Apr 2022 21:58:29 GMT
Subject: RFR: 8284548: Invalid XPath expression causes
 StringIndexOutOfBoundsException [v2]
In-Reply-To: <LpXBcY-WQ4___uG01fZZdgdjIptSKC77pRrRNauuMs4=.e13068c8-8beb-4070-a5c2-dc1c6fb83b15@github.com>
References: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
 <LpXBcY-WQ4___uG01fZZdgdjIptSKC77pRrRNauuMs4=.e13068c8-8beb-4070-a5c2-dc1c6fb83b15@github.com>
Message-ID: <wrRFKofxdQouI9juTTMGNqzte6BrajplcxCO17DSfos=.79e471f3-575b-44a8-8fef-add87c58c7a9@github.com>

On Wed, 20 Apr 2022 21:53:46 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Patch note:
>> 
>> A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected.
>>     
>> Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add the test

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8323

From joehw at openjdk.java.net  Wed Apr 20 23:11:33 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 20 Apr 2022 23:11:33 GMT
Subject: Integrated: 8284548: Invalid XPath expression causes
 StringIndexOutOfBoundsException
In-Reply-To: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
References: <mMs5jE6NC4KCbFQp5KlAtacflD0G0KzjzsAiG4xQMmo=.1ee8551c-6a60-448a-b9e6-6cfbc1938267@github.com>
Message-ID: <ZTfFay_D1TcdhGw_iniLUNzSnZZS3W7LC_Q-qNLJ-d0=.198b1335-937f-41d1-b480-a888a4828a1c@github.com>

On Wed, 20 Apr 2022 20:08:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Patch note:
> 
> A previous patch had a bug that missed the boundary check, that will cause StringIndexOutOfBoundsException to be thrown instead of XPathExpressionException as expected.
>     
> Fix: the fix is to check the boundaries of the parameter "index". Objects.checkIndex is removed as it's redundant.

This pull request has now been integrated.

Changeset: 994f2e92
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/994f2e9271355bebf355279d0208c1d2054bab27
Stats:     86 lines in 2 files changed: 82 ins; 2 del; 2 mod

8284548: Invalid XPath expression causes StringIndexOutOfBoundsException

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8323

From naoto at openjdk.java.net  Wed Apr 20 23:57:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 20 Apr 2022 23:57:58 GMT
Subject: RFR: 8283324: CLDRConverter run time increased by 3x
Message-ID: <w0GmHnHhWosUiATXdPu8wj5XEth-K3OJMutcQYV02DI=.2ba4b67d-f35a-4c80-a947-d479d2596616@github.com>

Fixing performance regression caused by the fix to https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra looping through the resource map multiple times which was not necessary. The execution time of the tool now got back on par with close to JDK18.

-------------

Commit messages:
 - 8283324: CLDRConverter run time increased by 3x

Changes: https://git.openjdk.java.net/jdk/pull/8288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8288&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283324
  Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8288.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8288/head:pull/8288

PR: https://git.openjdk.java.net/jdk/pull/8288

From smarks at openjdk.java.net  Thu Apr 21 00:04:25 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 00:04:25 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <AQ90drN3XWJus35qqILNE-umWyGaTSgtNOUMK5z-ziE=.7165096b-7298-4052-9cf1-ae511060cc56@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

I think it's a vanishingly small possibility that anything is relying on the synchronization in these methods. Synchronization here would provide proper memory visibility effects across threads. To use input streams from multiple threads without interleaving operations, one would have to provide some other means of coordination among those threads, which itself would likely ensure proper memory visibility. I'm hard pressed to see how threads could coordinate solely via use of the `mark` and `reset` methods. Therefore, I think it's safe to remove synchronization from them.

This reasoning also applies to `InputStream`. Perhaps synchronization can be removed from there too.

I agree that a CSR is probably warranted to capture the behavior change and analysis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From bpb at openjdk.java.net  Thu Apr 21 00:07:22 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Apr 2022 00:07:22 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <AQ90drN3XWJus35qqILNE-umWyGaTSgtNOUMK5z-ziE=.7165096b-7298-4052-9cf1-ae511060cc56@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
 <AQ90drN3XWJus35qqILNE-umWyGaTSgtNOUMK5z-ziE=.7165096b-7298-4052-9cf1-ae511060cc56@github.com>
Message-ID: <i6KIerZHPJLRb6RKiSeoJH8r4h5rnGafBAA5LLBe6Mw=.33dd3699-7fdd-4e86-b48c-1b173ee14c9d@github.com>

On Thu, 21 Apr 2022 00:00:47 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>

> I think it's a vanishingly small possibility that anything is relying on the synchronization in these methods. Synchronization here would provide proper memory visibility effects across threads. To use input streams from multiple threads without interleaving operations, one would have to provide some other means of coordination among those threads, which itself would likely ensure proper memory visibility. I'm hard pressed to see how threads could coordinate solely via use of the `mark` and `reset` methods. Therefore, I think it's safe to remove synchronization from them.
> 
> This reasoning also applies to `InputStream`. Perhaps synchronization can be removed from there too.
> 
> I agree that a CSR is probably warranted to capture the behavior change and analysis.

Commit f210cbf5f6bf58326a379b4b3f55fddf49d30f5c removed the synchronization from `InputStream`'s `mark()` and `reset()`; a CSR is on file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From smarks at openjdk.java.net  Thu Apr 21 00:45:23 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 00:45:23 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <8dSwwacwIU6h0TrGiP2lzCui1UKHNDreIuLlZz3fxng=.f2355e07-c25a-42f6-a2c0-b7eaf0cdb907@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Oh, sorry, I had missed that synchronization had already been removed from the `InputStream` methods. Needless to say, I approve. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From smarks at openjdk.java.net  Thu Apr 21 00:51:27 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 00:51:27 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

Thanks for working on this. Yes I can review and sponsor this change.

Sorry I got a bit distracted. I started looking at the test here, and this lead me to inquire about what other tests we have for `IdentityHashMap`, and the answer is: not enough. See [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295). (But that should be handled separately.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From smarks at openjdk.java.net  Thu Apr 21 00:56:28 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 00:56:28 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <d847y2kH-70Cj9XoFrgzLY1UvBNgJrPjaCXdwTYeZ8U=.cffa341c-3309-4142-bd8f-16f8dfb5e938@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

src/java.base/share/classes/java/util/IdentityHashMap.java line 1163:

> 1161:         public boolean remove(Object o) {
> 1162:             return o instanceof Entry<?, ?> entry
> 1163:                     && IdentityHashMap.this.remove(entry.getKey(), entry.getValue());

I would prefer to keep the internal `removeMapping` method and have other methods call it, instead of calling a public method. In particular the `EntrySet.remove()` method here should call an internal method to perform the actual removal instead of calling the public `remove()` method, since that potentially exposes the "self-use" to subclasses. The the public `remove()` method on IDHM could call `removeMapping`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From smarks at openjdk.java.net  Thu Apr 21 01:04:28 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 01:04:28 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <EHKvY9mVle4SPjVldpEH4-esmb3iLmsXK6EC_Pbj4zU=.b92896a5-c4ba-4a8a-8ee0-9e067fc36b72@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

src/java.base/share/classes/java/util/IdentityHashMap.java line 1412:

> 1410:             i = nextKeyIndex(i, len);
> 1411:         }
> 1412:     }

Unfortunately there's some mostly-duplicate code here. However, there's similar logic and code sprinkled throughout this class, so _more_ duplication isn't necessarily the wrong thing to do. However, trying to unify this logic results in much more intrusive refactoring, which is harder to review, and which isn't backed up with tests (see JDK-8285295) which I wouldn't encourage pursuing right now. In other words, I'm ok with this duplicate logic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From smarks at openjdk.java.net  Thu Apr 21 01:20:37 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 01:20:37 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <8xPZrvkPyyvAYVTff8s51KgNr9n0mZr-bcVPVnDmahg=.95dc1473-3782-4347-8854-2c9a3ccf265c@github.com>

On Fri, 15 Apr 2022 05:58:32 GMT, liach <duke at openjdk.java.net> wrote:

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

test/jdk/java/util/IdentityHashMap/DefaultRemoveReplace.java line 68:

> 66:         }
> 67:     }
> 68: }

Overall comments on this test. It does test the right set of four cases (positive and negative calls to `replace` and `remove`). However, it's **one** test that tests the four cases, instead of four tests. Using the same state makes it hard to add or maintain test cases in the future. It also trusts the return value of the method calls and doesn't make any assertions over the actual contents of the map. Without assertions over the expected contents, a method could behavior incorrectly and cause unrelated and confusing errors downstream, or even cause errors to be missed. I'd thus recommend the following:

* Convert this to a Test-NG test and use a `@BeforeTest` method to set up a test fixture consisting of a map containing the desired entries.
* Make each test case into its own test method that performs the method call and then makes assertions over the return value and expected result state of the map. Individual test methods is probably fine; no need to use a data provider for this.
* Probably add a "null hypothesis" test to ensure that the test fixture itself has the right properties, similar to the assertions at lines 38-44.
* Instead of fiddling around with strings, which have additional complexity caused by interning of string literals, I'd suggest using the technique I used in [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295) and create a `record Box(int i) { }` class. With this it's easy to get multiple instances that are != but are equals.
* After further thought, maybe additional cases are necessary. For example, tests of calls to `remove` and `replace` with a key that is equals() but != to a key in the map.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From duke at openjdk.java.net  Thu Apr 21 02:23:35 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 21 Apr 2022 02:23:35 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <EHKvY9mVle4SPjVldpEH4-esmb3iLmsXK6EC_Pbj4zU=.b92896a5-c4ba-4a8a-8ee0-9e067fc36b72@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <EHKvY9mVle4SPjVldpEH4-esmb3iLmsXK6EC_Pbj4zU=.b92896a5-c4ba-4a8a-8ee0-9e067fc36b72@github.com>
Message-ID: <eVj_LyltV6wYOb-GSoqa28jKxjGPGlp-OhX_bhhYSVI=.d9c05868-5588-4e6e-9d97-9e7ee627a391@github.com>

On Thu, 21 Apr 2022 01:01:25 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> src/java.base/share/classes/java/util/IdentityHashMap.java line 1412:
> 
>> 1410:             i = nextKeyIndex(i, len);
>> 1411:         }
>> 1412:     }
> 
> Unfortunately there's some mostly-duplicate code here. However, there's similar logic and code sprinkled throughout this class, so _more_ duplication isn't necessarily the wrong thing to do. However, trying to unify this logic results in much more intrusive refactoring, which is harder to review, and which isn't backed up with tests (see JDK-8285295) which I wouldn't encourage pursuing right now. In other words, I'm ok with this duplicate logic.

On intrusive logic: I planned address it in https://bugs.openjdk.java.net/browse/JDK-8277520 (#6532), and if this one is integrated first, it may be possible to fix it up there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From jiefu at openjdk.java.net  Thu Apr 21 03:39:24 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 21 Apr 2022 03:39:24 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <Aw2OFwv-cwPxwH9nY5VZmxtYNpTjJ6aa9GgojbfFx34=.29130123-ae2c-4f8e-81e4-74574b9b3f81@github.com>

On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

Add hotspot-compiler since the JBS has been moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Thu Apr 21 03:44:18 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 21 Apr 2022 03:44:18 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v2]
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <gUkNSaRAvKgA4xrYcfTC3VDcsmGecJYwO2JTagqT0cY=.2a52339a-0f02-4ad8-a14f-7aa8d1f1736f@github.com>

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Don't need to complexify module cache

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8281/files
  - new: https://git.openjdk.java.net/jdk/pull/8281/files/08796879..d58bb7e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Thu Apr 21 03:48:21 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Thu, 21 Apr 2022 03:48:21 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v20]
In-Reply-To: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
Message-ID: <HtzrBgqCSFojC7IBMWpx6Pt9vkLthcnyLQpSW95JtmA=.3bc61a82-9a33-4976-8019-d08e42ba1ac5@github.com>

> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
> 
> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
> 
> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4

Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision:

 - Update setSeed docs on Random class
 - Add nicer toString method to random wrapper

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7001/files
  - new: https://git.openjdk.java.net/jdk/pull/7001/files/2208f848..a7c1818c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=18-19

  Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001

PR: https://git.openjdk.java.net/jdk/pull/7001

From duke at openjdk.java.net  Thu Apr 21 03:48:21 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Thu, 21 Apr 2022 03:48:21 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19]
In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com>
Message-ID: <aAJ1B_V9_VPQqEIgjetTuZjIhTDQCjx7MOq0RVDYwhg=.f7d77d67-c1dd-4d9f-9c1e-6d6e2c289389@github.com>

On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add since in javadoc

Well after a long time away i finally got time to finish this, sorry for the delay, please review if any changes are necessary

-------------

PR: https://git.openjdk.java.net/jdk/pull/7001

From sminervini.prism at protonmail.com  Thu Apr 21 04:20:53 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Thu, 21 Apr 2022 04:20:53 +0000
Subject: Java Floating Point Points?
Message-ID: <ZcVETfoLCwycwh-C0vGSjDAm-erb-89NpbhkXaeB3fqmnxAOCQiDceu2MU72HMC2SGfShLtZiW4dekiddjjRedfTGA-VLYrxdMCdrPfhAn4=@protonmail.com>

mailto:core-libs-dev at openjdk.java.net

Andrew Haley said, and we reply:

1) Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

While I don't like re-submitting this article, certainly not on this forum,
there has always been this article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

The age of this article does not matter. It is as bearing to action in 2022
as it was then.

-Even without recombiling floating point or StrictMath code, of course it could
be changed, and compatibly. Runtime or compile time switches could be introduced.
Key words could be introduced that may apply at many different levels. Maybe
even annotations could be used for the compiler, which can already apply at
any point that floating point arithmetic and StrictMath methods and fields
may occur. Whevever there is a code space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further.

2) Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

-There could be dual mode floating point correction, implemented inside
Java at any level you could like. Dual mode couldn't be incompatible
with anything.

3) You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

> May the Java Community Process reconsider the present floating point
> operations and method calls situation, based on an imperfect
> standard and improper workaround, and provide corrected, defaulting
> or specifying-compatible waya for Java floating point arithmetic and
> Calculator class method results to always cohere in their ranges,
> without denormal and pronormal inclusion?

In a word, no. That possibility is so unlikely that it is not worthy
of consideration.

-IEEE 754 has a blind spot, an oversight error. It says nothing about
operation values that straddle the range of the arithmetic or method result,
partway in, partway out. BigInteger, BigDecimal, or the big-math library
at https://github.com/eobermuhlner/big-math are only temporary responses
that are two large in memory than needed, and too slow. The article included
as part of 3) doesn't even mention SSE, the presence of end of range
carrying additional bits.

Speed at the expense of accurary, ie. providing
a rapid falsehood, is a logic error that can compromise the entire enterprise
of computer software itself. What is required is the inclusion of SSE
additional registers and their use; just a little bit of extra registry
space to handle range end carries if they occur.

We wish to appeal to reason on this subject, if not the odds! A mechanical
clock is really amazing because it is complex, and because all the pieces whizz
around together at amazing speed, but because it maintains those earlier two
properties while maintaining accurate time. The clock loses usefulness,
and even any usefulness, if the accurate time can't be set or maintained,
at the rate it needs to operate at.

The fact that more registers are referred to, to uphold float and double, has not been
enough of a speed compromise to prevent 128 bit numbers elsewhere.
Besides, the emptiness of extra bits past the range limit of float and double
could be optimised and controlled by one flag bit.

Is there someone else involved in core-libs-dev at openjdk.java.net, or the JCP,
who can give a more particular response to this issue via the points raised here,
and engender change to the attitudes to floating point arithmetic and
floating point elementary functions, so that release versions of Java SE and
OpenJDK can include FP error correction in this Java domain?

Sergio Minervini
S.M.

Sent with [ProtonMail](https://protonmail.com/) secure email.

From jiefu at openjdk.java.net  Thu Apr 21 04:23:22 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 21 Apr 2022 04:23:22 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <QfD7xu2hGja_ind5uiq5P7B8p5ImQIQ_Mn-bM6qrVTo=.e2f541aa-ce51-406f-b3b3-5acb69cc1ffd@github.com>

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Address review comments
 - Merge branch 'master' into JDK-8284992
 - 8284992: Fix misleading Vector API doc for LSHR operator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8291/files
  - new: https://git.openjdk.java.net/jdk/pull/8291/files/50235163..1c7f4584

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=00-01

  Stats: 11427 lines in 826 files changed: 6952 ins; 1816 del; 2659 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Thu Apr 21 04:23:29 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 21 Apr 2022 04:23:29 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v2]
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <02NAjBXz9x_toVUMmYGxAF3xgkqvcDPccaSmtaH1G_E=.bf046d7d-3b06-46df-b781-e807934569a6@github.com>

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Revamp test and changes. Let ci run the tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8259/files
  - new: https://git.openjdk.java.net/jdk/pull/8259/files/9bb9ef57..dd416079

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8259&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8259&range=00-01

  Stats: 281 lines in 3 files changed: 191 ins; 88 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.java.net/jdk/pull/8259

From jiefu at openjdk.java.net  Thu Apr 21 04:28:36 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 21 Apr 2022 04:28:36 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <MUPQmersb0YhbyWhFJoVqAvCwrvnqjIzZY8OfLVn634=.8baec30e-434e-4c49-9abd-9fa5ac88ef5a@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <MUPQmersb0YhbyWhFJoVqAvCwrvnqjIzZY8OfLVn634=.8baec30e-434e-4c49-9abd-9fa5ac88ef5a@github.com>
Message-ID: <g8lBtZW59Om2xxnLww32uMLFESJtCKpJzC92hlWyQuo=.6409b325-7ee5-4ec4-b30c-2ac6db330ad8@github.com>

On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> We can raise attention to that:
> 
> ```
> /** Produce {@code a>>>(n&(ESIZE*8-1))} 
>   * (The operand and result are converted if the operand type is {@code byte} or {@code short}, see below).  Integral only.
>   * ...
>   */
> ```


It seems still misleading if we don't change the brief description of `LSHR`.
How about adding 'see details for attention' like this?
<img width="1155" alt="WeChatWorkScreenshot_96b57c88-445e-4b14-a956-35e421279744" src="https://user-images.githubusercontent.com/19923746/164371693-6e26842c-47f4-44f5-8371-1906ae8e6218.png">

And the patch had been updated.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Thu Apr 21 05:01:44 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 21 Apr 2022 05:01:44 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap [v4]
In-Reply-To: <bdqs76U2dWZMMtiF-x4vgh-gy_wC7V2M02IfgkMEy64=.4c47b0d9-13da-455a-80b4-f90ab1a01cba@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
 <bdqs76U2dWZMMtiF-x4vgh-gy_wC7V2M02IfgkMEy64=.4c47b0d9-13da-455a-80b4-f90ab1a01cba@github.com>
Message-ID: <ndQA7jAmztu_7Iltkm3YYkIef4lAq__tB8vrhvV27so=.0c64b317-4a47-4680-b60a-d2af031b6941@github.com>

On Mon, 21 Feb 2022 23:36:19 GMT, liach <duke at openjdk.java.net> wrote:

>> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.
>
> liach has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default
>  - fix whitespace

There?should probably?be something?like [test/jdk/java/util/Collections/Wrappers.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Collections/Wrappers.java) to?check?that `IdentityHashMap` overrides?all `default`?methods from?`java.util.Map` (with?`remove(K,?V)` and?`replace(K, V,?V)` depending on?<https://github.com/openjdk/jdk/pull/8259>).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6532

From alanb at openjdk.java.net  Thu Apr 21 06:05:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Apr 2022 06:05:25 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <0WGuA8aHbHgSiVW4FvbE2MkbwJXzq2niDMu4_vOivJo=.9a3f0742-e8ef-452e-a31e-83d98a88fb69@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From jpai at openjdk.java.net  Thu Apr 21 07:03:28 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 21 Apr 2022 07:03:28 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <r7zujDhxHF1GzSYk3UImBh8IQp-deVzX-ajc6XlfqpQ=.b8773f1b-40e8-40a6-9920-524550c139de@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Marked as reviewed by jpai (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From JanecekPetr at seznam.cz  Thu Apr 21 08:15:06 2022
From: JanecekPetr at seznam.cz (=?utf-8?q?Petr_Jane=C4=8Dek?=)
Date: Thu, 21 Apr 2022 10:15:06 +0200 (CEST)
Subject: =?utf-8?q?Consider_enhancing_Comparable_with_lessThan=28=29=2C_gr?=
 =?utf-8?q?eaterThan=28=29_and_friends?=
Message-ID: <E1s.1Sld.6cX{bXVA7cs.1YOHAA@seznam.cz>

Hello,
I'm pretty sure this must have come up a few times now, but
I was unable to find a discussion anywhere, so here goes:

The `if (object.compareTo(other) > 0)` construct for Comparables,
while it works, is an annoyance to readers, and I often have to
do a double-take when seeing it, to make sure it says what I think
it says.

Did we ever consider adding human-friendly default methods
to Comparable like e.g. these (names obviously subject to change):

```java
public default boolean lessThan(T other) {
    return compareTo(other) < 0;
}

public default boolean lessThanOrEqual(T other) {
    return compareTo(other) <= 0;
}

public default boolean comparesEqual(T other) {
    return compareTo(other) == 0;
}

public default boolean greaterThanOrEqual(T other) {
    return compareTo(other) >= 0;
}

public default boolean greaterThan(T other) {
    return compareTo(other) > 0;
}
```

These are pure human convenience methods to make the code easier
to read, we do not *need* them. Still, I absolutely personally
think the simplification they'd provide is worth the cost.

Are there any problems with the proposed methods that prevent them
to ever appear? Wise from the CharSequence.isEmpty() incompatibility
(https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/)
I looked at common libraries to look up potential matches, but
did not find any. The closest thing I found was AssertJ with
isGreaterThan(), and some greaterThan() methods with two or more
parameters in some obscure libraries. Now, I'm sure there *will*
be matches somewhere, and this is a risk that needs to be assessed.
Or was it simply a "meh" feature not worth the hassle?

Thank you,
PJ

P.S. I'm not a native English speaker, so the method names are
up for a potential discussion if we agree they'd make our lives
easier. I can imagine something like `comparesLessThan` or similar
variations, too.

P.P.S. The `Comparator` interface does also come into mind as it
could take similar methods, but I did not see a clear naming
pattern there. I'm open to suggestions.

From dfuchs at openjdk.java.net  Thu Apr 21 08:54:24 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 08:54:24 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <5m71u3XoiluTOAKJaN1amou2ZLzMY_T2NjZ6xygdJlU=.4cf02e2a-2c33-491c-b428-bf623921acd4@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From jlahoda at openjdk.java.net  Thu Apr 21 09:15:15 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 21 Apr 2022 09:15:15 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v6]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup, fixing tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/dc001541..76f2d05c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=04-05

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From lancea at openjdk.java.net  Thu Apr 21 10:16:39 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 21 Apr 2022 10:16:39 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
Message-ID: <VOmN284ucclRjk5f-zORDtkcopD9DBGSbJWjMKYuufY=.6943e36a-47fb-47e2-a24d-eb27b7c1577f@github.com>

On Wed, 20 Apr 2022 15:33:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284930: Also remove synchronized keyword from mark() and reset() of InputStream

Looks fine Brian.  Any thoughts as to whether a release note is warranted?

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8309

From ihse at openjdk.java.net  Thu Apr 21 10:36:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 10:36:46 GMT
Subject: RFR: 8283324: CLDRConverter run time increased by 3x
In-Reply-To: <w0GmHnHhWosUiATXdPu8wj5XEth-K3OJMutcQYV02DI=.2ba4b67d-f35a-4c80-a947-d479d2596616@github.com>
References: <w0GmHnHhWosUiATXdPu8wj5XEth-K3OJMutcQYV02DI=.2ba4b67d-f35a-4c80-a947-d479d2596616@github.com>
Message-ID: <Um7d96LmbS4Llxrjg2PkkqxrvlmOt9jSawDxjrlmCE0=.68639819-d94a-4233-b685-899a5ca8c398@github.com>

On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing performance regression caused by the fix to https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra looping through the resource map multiple times which was not necessary. The execution time of the tool now got back on par with close to JDK18.

Thanks for fixing this!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8288

From dfuchs at openjdk.java.net  Thu Apr 21 10:57:34 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 10:57:34 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <rdd4WNhICmTpUwheAex-YixgZSbjWonmMHsPTlL3g2A=.161547b1-4e23-460c-b93a-39c8258f5876@github.com>

On Wed, 20 Apr 2022 00:32:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

I also agree with Roger's suggestions.

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 73:

> 71:         public void run() {
> 72:             if (enumClnt != null) {
> 73:                 enumClnt.clearSearchReply(res, homeCtx.reqCtls);

It's a bit strange to see that there is no guard here to verify that `homeCtx != null`, when line 76 implies that it might. My reading is that `homeCtxt` is not supposed to be `null` when `enumClnt` is not `null`. That could be explained in a comment, or alternatively asserted just before line 73 (`assert homeCtx != null;`)

src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 83:

> 81:     }
> 82: 
> 83:     private CleaningAction state;

I wonder if state should be final?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From ihse at openjdk.java.net  Thu Apr 21 11:30:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 11:30:48 GMT
Subject: RFR: 8285366: Fix typos in serviceability
Message-ID: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>

I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.


I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).

The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

-------------

Commit messages:
 - Pass #2
 - Pass #1

Changes: https://git.openjdk.java.net/jdk/pull/8334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285366
  Stats: 203 lines in 137 files changed: 0 ins; 0 del; 203 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8334/head:pull/8334

PR: https://git.openjdk.java.net/jdk/pull/8334

From alanb at openjdk.java.net  Thu Apr 21 11:35:57 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Apr 2022 11:35:57 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Refresh

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/ff1ef712..5e202eca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03-04

  Stats: 1827 lines in 289 files changed: 682 ins; 377 del; 768 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu Apr 21 11:36:02 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Apr 2022 11:36:02 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <oo_Mx37iKBdjBEb6AoqJAckrHNmsG7kRGpXi8EhfsQ0=.db91f2a3-4f94-42fb-a3da-2f5038282136@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <oo_Mx37iKBdjBEb6AoqJAckrHNmsG7kRGpXi8EhfsQ0=.db91f2a3-4f94-42fb-a3da-2f5038282136@github.com>
Message-ID: <dbgTWd3AFt9yIdbYMqtfaYLbEVzFyo9OE7mIT6euId8=.1c76e482-3e09-41c8-9432-71dd059a27a5@github.com>

On Fri, 15 Apr 2022 21:31:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264:
> 
>> 262:             } finally {
>> 263:                 fence();
>> 264:                 StackChunk c = tail;
> 
> `c` is not used

Ron has done some cleanup so this is removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu Apr 21 11:35:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Apr 2022 11:35:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4]
In-Reply-To: <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com>
 <yoK8VWIymiUyxuNY69OHMSEaOn_1WLNrmzxWVDtS5xU=.32373dbd-b42f-48bd-9933-2bc7f605aa94@github.com>
Message-ID: <-G75Xv0RAXFvZt1TM0JXiQk9R5YX_SPAUennszGlXMA=.fde68d79-9d39-417c-8bec-e21ec04df70d@github.com>

On Tue, 19 Apr 2022 01:11:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/java/lang/System.java line 2173:
> 
>> 2171: 
>> 2172:         // start Finalizer and Reference Handler threads
>> 2173:         SharedSecrets.getJavaLangRefAccess().startThreads();
> 
> I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line.   Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available.  With this change, `JavaLangAccess` is already set.

Yes, that would be best, just wasn't possible before now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu Apr 21 11:36:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 21 Apr 2022 11:36:04 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <zX0QGA7avdCwhVvplTFaBYPzWb1C9KgVZ0H-VvFJanY=.8d9dde3f-e351-404f-866f-585ea3e94d8d@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <FbKKiFJlfMTc51D3eq6oc7953FvvjMPXzIOVVxxT6ho=.c131abf0-5354-476f-a453-e351ef1829f4@github.com>
 <zX0QGA7avdCwhVvplTFaBYPzWb1C9KgVZ0H-VvFJanY=.8d9dde3f-e351-404f-866f-585ea3e94d8d@github.com>
Message-ID: <NBdOQzxjpAdQituL_QY74yJlCcKlzDOJacBaBvmiNGY=.8eb71096-ef9e-4468-a7bf-2cded1fe9465@github.com>

On Sat, 16 Apr 2022 14:59:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184:
>> 
>>> 182:      * with the Thread API.
>>> 183:      */
>>> 184:     private static class RootContainer extends ThreadContainer {
>> 
>> This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based  on the system property. Something to consider later perhaps.
>
> We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From ecki at zusammenkunft.net  Thu Apr 21 11:47:26 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 21 Apr 2022 11:47:26 +0000
Subject: Zlib update
Message-ID: <AM9P193MB1142B3D88CF740E1FF809EA7FFF49@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Since the new upstream version for zlib 1.2.12 is available since 4 weeks and I don?t see them in GitHub (not even after April cpu merges) I wonder when is an update planned?

(I also noticed at least one vendor claims to have a zlib fix, I am not yet sure if this is a vendor specific thing)

If the system zlib on Linux is used, can OS updates to zlib be applied, is this compatible?

Gruss
Bernd
--
http://bernd.eckenfels.net

From duke at openjdk.java.net  Thu Apr 21 12:53:26 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 21 Apr 2022 12:53:26 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v6]
In-Reply-To: <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <APfqAZKHwb4CmwLKRZdxT0LroJ2qpSNLCJILIMrcqQU=.8aa5b38a-7946-432a-9adb-40a19b5f2ec5@github.com>
Message-ID: <oWEFE8GKiVUQf6lHxEIZe22ra6BnRbXF_UG-s7f3fks=.abfd1eaa-3952-4040-8620-2fc2dc2005a7@github.com>

On Thu, 21 Apr 2022 09:15:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup, fixing tests.

LGTM

-------------

Marked as reviewed by biboudis at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlaskey at openjdk.java.net  Thu Apr 21 13:43:35 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 21 Apr 2022 13:43:35 GMT
Subject: Integrated: JDK-8274683 Code example provided by
 RandomGeneratorFactory does not compile
In-Reply-To: <8swbD8yBpjNgfX8r-tP7qikO9okbwaxWKSCPsLCqhGE=.4aba73e0-68da-4015-8e71-87ec952a91ca@github.com>
References: <8swbD8yBpjNgfX8r-tP7qikO9okbwaxWKSCPsLCqhGE=.4aba73e0-68da-4015-8e71-87ec952a91ca@github.com>
Message-ID: <I9pJHB2x9Pywdua8eSX7Go_vKQN6gByby7ZHvcIXPBw=.6132ee64-34c1-426b-9893-7667649bef26@github.com>

On Tue, 5 Apr 2022 13:47:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> A DESCRIPTION OF THE PROBLEM : 
> In https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGeneratorFactory.html the code provided as: 
> RandomGeneratorFactory<RandomGenerator> best = RandomGeneratorFactory.all() 
>          .sorted(Comparator.comparingInt(RandomGenerator::stateBits).reversed()) 
>          .findFirst() 
>          .orElse(RandomGeneratorFactory.of("Random")); 
> does not compile.

This pull request has now been integrated.

Changeset: 4732b1d0
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4732b1d038d086aba31b7644c18e5db083277969
Stats:     7 lines in 1 file changed: 1 ins; 0 del; 6 mod

8274683: Code example provided by RandomGeneratorFactory does not compile

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8108

From jlaskey at openjdk.java.net  Thu Apr 21 13:48:27 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 21 Apr 2022 13:48:27 GMT
Subject: Integrated: JDK-8283084 RandomGenerator nextDouble(double,
 double) is documented incorrectly
In-Reply-To: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
References: <Au4eJ2E_RW5wlBJTSxjUATLlB07gfKTO1v_PvHKjEDQ=.54f27665-a451-4d8a-8c19-5e0b12c6541b@github.com>
Message-ID: <VJHRBe_t-mIWszRsIyLa3OtsODCoHDqGWyR6Eu0WZOA=.c6f5b66c-3ae6-48e7-a11c-e4c63ed3b237@github.com>

On Tue, 5 Apr 2022 14:05:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> `default float nextFloat(float origin, float bound); ` and `default double nextDouble(double origin, double bound); ` are documented incorrectly. The default method checks (origin < bound) and (bound - origin) < +infinity. 
> 
> The exception conditions are incorrect: 
> "if {@code origin} is not finite, 
>  or {@code bound} is not finite, or {@code origin} 
>  is greater than or equal to {@code bound}" 
> 
> This is not true. Calling with -Double.MAX_VALUE and Double.MAX_VALUE satisfies the documented requirements but actually throws an exception.

This pull request has now been integrated.

Changeset: 85641c65
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/85641c651d1099adcdce6ae355d8d89cfbd7e040
Stats:     18 lines in 1 file changed: 4 ins; 0 del; 14 mod

8283084: RandomGenerator nextDouble(double, double) is documented incorrectly

Reviewed-by: bpb, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8109

From dfuchs at openjdk.java.net  Thu Apr 21 14:06:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 14:06:36 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From bpb at openjdk.java.net  Thu Apr 21 15:32:41 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 21 Apr 2022 15:32:41 GMT
Subject: RFR: 8284930: Re-examine FilterInputStream mark/reset [v2]
In-Reply-To: <VOmN284ucclRjk5f-zORDtkcopD9DBGSbJWjMKYuufY=.6943e36a-47fb-47e2-a24d-eb27b7c1577f@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
 <NGcptKWbwrPBSjKBUT-hcowkbstGHk_v5LkXwgzhYLI=.07b781b7-0676-4c74-b67b-42e994a7f74d@github.com>
 <VOmN284ucclRjk5f-zORDtkcopD9DBGSbJWjMKYuufY=.6943e36a-47fb-47e2-a24d-eb27b7c1577f@github.com>
Message-ID: <-fSMGY5LQfuQmX0yI4hXkJLcVUhYAyzJXoQvcjijOmw=.a7de50a7-8f99-4232-bab6-54a07eb8a806@github.com>

On Thu, 21 Apr 2022 10:13:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Looks fine Brian. Any thoughts as to whether a release note is warranted?

Thanks, @LanceAndersen. The issue is labelled as needing a release note so you are spot on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From ihse at openjdk.java.net  Thu Apr 21 15:40:28 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 15:40:28 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
Message-ID: <R3xjAu-kYS2cCP8laV7KJ-yPSiCZdFRndiW2fXeXb7k=.263b953f-2740-40c3-937c-83c6cac62d99@github.com>

On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

@dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?

And yes, ideally the tests should be spell checked as well. It's just that:
1) the product source is (imho) more important to begin with,
2) test comments are generally of a lower quality and more likely to contain more typos (imho), meaning even more work for me to publish a PR i believe is correct, and
3) the tests in the JDK are so intertwined and messy that I'm having a hard time understanding what groups to post reviews to. I could make one mega-PR touching the entire test code base, but I doubt it would be very popular. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From duke at openjdk.java.net  Thu Apr 21 16:17:28 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 21 Apr 2022 16:17:28 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
Message-ID: <4tkizdIaAijogXwNCs7_AbmXw6JebSkoIUvsXSwyQc8=.c3f2211e-1a02-4ade-baf2-9ddfd0008cc7@github.com>

On Thu, 21 Apr 2022 00:48:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> Thanks for working on this. Yes I can review and sponsor this change.
> 
> Sorry I got a bit distracted. I started looking at the test here, and this lead me to inquire about what other tests we have for `IdentityHashMap`, and the answer is: not enough. See [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295). (But that should be handled separately.)

@stuart-marks Updated. In addition, for API docs change, should we add apiNote on object equality code, like call computeIfPresent?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From kevinw at openjdk.java.net  Thu Apr 21 16:21:26 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 21 Apr 2022 16:21:26 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

All looks good to me, just the invokable which you might want to leave as is, unless there are other strong feelings. 8-)

src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:

> 36:     jboolean pending;      /* Is an invoke requested? */
> 37:     jboolean started;      /* Is an invoke happening? */
> 38:     jboolean available;    /* Is the thread in an invocable state? */

invocable could perhaps stay as invokable ?
Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8334

From dfuchs at openjdk.java.net  Thu Apr 21 16:34:29 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Apr 2022 16:34:29 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
Message-ID: <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>

On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-)

> @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?

Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Thu Apr 21 17:25:23 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 21 Apr 2022 17:25:23 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
Message-ID: <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>

On Thu, 21 Apr 2022 16:17:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
>> 
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:
> 
>> 36:     jboolean pending;      /* Is an invoke requested? */
>> 37:     jboolean started;      /* Is an invoke happening? */
>> 38:     jboolean available;    /* Is the thread in an invocable state? */
> 
> invocable could perhaps stay as invokable ?
> Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.

But on the other hand we have `javax.script.Invocable`. :-) 

Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 

But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 

I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From kevinw at openjdk.java.net  Thu Apr 21 18:11:29 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 21 Apr 2022 18:11:29 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
 <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
Message-ID: <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>

On Thu, 21 Apr 2022 17:22:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38:
>> 
>>> 36:     jboolean pending;      /* Is an invoke requested? */
>>> 37:     jboolean started;      /* Is an invoke happening? */
>>> 38:     jboolean available;    /* Is the thread in an invocable state? */
>> 
>> invocable could perhaps stay as invokable ?
>> Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change,  and I see Internet dictionary evidence of invokable being acceptable.
>
> But on the other hand we have `javax.script.Invocable`. :-) 
> 
> Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 
> 
> But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 
> 
> I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.

Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed.  Don't lose sleep over it. 8-)

More importantly, on the tests -- I see the changes in exception messages searched for the wrong text in the test directories, and didn't find any matches that looked like checks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From hseigel at openjdk.java.net  Thu Apr 21 18:27:28 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 21 Apr 2022 18:27:28 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <EzWHM_Gzp59T3fZ12geV7gZ2PoMK1jD7c9GpEPdXihI=.cc2232a1-f951-4618-a720-7abccd1ea3e6@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

Should no changes be made to the code, instead just remove "the size is set to 0, meaning that" from the description of MaxDirectMemorySize?

-XX:MaxDirectMemorySize=size
Sets the maximum total size (in bytes) of the java.nio package, direct-buffer allocations. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, or g or G to indicate gigabytes. By default, **the size is set to 0, meaning that** the JVM chooses the size for NIO direct-buffer allocations automatically.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From cjplummer at openjdk.java.net  Thu Apr 21 20:24:29 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 21 Apr 2022 20:24:29 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com>
 <EoBxw8WGZhBJJWkHsOC6cRnC_mB95gukPslfoUr0Pmk=.b095085e-238f-4424-ba87-c940d4a229ca@github.com>
Message-ID: <ZEcDPIeEzMkagprPtPK-27vR80k4NOBWpvWOH9LAucM=.d451d890-25af-4206-8eb1-a99ef33f65cd@github.com>

On Thu, 21 Apr 2022 16:30:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run?
> 
> Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution.

I sent Magnus a PM with info on all the svc tests that can be run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From smarks at openjdk.java.net  Thu Apr 21 22:14:57 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 22:14:57 GMT
Subject: RFR: 8285386: java/util/HashMap/WhiteBoxResizeTest.java fails in tier7
 after JDK-8186958
Message-ID: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>

Adds `othervm` and `-Xmx2g` options to this test, because the default heap of 768m isn't enough.

-------------

Commit messages:
 - Add -Xmx2g to ensure JVM has enough heap.

Changes: https://git.openjdk.java.net/jdk/pull/8352/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8352&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285386
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8352/head:pull/8352

PR: https://git.openjdk.java.net/jdk/pull/8352

From smarks at openjdk.java.net  Thu Apr 21 22:19:32 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 22:19:32 GMT
Subject: RFR: 8285386: java/util/HashMap/WhiteBoxResizeTest.java fails in
 tier7 after JDK-8186958 [v2]
In-Reply-To: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>
References: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>
Message-ID: <C0LuQLCzx4I3ms8CixsRjzCp6ODG8jTQ3Pgy43f3unM=.96b0a9af-2218-40a4-99c0-de6ea8c69b52@github.com>

> Adds `othervm` and `-Xmx2g` options to this test, because the default heap of 768m isn't enough.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Add bug id.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8352/files
  - new: https://git.openjdk.java.net/jdk/pull/8352/files/2e892be4..4191e2a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8352&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8352&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8352/head:pull/8352

PR: https://git.openjdk.java.net/jdk/pull/8352

From lancea at openjdk.java.net  Thu Apr 21 22:23:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 21 Apr 2022 22:23:28 GMT
Subject: RFR: 8285386: java/util/HashMap/WhiteBoxResizeTest.java fails in
 tier7 after JDK-8186958 [v2]
In-Reply-To: <C0LuQLCzx4I3ms8CixsRjzCp6ODG8jTQ3Pgy43f3unM=.96b0a9af-2218-40a4-99c0-de6ea8c69b52@github.com>
References: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>
 <C0LuQLCzx4I3ms8CixsRjzCp6ODG8jTQ3Pgy43f3unM=.96b0a9af-2218-40a4-99c0-de6ea8c69b52@github.com>
Message-ID: <v09syPzUznTmCrU0c7YuRgynHPHmJpfKj60bNCbAdew=.f9ae66b5-08bd-432b-b41f-c7a811f67535@github.com>

On Thu, 21 Apr 2022 22:19:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Adds `othervm` and `-Xmx2g` options to this test, because the default heap of 768m isn't enough.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8352

From naoto at openjdk.java.net  Thu Apr 21 22:27:28 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 21 Apr 2022 22:27:28 GMT
Subject: Integrated: 8283324: CLDRConverter run time increased by 3x
In-Reply-To: <w0GmHnHhWosUiATXdPu8wj5XEth-K3OJMutcQYV02DI=.2ba4b67d-f35a-4c80-a947-d479d2596616@github.com>
References: <w0GmHnHhWosUiATXdPu8wj5XEth-K3OJMutcQYV02DI=.2ba4b67d-f35a-4c80-a947-d479d2596616@github.com>
Message-ID: <TrWUQa1cyqzw83woHL7CdBKVhpwOtNVQK2fZRqe33p0=.b3767627-e361-4ed3-af83-3c31aab565f6@github.com>

On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing performance regression caused by the fix to https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra looping through the resource map multiple times which was not necessary. The execution time of the tool now got back on par with close to JDK18.

This pull request has now been integrated.

Changeset: f6e9ca0c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f6e9ca0cbe671502b6b3b1d0f8fd86f0928f64ea
Stats:     16 lines in 2 files changed: 10 ins; 0 del; 6 mod

8283324: CLDRConverter run time increased by 3x

Reviewed-by: ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/8288

From smarks at openjdk.java.net  Thu Apr 21 22:32:28 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 21 Apr 2022 22:32:28 GMT
Subject: Integrated: 8285386: java/util/HashMap/WhiteBoxResizeTest.java fails
 in tier7 after JDK-8186958
In-Reply-To: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>
References: <ZxNOJ4kL6PCUMpC0oIx3tRXmizgS-6g1ttRSSmdoi_s=.e2535407-0baa-473e-929f-96ac71119286@github.com>
Message-ID: <0GDT4hftuhjEQ9SfiRXIGQeerkW1YqoY075dIcxV8os=.a6c6b44c-82a9-4c5c-b42f-2b8e647f1daf@github.com>

On Thu, 21 Apr 2022 22:08:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adds `othervm` and `-Xmx2g` options to this test, because the default heap of 768m isn't enough.

This pull request has now been integrated.

Changeset: 58155a72
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/58155a723e3ce57ee736b9e0468591e386feceee
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8285386: java/util/HashMap/WhiteBoxResizeTest.java fails in tier7 after JDK-8186958

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8352

From stuart.marks at oracle.com  Thu Apr 21 23:00:38 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 21 Apr 2022 16:00:38 -0700
Subject: need volunteer for JDK-8285405 add test and check for negative
 argument to HashMap::newHashMap et al
Message-ID: <4f3c9d55-589c-5d3b-311e-049debf270de@oracle.com>

There's a small bug tail from JDK-8186958, which added a few methods to create 
pre-sized HashMap and related instances.

* JDK-8285386 WhiteBoxResizeTest.java fails in tier7 after JDK-8186958

Some of our test configurations failed with OOME. Since they're internal systems, 
I've handled this myself.

* JDK-8285405 add test and check for negative argument to HashMap::newHashMap et al

Some internal discussions revealed this issue; the robustness of the system under 
maintenance could be improved by adding an explicit argument check to these methods 
and tests for these cases. (Probably -1 and Integer.MIN_VALUE would be sufficient.)

I'd like a volunteer to handle this. Since Xeno Amess authored the original feature, 
I nominate Xeno to do this work. :-)

Please let us know if you can pick up this work. Thanks.

s'marks

From naoto at openjdk.java.net  Thu Apr 21 23:24:05 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 21 Apr 2022 23:24:05 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset specified
 in the Javadoc
Message-ID: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>

Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

-------------

Commit messages:
 - 8283620: System.out does not use the encoding/charset specified in the Javadoc

Changes: https://git.openjdk.java.net/jdk/pull/8270/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8270&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283620
  Stats: 57 lines in 8 files changed: 24 ins; 4 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8270.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8270/head:pull/8270

PR: https://git.openjdk.java.net/jdk/pull/8270

From dholmes at openjdk.java.net  Fri Apr 22 00:25:25 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 22 Apr 2022 00:25:25 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <fYqy5xVs3A1ICdz8lIcS8fSYJB7Qand7G0PqJZ7ga0A=.fff41211-e8a4-4c35-acc1-9331ec6bac6b@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

I would delete the last sentence:

> By default, the size is set to 0, meaning that the JVM chooses the size for NIO direct-buffer allocations automatically.

and replace with:

> If not set, the flag is ignored and the JVM chooses the size for NIO direct-buffer allocations automatically.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From stuart.marks at oracle.com  Fri Apr 22 00:35:17 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 21 Apr 2022 17:35:17 -0700
Subject: Consider enhancing Comparable with lessThan(), greaterThan() and
 friends
In-Reply-To: <E1s.1Sld.6cX{bXVA7cs.1YOHAA@seznam.cz>
References: <E1s.1Sld.6cX{bXVA7cs.1YOHAA@seznam.cz>
Message-ID: <eea26295-3f14-f27d-1d82-8d64da1530ab@oracle.com>

Yes, this has been proposed before. See

     https://bugs.openjdk.java.net/browse/JDK-8241056

It's not obviously a bad idea, but there are a bunch of costs that seem to 
counterbalance the benefits.

I think the biggest problem is that adding a bunch of default methods to a 
widely-implemented interface (Comparable) runs the risk of name clashes. An 
alternative would be to add static methods with nice names, but I'm still not sure 
it's worthwhile.

Perhaps the next biggest problem is that it adds a lot of clutter to the API, and it 
doesn't add any new abstractions, it doesn't strengthen any existing abstraction, it 
doesn't increase performance of anything, etc. It arguably improves readability, but 
it also arguably could lead to confusion.

Personally I don't find `if (object.compareTo(other) > 0)` objectionable. Just move 
the comparison operator between the two operands. Then again, I'm an old C hacker 
who grew up with `if (strcmp(a, b) > 0)` which is basically the same thing, so I'm 
used to it.

(Interestingly, I looked at a bunch of Java tutorial sites, and -- setting aside 
their mistakes -- they all talked about how to *implement* Comparable, and how use 
Comparable objects for sorting, but not about how to compare the return value 
against zero to compare two objects. The javadocs don't explain this either. So 
maybe we have a documentation problem.)

Named methods and their alternatives seem to be something along the lines of:

     if (object.greaterThan(other))
     if (object.isGreaterThan(other))
     if (object.gt(other))

(Choice of names deferred to a bike shed to be had at a later time.)

This is kind of ok, until we get to Comparator, which would need the same thing. 
Instead of

     if (c.compare(a, b) > 0)

we might want

     if (c.greaterThan(a, b))
     if (c.isGreaterThan(a, b))
     if (c.gt(a, b))

Here we have to do the same mental gymnastics of moving the operator between the 
operands. This doesn't seem all that helpful to me.

There's also the difference between equals() and comparesEqual() or whatever. Worse, 
something like isNotEquals() is *not* the inverse of equals()! I think adding such 
methods could increase confusion instead of reducing it.

While the idiom of comparing the return value of compareTo() against zero is pretty 
cryptic, I think trying to solve it by adding a bunch of named methods somewhere 
potentially runs into a bunch of other problems. Maybe these can be avoided, but it 
seems like a lot of effort for not much gain. Maybe it would be more fruitful to 
find better ways to teach people about the compare-against-zero idiom.

s'marks




On 4/21/22 1:15 AM, Petr Jane?ek wrote:
> Hello,
> I'm pretty sure this must have come up a few times now, but
> I was unable to find a discussion anywhere, so here goes:
> 
> The `if (object.compareTo(other) > 0)` construct for Comparables,
> while it works, is an annoyance to readers, and I often have to
> do a double-take when seeing it, to make sure it says what I think
> it says.
> 
> Did we ever consider adding human-friendly default methods
> to Comparable like e.g. these (names obviously subject to change):
> 
> ```java
> public default boolean lessThan(T other) {
>      return compareTo(other) < 0;
> }
> 
> public default boolean lessThanOrEqual(T other) {
>      return compareTo(other) <= 0;
> }
> 
> public default boolean comparesEqual(T other) {
>      return compareTo(other) == 0;
> }
> 
> public default boolean greaterThanOrEqual(T other) {
>      return compareTo(other) >= 0;
> }
> 
> public default boolean greaterThan(T other) {
>      return compareTo(other) > 0;
> }
> ```
> 
> These are pure human convenience methods to make the code easier
> to read, we do not *need* them. Still, I absolutely personally
> think the simplification they'd provide is worth the cost.
> 
> Are there any problems with the proposed methods that prevent them
> to ever appear? Wise from the CharSequence.isEmpty() incompatibility
> (https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/)
> I looked at common libraries to look up potential matches, but
> did not find any. The closest thing I found was AssertJ with
> isGreaterThan(), and some greaterThan() methods with two or more
> parameters in some obscure libraries. Now, I'm sure there *will*
> be matches somewhere, and this is a risk that needs to be assessed.
> Or was it simply a "meh" feature not worth the hassle?
> 
> Thank you,
> PJ
> 
> P.S. I'm not a native English speaker, so the method names are
> up for a potential discussion if we agree they'd make our lives
> easier. I can imagine something like `comparesLessThan` or similar
> variations, too.
> 
> P.P.S. The `Comparator` interface does also come into mind as it
> could take similar methods, but I did not see a clear naming
> pattern there. I'm open to suggestions.
> 

From duke at openjdk.java.net  Fri Apr 22 02:41:28 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 22 Apr 2022 02:41:28 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
Message-ID: <VSnZhWUivLjjIxjOmnsN1yKEregX_WELh2Pxh7YSo6c=.ebf9897c-07fc-46e9-ac7f-c5f583fe5692@github.com>

On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

src/java.base/share/classes/java/lang/ThreadLocal.java line 179:

> 177:     private T get(Thread t) {
> 178:         ThreadLocalMap map = getMap(t);
> 179:         if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) {

Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled.

--------------------------------------------------------------------------------

This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does:

return initialValue();


--------------------------------------------------------------------------------

Suggestion:

        if (map != null) {
            if (map == ThreadLocalMap.NOT_SUPPORTED) {
                return initialValue();
            }

src/java.base/share/classes/java/lang/ThreadLocal.java line 423:

> 421:          * Construct a new map without a table.
> 422:          */
> 423:         ThreadLocalMap() {

It?might be?possible for?this to?be?`private`:
Suggestion:

        private ThreadLocalMap() {

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sminervini.prism at protonmail.com  Fri Apr 22 06:55:36 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Fri, 22 Apr 2022 06:55:36 +0000
Subject: Java Floating Points.
Message-ID: <iCORp6NCIt8s2VCks4xmemCc3JvDIim4s2gktYmU2DSEfseRE4mWeqWv_xLuUD6RM_5AxjJoTq812Gc_z2HBnydZ9IyEn-xObfEU2sRTp-Y=@protonmail.com>

mailto:core-libs-deb at openjdk.net
To core-libs, OpenJDK, JCP, and all

For the sake of the consequences of the real issues it raises,
I include the rebuttal to Andrew Haley's earlier comments,
and I reiterate that the real need is to improve the Java software
at its roots level, more so.

Andrew Haley said, and we reply:

1) Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

While I don't like re-submitting this article, certainly not on this forum,
there has always been this article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

The age of this article does not matter. It is as bearing to action in 2022
as it was then.

-Even without recombiling floating point or StrictMath code, of course it could
be changed, and compatibly. Runtime or compile time switches could be introduced.
Key words could be introduced that may apply at many different levels. Maybe
even annotations could be used for the compiler, which can already apply at
any point that floating point arithmetic and StrictMath methods and fields
may occur. Whevever there is a code space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further.

2) Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

-There could be dual mode floating point correction, implemented inside
Java at any level you could like. Dual mode couldn't be incompatible
with anything.

3) You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

> May the Java Community Process reconsider the present floating point
> operations and method calls situation, based on an imperfect
> standard and improper workaround, and provide corrected, defaulting
> or specifying-compatible waya for Java floating point arithmetic and
> Calculator class method results to always cohere in their ranges,
> without denormal and pronormal inclusion?

In a word, no. That possibility is so unlikely that it is not worthy
of consideration.

-IEEE 754 has a blind spot, an oversight error. It says nothing about
operation values that straddle the range of the arithmetic or method result,
partway in, partway out. BigInteger, BigDecimal, or the big-math library
at https://github.com/eobermuhlner/big-math are only temporary stop-gap measures
that are two large in memory, more than needed, and too slow. The article included
as part of 3) doesn't even mention SSE, the presence of end of range
carrying additional bits.

Speed at the expense of accurary, ie. providing a rapid falsehood, is also a
logic error that can compromise the entire enterprise of computer software
itself. What is required is the inclusion of SSE additional registers and their
use; just a little bit of extra registry space to handle range end carries if they occur.

We wish to appeal to reason and software needs on this subject, if not the odds!

A mechanical clock is really amazing because it is complex, and because all the pieces whizz around together at amazing speed, but because it maintains those earlier two
properties while maintaining accurate time. The clock loses usefulness,
and even any usefulness, if the accurate time can't be set or maintained,
at the rate it needs to operate at.

The fact that more registers are referred to, to uphold float and double, has not been
enough of a speed compromise to prevent 128 bit numbers elsewhere.
Besides, the emptiness of extra bits past the range limit of float and double
could be optimised and controlled by one flag bit.

When the enhancements to the switch statements came along, all previous options were
maintained, while including, even integrating, the new ones: the abbility to switch on String, and the ability to coelesce cases in any way. There ended up being no kind of ultimate problem, no matter which developers used which approach for accurate, logic correct software. Whatever approach is taken, floating point correction need be no better, and offers in-place advantages. And the present state of floating point is a logic error, with IEEE 754 on this precise point being silent, incorrect, and irrelevant.

Is there someone else involved in core-libs-dev at openjdk.java.net, or the JCP,
who can give a more particular response to this issue via the points raised here,
and engender change to the attitudes to floating point arithmetic and
floating point elementary functions, so that release versions of Java SE and
OpenJDK can include FP error correction in this Java domain?

Sergio MinerviniS.M.

Sent with [ProtonMail](https://protonmail.com/) secure email.

From xgong at openjdk.java.net  Fri Apr 22 07:08:24 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 22 Apr 2022 07:08:24 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Rename the "usePred" to "offsetInRange"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8035/files
  - new: https://git.openjdk.java.net/jdk/pull/8035/files/8f9e8a3c..9b2d2f19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=00-01

  Stats: 393 lines in 41 files changed: 0 ins; 0 del; 393 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Fri Apr 22 07:12:28 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 22 Apr 2022 07:12:28 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <Whjq4dmC2mgppNr4sCi270HLc-7yvEJnVxZKWlXJ-T0=.8e3449fa-9dc8-4bb2-aa20-1c5e1422dc32@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <fNRGaO8kqLFhu2LyZVxlocbH5kBHvOQ204gwyW2U0zQ=.605f77a3-bae7-4eb6-b654-2cd1ea8a6610@github.com>
 <Whjq4dmC2mgppNr4sCi270HLc-7yvEJnVxZKWlXJ-T0=.8e3449fa-9dc8-4bb2-aa20-1c5e1422dc32@github.com>
Message-ID: <XDtlnRh9vgFlkGwAamAcwEZPPOI-Cba84tuPDWmFiFY=.de787039-c127-4829-8f20-9bf26a8aedab@github.com>

On Wed, 20 Apr 2022 02:46:09 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861:
>> 
>>> 2859:         ByteSpecies vsp = (ByteSpecies) species;
>>> 2860:         if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) {
>>> 2861:             return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo);
>> 
>> Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow.
>
> Thanks for the review. I will change it later.

The name is updated to `offsetInRange`. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From duke at openjdk.java.net  Fri Apr 22 08:09:04 2022
From: duke at openjdk.java.net (Johnny Lim)
Date: Fri, 22 Apr 2022 08:09:04 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
Message-ID: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>

This PR fixes a typo.

-------------

Commit messages:
 - Fix typo

Changes: https://git.openjdk.java.net/jdk/pull/6942/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6942&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285440
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6942.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6942/head:pull/6942

PR: https://git.openjdk.java.net/jdk/pull/6942

From duke at openjdk.java.net  Fri Apr 22 08:09:04 2022
From: duke at openjdk.java.net (Johnny Lim)
Date: Fri, 22 Apr 2022 08:09:04 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <-KrKiLROWuCr86sK1tO0IFhR79erSs_XBjaGkYLtmTg=.579702c8-a362-4424-9fb6-b9fa730b8890@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

@bridgekeeper I was waiting for "oca-verify", so I'm a bit confused. Please let me know if there's anything I need to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From jwaters at openjdk.java.net  Fri Apr 22 08:09:05 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 22 Apr 2022 08:09:05 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <yrRlaiwHKp7vYA85f6nd8lpZHZKPpdYVwAEkU6FPX9c=.fdf2a3b5-a030-4ce1-9c26-6fe96257f892@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

No need to worry, all you need to do is comment to reset the timer. There's nothing much else to do besides creating a JBS issue related to the PR (You do need one for the checks to pass, unfortunately I can't help you there since I don't have access to the bug tracker)

Besides, Bridgekeeper is a bot, it can't reply to your mention :P

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From robilad at openjdk.java.net  Fri Apr 22 08:09:05 2022
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Fri, 22 Apr 2022 08:09:05 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

Hi,

please (re)submit a completed OCA at OCA.opensource.oracle.com.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From duke at openjdk.java.net  Fri Apr 22 08:09:06 2022
From: duke at openjdk.java.net (Johnny Lim)
Date: Fri, 22 Apr 2022 08:09:06 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
 <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>
Message-ID: <esVzcnvNse9z5fKF5JV_ylzFNQOTe5aawBztlttMRkw=.44654865-2cce-4b32-be4d-245ba3ece07e@github.com>

On Thu, 24 Mar 2022 20:28:59 GMT, Dalibor Topic <robilad at openjdk.org> wrote:

>> This PR fixes a typo.
>
> Hi,
> 
> please (re)submit a completed OCA at OCA.opensource.oracle.com.

@robilad Hi. Thanks for the feedback!

I submitted it again. I tried to fill it as possible as I can this time. Please let me know if there's anything missing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From jpai at openjdk.java.net  Fri Apr 22 08:09:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 22 Apr 2022 08:09:06 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <esVzcnvNse9z5fKF5JV_ylzFNQOTe5aawBztlttMRkw=.44654865-2cce-4b32-be4d-245ba3ece07e@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
 <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>
 <esVzcnvNse9z5fKF5JV_ylzFNQOTe5aawBztlttMRkw=.44654865-2cce-4b32-be4d-245ba3ece07e@github.com>
Message-ID: <a6O5WHpThRFhgr_TLQ4uWbajfMMCjvLEA436bIZwy2Y=.44f38ddb-ff4f-40c8-9259-0ee9a44d612a@github.com>

On Fri, 25 Mar 2022 00:55:00 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> please (re)submit a completed OCA at OCA.opensource.oracle.com.
>
> @robilad Hi. Thanks for the feedback!
> 
> I submitted it again. I tried to fill it as possible as I can this time. Please let me know if there's anything missing.

Hello @izeye, I've created a JBS issue for this change https://bugs.openjdk.java.net/browse/JDK-8285440. Please edit the title of this PR to "8285440: Typo in Collections.addAll method javadoc" so that it triggers the workflow of the official review process.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From duke at openjdk.java.net  Fri Apr 22 08:09:07 2022
From: duke at openjdk.java.net (Johnny Lim)
Date: Fri, 22 Apr 2022 08:09:07 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <a6O5WHpThRFhgr_TLQ4uWbajfMMCjvLEA436bIZwy2Y=.44f38ddb-ff4f-40c8-9259-0ee9a44d612a@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
 <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>
 <esVzcnvNse9z5fKF5JV_ylzFNQOTe5aawBztlttMRkw=.44654865-2cce-4b32-be4d-245ba3ece07e@github.com>
 <a6O5WHpThRFhgr_TLQ4uWbajfMMCjvLEA436bIZwy2Y=.44f38ddb-ff4f-40c8-9259-0ee9a44d612a@github.com>
Message-ID: <H9YDX_YiYim_p9VRG0XNWjDqGEVZGZdl0t0cvFe6yR0=.99ace24c-2170-4349-a0df-699e992a7e9b@github.com>

On Fri, 22 Apr 2022 07:35:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @robilad Hi. Thanks for the feedback!
>> 
>> I submitted it again. I tried to fill it as possible as I can this time. Please let me know if there's anything missing.
>
> Hello @izeye, I've created a JBS issue for this change https://bugs.openjdk.java.net/browse/JDK-8285440. Please edit the title of this PR to "8285440: Typo in Collections.addAll method javadoc" so that it triggers the workflow of the official review process.

@jaikiran Thanks! I updated the title as you guided.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From rpressler at openjdk.java.net  Fri Apr 22 08:49:46 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Fri, 22 Apr 2022 08:49:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
In-Reply-To: <yOux-w_H5UYpZMBxkZ-iKrfmeNzdgbK_nLC-18th7wQ=.24f0ce3e-9149-4c91-8cc8-a3cb254f0e58@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <hcLcWh0LkA1a490LrpmlLOqxXbggOWoeaStyea5zMoc=.c991da77-6b00-4287-80c4-a95d6c619f7b@github.com>
 <yOux-w_H5UYpZMBxkZ-iKrfmeNzdgbK_nLC-18th7wQ=.24f0ce3e-9149-4c91-8cc8-a3cb254f0e58@github.com>
Message-ID: <yJ673Sw8tg1a0rFGHxqe_cSq1huRuHfWkiMePr2JAKs=.fcb620db-65d9-46ed-934b-66b878c33cc1@github.com>

On Sun, 17 Apr 2022 04:57:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Refresh
>>  - Refresh
>>  - Merge with jdk-19+18
>>  - Refresh
>>  - Initial push
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 556:
> 
>> 554:     }
>> 555: 
>> 556:     static StackTraceElement[] of(StackTraceElement[] stackTrace) {
> 
> Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array?

It's just for convenience of use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Fri Apr 22 09:34:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 22 Apr 2022 09:34:25 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc
In-Reply-To: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
Message-ID: <aWIl77jLgGg-3jB_tnoXncK6soU5Fkmb-yn7pClytHI=.ebe4b76f-a9ac-45a4-a957-e14740915f28@github.com>

On Fri, 15 Apr 2022 20:26:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

src/java.base/share/classes/java/lang/System.java line 780:

> 778:      *     The property may be set on the command line to the value
> 779:      *     {@code UTF-8}. Setting the property to a value other than {@code UTF-8}
> 780:      *     leads to unspecified behavior.

I think the proposal to introduce two standard properties is good and is consistent with the recently introduced native.encoding. I'm not 100% sure that the sentence "The property may be set on the command line ..." is appropriate for the spec of standard properties. We got away with that for file.encoding in implNote but that isn't spec. I think we may have to replace this with something that says that the Java runtime can be started with the system property set to "UTF-8", starting it with the property set to another value clears to undefined behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From jpai at openjdk.java.net  Fri Apr 22 09:42:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 22 Apr 2022 09:42:37 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <8tonU-pcG6E98oQXbPzj6gMnAa2nyjIJ7OcFT0mbegg=.2dc50cb7-cac3-4218-b6f7-45d22adab89e@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

Thank you for contributing. The change looks fine to me. After someone with a Reviewer role approves this change, I can sponsor this for you.

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/6942

From ssahoo at openjdk.java.net  Fri Apr 22 12:23:57 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 22 Apr 2022 12:23:57 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java
Message-ID: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>

A new API to support replacing selective lines with desired content.

-------------

Commit messages:
 - 8285452: Support new API to replace a file content using FileUtils.java
 - Revert "8285452: Support new API to replace a file content in FileUtils.java"
 - 8285452: Support new API to replace a file content in FileUtils.java

Changes: https://git.openjdk.java.net/jdk/pull/8360/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285452
  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From ssahoo at openjdk.java.net  Fri Apr 22 12:36:15 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 22 Apr 2022 12:36:15 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v2]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <Ss5ac43yYzG0aKz9VVILgFuJXBFhiLlrjedI3wfptrg=.23120c83-f69c-4a1d-9214-3bddac10701a@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  Update FileUtils.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/39fa164a..0ec01e0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From dfuchs at openjdk.java.net  Fri Apr 22 13:13:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Apr 2022 13:13:37 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v2]
In-Reply-To: <Ss5ac43yYzG0aKz9VVILgFuJXBFhiLlrjedI3wfptrg=.23120c83-f69c-4a1d-9214-3bddac10701a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <Ss5ac43yYzG0aKz9VVILgFuJXBFhiLlrjedI3wfptrg=.23120c83-f69c-4a1d-9214-3bddac10701a@github.com>
Message-ID: <ZmUkQPy43QqN-lz5i2Ox1y0Ij-YO8LZzgk4SmzbHucA=.2cc5b01d-8c2c-4c16-8197-d6912a0e8aac@github.com>

On Fri, 22 Apr 2022 12:36:15 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

test/lib/jdk/test/lib/util/FileUtils.java line 381:

> 379: 
> 380:     public static void patch(Path path, int fromLine, int toLine, String to) throws IOException {
> 381:         if(fromLine < 1 || toLine < 1) {

It would be good to add a proper API doc comment, especially regarding the meaning of the parameters, and whether the line in question is included/excluded. Also RuntimeException could be replaced with IndexOutOfBoundsException.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From duke at openjdk.java.net  Fri Apr 22 14:33:56 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 22 Apr 2022 14:33:56 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double
Message-ID: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>

Add useful constants specified in IEEE 754.

-------------

Commit messages:
 - 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

Changes: https://git.openjdk.java.net/jdk/pull/8362/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8362&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285477
  Stats: 50 lines in 2 files changed: 32 ins; 14 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8362.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362

PR: https://git.openjdk.java.net/jdk/pull/8362

From duke at openjdk.java.net  Fri Apr 22 14:33:56 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 22 Apr 2022 14:33:56 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double
In-Reply-To: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
Message-ID: <s9Z21TssmYAV66R7_R70CM5_iDaTiCUHjRaXk5Phbg0=.88bcae38-541a-40ad-ba18-b8856794013d@github.com>

On Fri, 22 Apr 2022 14:26:07 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Add useful constants specified in IEEE 754.

The precision of float resp. double values, as defined by IEEE 754, is not easily derivable from the constants in the java.lang.Float resp. java.lang.Double classes. These values (24 resp. 53) are used in some places in the OpenJDK code base, where they appear as literals or even as derived literals, like 23 and 52. Hence, usages of these values are harder to find than necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8362

From ssahoo at openjdk.java.net  Fri Apr 22 14:35:14 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 22 Apr 2022 14:35:14 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  Update FileUtils.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/0ec01e0b..ef5dc31a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=01-02

  Stats: 24 lines in 1 file changed: 15 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From ssahoo at openjdk.java.net  Fri Apr 22 14:35:14 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 22 Apr 2022 14:35:14 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <U8YiJIlJN48araBcxKZZTmh-lSuvD5YiD0-BhF4RYOw=.52ddc1fa-9e2d-4332-b3a9-4741fdb2ca51@github.com>

On Fri, 22 Apr 2022 14:30:57 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

API doc added along with some changes in the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From duke at openjdk.java.net  Fri Apr 22 14:38:06 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 22 Apr 2022 14:38:06 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double [v2]
In-Reply-To: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
Message-ID: <70UGG1DzZs7S_ei2DG5hebIil5cc7RtAz-fo9g296P8=.f0c43731-5ab1-4e6d-bdb4-807342beff67@github.com>

> Add useful constants specified in IEEE 754.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8362/files
  - new: https://git.openjdk.java.net/jdk/pull/8362/files/830faf2b..80a6fe2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8362&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8362&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8362.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362

PR: https://git.openjdk.java.net/jdk/pull/8362

From ihse at openjdk.java.net  Fri Apr 22 15:16:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 22 Apr 2022 15:16:47 GMT
Subject: RFR: 8285485: Fix typos in corelibs
Message-ID: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>

I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.

I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).

The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

-------------

Commit messages:
 - Pass #2 core
 - Pass #1 core
 - Pass #2 misc
 - Pass #1 misc

Changes: https://git.openjdk.java.net/jdk/pull/8364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285485
  Stats: 215 lines in 103 files changed: 0 ins; 0 del; 215 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364

PR: https://git.openjdk.java.net/jdk/pull/8364

From dfuchs at openjdk.java.net  Fri Apr 22 16:16:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 22 Apr 2022 16:16:41 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <u0IiuEbZhfpu5RMlayIwa9byqhivMyghFYNO4kLbfeE=.2ba8a674-a79c-4272-a540-3d41ca0c82ea@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

test/lib/jdk/test/lib/util/FileUtils.java line 402:

> 400:             if (!removed.equals(froms)) {
> 401:                 throw new IOException("Removed not the same");
> 402:             }

That's a bit strange. I would suggest to return the removed lines instead, or to pass a `Consumer<String>` (or even better, a `Predicate<String>`  ?) that will accept the removed lines. You could continue to remove if the predicate returns true and throw if it returns false. It would also enable you to tell exactly which line failed the check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From darcy at openjdk.java.net  Fri Apr 22 16:41:18 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 22 Apr 2022 16:41:18 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double [v2]
In-Reply-To: <70UGG1DzZs7S_ei2DG5hebIil5cc7RtAz-fo9g296P8=.f0c43731-5ab1-4e6d-bdb4-807342beff67@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
 <70UGG1DzZs7S_ei2DG5hebIil5cc7RtAz-fo9g296P8=.f0c43731-5ab1-4e6d-bdb4-807342beff67@github.com>
Message-ID: <BglVZN4yclXMdhSsf_n46xQwWZdsh2AIryACMYEkKpc=.6c334375-ba75-409d-933c-127cf563c7ce@github.com>

On Fri, 22 Apr 2022 14:38:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add useful constants specified in IEEE 754.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

src/java.base/share/classes/java/lang/Double.java line 231:

> 229:      * @since 1.6
> 230:      */
> 231:     public static final int MAX_EXPONENT = (1 << (SIZE - PRECISION - 1)) - 1;

Please include the expected value as a comment; e.g. 

(1 << (SIZE - PRECISION - 1)) - 1; // 1023

src/java.base/share/classes/java/lang/Float.java line 128:

> 126:      * The number of bits in the significand of a {@code float} value.
> 127:      * This is the parameter N in section {@jls 4.2.3} of
> 128:      * <em>The Java Language Specification</em>.

Please use "cite" rather than "em" tags for references to the JLS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8362

From weijun at openjdk.java.net  Fri Apr 22 17:09:27 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 22 Apr 2022 17:09:27 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <u0IiuEbZhfpu5RMlayIwa9byqhivMyghFYNO4kLbfeE=.2ba8a674-a79c-4272-a540-3d41ca0c82ea@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
 <u0IiuEbZhfpu5RMlayIwa9byqhivMyghFYNO4kLbfeE=.2ba8a674-a79c-4272-a540-3d41ca0c82ea@github.com>
Message-ID: <ITx7DNDpq6KD2k9U45XEBr86Ujusg8q-gIQvmH9qXHI=.8d8062da-13c8-49af-970f-ca5eba2006b9@github.com>

On Fri, 22 Apr 2022 16:06:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update FileUtils.java
>
> test/lib/jdk/test/lib/util/FileUtils.java line 402:
> 
>> 400:             if (!removed.equals(froms)) {
>> 401:                 throw new IOException("Removed not the same");
>> 402:             }
> 
> That's a bit strange. I would suggest to return the removed lines instead, or to pass a `Consumer<String>` (or even better, a `Predicate<String>`  ?) that will accept the removed lines. You could continue to remove if the predicate returns true and throw if it returns false. It would also enable you to tell exactly which line failed the check.

I was just thinking about providing the removed lines and the added lines at the same time into the method (just like what a patch file looks like). The exception here can probably be enhanced to compare the content of `removed` with `from`. Two blocks of code (call and callback) would be needed if a consumer or predicate is used, and I don't feel it's worth doing. Here I've already trimmed the lines to make sure whitespaces do not matter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From duke at openjdk.java.net  Fri Apr 22 17:36:26 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 22 Apr 2022 17:36:26 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double [v3]
In-Reply-To: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
Message-ID: <g8tIBBse94W1qg6zUdhmbYtoFiSFidZflDzymBjMIKg=.bce8b273-0660-4ff2-9948-7a5636c7335c@github.com>

> Add useful constants specified in IEEE 754.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8362/files
  - new: https://git.openjdk.java.net/jdk/pull/8362/files/80a6fe2e..b4c1b61b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8362&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8362&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8362.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362

PR: https://git.openjdk.java.net/jdk/pull/8362

From duke at openjdk.java.net  Fri Apr 22 17:36:27 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 22 Apr 2022 17:36:27 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double [v2]
In-Reply-To: <BglVZN4yclXMdhSsf_n46xQwWZdsh2AIryACMYEkKpc=.6c334375-ba75-409d-933c-127cf563c7ce@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
 <70UGG1DzZs7S_ei2DG5hebIil5cc7RtAz-fo9g296P8=.f0c43731-5ab1-4e6d-bdb4-807342beff67@github.com>
 <BglVZN4yclXMdhSsf_n46xQwWZdsh2AIryACMYEkKpc=.6c334375-ba75-409d-933c-127cf563c7ce@github.com>
Message-ID: <gyGsWxaKMHWDR7SWeBxvS4Nv_UvT2NLxgpAKk42nG2k=.d7333634-f777-44f3-8460-08ee38b85043@github.com>

On Fri, 22 Apr 2022 16:34:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
>
> src/java.base/share/classes/java/lang/Double.java line 231:
> 
>> 229:      * @since 1.6
>> 230:      */
>> 231:     public static final int MAX_EXPONENT = (1 << (SIZE - PRECISION - 1)) - 1;
> 
> Please include the expected value as a comment; e.g. 
> 
> (1 << (SIZE - PRECISION - 1)) - 1; // 1023

Ready

> src/java.base/share/classes/java/lang/Float.java line 128:
> 
>> 126:      * The number of bits in the significand of a {@code float} value.
>> 127:      * This is the parameter N in section {@jls 4.2.3} of
>> 128:      * <em>The Java Language Specification</em>.
> 
> Please use "cite" rather than "em" tags for references to the JLS.

Ready

-------------

PR: https://git.openjdk.java.net/jdk/pull/8362

From naoto at openjdk.java.net  Fri Apr 22 18:14:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 22 Apr 2022 18:14:19 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <aWIl77jLgGg-3jB_tnoXncK6soU5Fkmb-yn7pClytHI=.ebe4b76f-a9ac-45a4-a957-e14740915f28@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <aWIl77jLgGg-3jB_tnoXncK6soU5Fkmb-yn7pClytHI=.ebe4b76f-a9ac-45a4-a957-e14740915f28@github.com>
Message-ID: <6zvq3JGAGia47_KJqSfix73TkqIbbFMsvsSrauq4WjE=.9bd9259a-8f85-4190-b3b8-4e37098432f2@github.com>

On Fri, 22 Apr 2022 09:31:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified the spec for the new system properties.
>
> src/java.base/share/classes/java/lang/System.java line 780:
> 
>> 778:      *     The property may be set on the command line to the value
>> 779:      *     {@code UTF-8}. Setting the property to a value other than {@code UTF-8}
>> 780:      *     leads to unspecified behavior.
> 
> I think the proposal to introduce two standard properties is good and is consistent with the recently introduced native.encoding. I'm not 100% sure that the sentence "The property may be set on the command line ..." is appropriate for the spec of standard properties. We got away with that for file.encoding in implNote but that isn't spec. I think we may have to replace this with something that says that the Java runtime can be started with the system property set to "UTF-8", starting it with the property set to another value clears to undefined behavior.

Thanks, Alan. Modified them as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From hseigel at openjdk.java.net  Fri Apr 22 18:14:28 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 22 Apr 2022 18:14:28 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <2ZRhAcljHZx6vY17qL64g9_XZyVz1ybKQFJat4CQa4k=.7908483b-9ec0-49f3-96e5-bbfdf7b235fa@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

Please review the updated man page change.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From hseigel at openjdk.java.net  Fri Apr 22 18:14:27 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 22 Apr 2022 18:14:27 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v2]
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <mZbXGGdF0FQR-mlbmRrWtA9uaoQYPNQWe1YgH8-r6HI=.3edbd73e-92b9-42b9-bb60-d718bfa81fbd@github.com>

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  restore source, fix man page

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8222/files
  - new: https://git.openjdk.java.net/jdk/pull/8222/files/c178c602..5fdb220a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8222&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8222&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8222.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8222/head:pull/8222

PR: https://git.openjdk.java.net/jdk/pull/8222

From naoto at openjdk.java.net  Fri Apr 22 18:14:18 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 22 Apr 2022 18:14:18 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
Message-ID: <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>

> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Modified the spec for the new system properties.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8270/files
  - new: https://git.openjdk.java.net/jdk/pull/8270/files/9ef42917..b5bcb870

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8270&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8270&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8270.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8270/head:pull/8270

PR: https://git.openjdk.java.net/jdk/pull/8270

From darcy at openjdk.java.net  Fri Apr 22 19:26:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 22 Apr 2022 19:26:30 GMT
Subject: RFR: 8285477: Add a PRECISION public static field to j.l.Float and
 j.l.Double [v3]
In-Reply-To: <g8tIBBse94W1qg6zUdhmbYtoFiSFidZflDzymBjMIKg=.bce8b273-0660-4ff2-9948-7a5636c7335c@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
 <g8tIBBse94W1qg6zUdhmbYtoFiSFidZflDzymBjMIKg=.bce8b273-0660-4ff2-9948-7a5636c7335c@github.com>
Message-ID: <VMp5KkwD06-hEnGAXhsi0ZFQzLOgQgOBCTzwDvXYmbw=.8f4a4725-357b-413b-af57-fbca27f22c7d@github.com>

On Fri, 22 Apr 2022 17:36:26 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add useful constants specified in IEEE 754.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8362

From sspitsyn at openjdk.java.net  Fri Apr 22 23:44:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 22 Apr 2022 23:44:27 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <jCPFRFJyh5d_fV1zY9l6PVhFnRpPun1YejB90ki0lM8=.2a7c19f6-0d5f-45a7-b9ec-a413b9028f08@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Hi Magnus,
Great job, thank you for doing this!
It looks good to me.
These findings are pretty interesting.
Some are funny and some seems to be typical.
Good examples of typical typos are:
 - double letter instead of single
 - single or even triple letter instead of double
 
 Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8334

From bchristi at openjdk.java.net  Sat Apr 23 00:13:28 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Sat, 23 Apr 2022 00:13:28 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: <rdd4WNhICmTpUwheAex-YixgZSbjWonmMHsPTlL3g2A=.161547b1-4e23-460c-b93a-39c8258f5876@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <rdd4WNhICmTpUwheAex-YixgZSbjWonmMHsPTlL3g2A=.161547b1-4e23-460c-b93a-39c8258f5876@github.com>
Message-ID: <jmQIfUsKkd3oe_6JUYbSmIY4ANIhB5tG1twdRQ--ckc=.c9d66a1b-eb9d-4c2e-bf79-00f0d7cb5a29@github.com>

On Wed, 20 Apr 2022 13:48:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 73:
> 
>> 71:         public void run() {
>> 72:             if (enumClnt != null) {
>> 73:                 enumClnt.clearSearchReply(res, homeCtx.reqCtls);
> 
> It's a bit strange to see that there is no guard here to verify that `homeCtx != null`, when line 76 implies that it might. My reading is that `homeCtxt` is not supposed to be `null` when `enumClnt` is not `null`. That could be explained in a comment, or alternatively asserted just before line 73 (`assert homeCtx != null;`)

Yes, it is strange -- that code came from the finalizer. I will add an assert.

> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     private CleaningAction state;
> 
> I wonder if state should be final?

Makes sense to me. `cleanable` can be final, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From bchristi at openjdk.java.net  Sat Apr 23 00:27:22 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Sat, 23 Apr 2022 00:27:22 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v2]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <yr4RsgnBsFE4-tuj3kW60824KiFYwe19MH-yuBBu8MY=.3e78444b-1ec0-43d7-86e6-35cd34ce3b24@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/3c957b51..1df8515b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=00-01

  Stats: 30 lines in 1 file changed: 1 ins; 0 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From bpb at openjdk.java.net  Sat Apr 23 01:20:02 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Sat, 23 Apr 2022 01:20:02 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
Message-ID: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>

Change the default value of the `jdk.io.File.enableADS` property to `true`.

-------------

Commit messages:
 - 8285445: cannot open file "NUL:"

Changes: https://git.openjdk.java.net/jdk/pull/8373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8373&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285445
  Stats: 57 lines in 2 files changed: 52 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8373/head:pull/8373

PR: https://git.openjdk.java.net/jdk/pull/8373

From mikael at openjdk.java.net  Sat Apr 23 01:23:19 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 23 Apr 2022 01:23:19 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
Message-ID: <3-LfIaGuCPjcQH--kaRTtBXeo7SGNe7Xl8wX-Drr9N0=.419c4653-bb33-445b-97a8-64d498d9b0a6@github.com>

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change the default value of the `jdk.io.File.enableADS` property to `true`.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From ecki at zusammenkunft.net  Sat Apr 23 01:58:39 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 23 Apr 2022 01:58:39 +0000
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
Message-ID: <AM9P193MB114275C9A18CE329D7352499FFF69@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Is that really a needed fix?  enabling ADS and less strict parsing might introduce vulnerability but on the other hand NUL: should be allowed for it is a drive style not a ADS.

I would also think the number of users who want use NUL: is smaller than the number of users who benefit from ADS being forbidden. Especially since \\.\NUL or NUL should already work.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Brian Burkhalter <bpb at openjdk.java.net>
Gesendet: Saturday, April 23, 2022 3:20:02 AM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Betreff: RFR: 8285445: cannot open file "NUL:"

Change the default value of the `jdk.io.File.enableADS` property to `true`.

-------------

Commit messages:
 - 8285445: cannot open file "NUL:"

Changes: https://git.openjdk.java.net/jdk/pull/8373/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8373&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285445
  Stats: 57 lines in 2 files changed: 52 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8373/head:pull/8373

PR: https://git.openjdk.java.net/jdk/pull/8373

From dholmes at openjdk.java.net  Sat Apr 23 05:46:25 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 23 Apr 2022 05:46:25 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v2]
In-Reply-To: <mZbXGGdF0FQR-mlbmRrWtA9uaoQYPNQWe1YgH8-r6HI=.3edbd73e-92b9-42b9-bb60-d718bfa81fbd@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
 <mZbXGGdF0FQR-mlbmRrWtA9uaoQYPNQWe1YgH8-r6HI=.3edbd73e-92b9-42b9-bb60-d718bfa81fbd@github.com>
Message-ID: <khK_PrAzf5CUOYnpqUysYog66BvDHoZJNuvY9ekfLSU=.c7e71ef8-0134-4e2e-a4f0-710e4d0a91e5@github.com>

On Fri, 22 Apr 2022 18:14:27 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore source, fix man page

I didn't realize that text was from the manpage. It is fine but I think we also need something in globals.hpp:


 product(uint64_t, MaxDirectMemorySize, 0,                                 \
          "Maximum total size of NIO direct-buffer allocations. "        \
          "Ignored if not explicitly set.")
          range(0, max_jlong)                                               \

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From dholmes at openjdk.java.net  Sat Apr 23 05:58:26 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 23 Apr 2022 05:58:26 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>
Message-ID: <LYaz0ymec53OaTXhHNrYPrioeSyh6Viun5llmsGjAaQ=.bc2f1807-dbe9-423a-a334-1f36f4832531@github.com>

On Fri, 22 Apr 2022 18:14:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the spec for the new system properties.

src/java.base/share/classes/java/lang/System.java line 774:

> 772:      *     <td>Character encoding name for {@link System#out System.out}.
> 773:      *     The Java runtime can be started with the system property set to {@code UTF-8},
> 774:      *     starting it with the property set to another value clears to undefined behavior.

_leads_ to undefined behavior

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From dholmes at openjdk.java.net  Sat Apr 23 05:58:26 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 23 Apr 2022 05:58:26 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <6zvq3JGAGia47_KJqSfix73TkqIbbFMsvsSrauq4WjE=.9bd9259a-8f85-4190-b3b8-4e37098432f2@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <aWIl77jLgGg-3jB_tnoXncK6soU5Fkmb-yn7pClytHI=.ebe4b76f-a9ac-45a4-a957-e14740915f28@github.com>
 <6zvq3JGAGia47_KJqSfix73TkqIbbFMsvsSrauq4WjE=.9bd9259a-8f85-4190-b3b8-4e37098432f2@github.com>
Message-ID: <B7cyCNzdBNhM9YgxfNrNd2yn5BHydsQu3YLtQUMzt2k=.857fca5a-4dc2-4f8d-8e1a-3ed1e4e7c3be@github.com>

On Fri, 22 Apr 2022 18:10:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 780:
>> 
>>> 778:      *     The property may be set on the command line to the value
>>> 779:      *     {@code UTF-8}. Setting the property to a value other than {@code UTF-8}
>>> 780:      *     leads to unspecified behavior.
>> 
>> I think the proposal to introduce two standard properties is good and is consistent with the recently introduced native.encoding. I'm not 100% sure that the sentence "The property may be set on the command line ..." is appropriate for the spec of standard properties. We got away with that for file.encoding in implNote but that isn't spec. I think we may have to replace this with something that says that the Java runtime can be started with the system property set to "UTF-8", starting it with the property set to another value clears to undefined behavior.
>
> Thanks, Alan. Modified them as suggested.

I think Alan has a typo: "clears" -> "leads"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From dholmes at openjdk.java.net  Sat Apr 23 06:12:29 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 23 Apr 2022 06:12:29 GMT
Subject: RFR: 8285366: Fix typos in serviceability
In-Reply-To: <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
 <qWssE0yWozCIm3dC8R-jRj6wzC-9wSNBKxPddBWQqPQ=.6946be24-6b22-4ed1-80a8-9f0a57c35f64@github.com>
 <E3cvDYPFpkc9jORIcxO6REaQJ6NLBVRJXYDHekKwf1Y=.5d039bab-f1e5-4959-b63c-1b5143b92184@github.com>
 <xvcZ6swFp4vBB2HF9szyj4a_J0gELEFEh8Od2DSbrKg=.5332082e-c511-4468-8a23-e380877069a8@github.com>
Message-ID: <i8HhcmdDFktsEGg93rAGBehfsoKxWAXjZpF1Rj-pVc8=.782315bc-a31a-4367-9435-1f1c14793b94@github.com>

On Thu, 21 Apr 2022 18:08:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> But on the other hand we have `javax.script.Invocable`. :-) 
>> 
>> Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". 
>> 
>> But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". 
>> 
>> I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes.
>
> Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed.  Don't lose sleep over it. 8-)
> 
> More importantly, on the tests -- I saw the changes in exception messages, searched for the wrong text in the test directories, and didn't find any matches that looked like checks.

Invocable, Invokable and Invokeable are all used in practice. We have a mix of invocable and invokable throughout our codebase, with more of the former than the latter - and in prose "invocable" is probably best.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8334

From sminervini.prism at protonmail.com  Sat Apr 23 06:29:56 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Sat, 23 Apr 2022 06:29:56 +0000
Subject: Compatible Updating of Java SE, OpenJDK floating Point?
Message-ID: <mf_elmVTQhTCWwbAKhkXzIJ4DM5nBpwWua0_mkWIYB7aalyruH8rLi-nnhi5tcRdQ2ZSBl7SBA0OHb6FASuRm-uZfvXm-1pubpKpv60miH0=@protonmail.com>

To Oracle, OpenJDK and the Java Community Process,

use of the floating point arithmetic formula

(-1)^s ? m ? 2^(e - 127)

for both float and double, while adhering to IEEE 754 statements, and nothing else,
means that there is an accuracy degredation that does occur in the position of the right
most decimal digit. The 754 standard does nothing to exactly address this degredation.

This occurs in float and double data and variables, from direct source code, and indirect pre-compiled code that has been compiled already, but can't be altered. By means of arithmetic operators, and StrictMath method calls.

It has gotten to the point where the accuracy workarounds using BigInteger, BigDecimal,
or the big-math library for an accurate type calculator class, is all both all too slow and too large in memory, where they really can be avoided, which is for most cases.

32 and 64 bit registers for float and double, nowadays, have additional "SSE" bits, which means thata small amount more writing and consideration can be done so that degredation happens entirely outside the present ranges for float and double, which are:

float: 4 bytes, IEEE 754. Covers a range from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).

double: 8 bytes IEEE 754. Covers a range from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

In order to correct the digit accuracy degredation phenomenon, either the default mode should be changed, since there is no coherent way to need or rely on an innaccurate final decimal digit, or a compatability mode should be brought in so that either mode of floating point type arithmetic or StrictMath method call can be used, both for original code and re-used library code.

Even without recompiling, of course floating point errors can be changed, and compatibly. Runtime or better, compile time switches can be introduced. Key words could be introduced that may apply at many different levels, for compiled code or source code. Method calls to a new overhead Factory type class would be an approach. Maybe even annotations could be used for the compiler, which can already apply at any point that floating point arithmetic and StrictMath methods and fields may occur, if such an approach doesn't include too many inneficiencies. There might be ways to acheive this be either appending to how Java compiles, or not.

Whevever there is a code instance in a space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further. Data in variables or
same type objects can always be re-read, and changed.

Something similar did take place when the new version of the Java switch statement came in. It allowed String to be immediately switched on. Instead of just end result coelesce, it also allows for cases to be coelesced, with a new operator, the -> operator. There was no split in Java, and programmers using either approach within logical bounds has never lead to any problem. The same is a parallel and true for enhancement of Floating Point use.

SSE and similar post registry bits seem to be the key to such. Is it possible for the OpenJDK to actively apply floating point arithmetic and StrictMath method result correction to its release versions of its JDK and JRE?

From duke at openjdk.java.net  Sat Apr 23 12:38:27 2022
From: duke at openjdk.java.net (David M. Lloyd)
Date: Sat, 23 Apr 2022 12:38:27 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
Message-ID: <7o0mtJTdRLuSxHAVpek4wSvdkdcva84bwb87eq3S6Dg=.ae5b86c2-903d-46f2-bad4-3eb3790b93d3@github.com>

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change the default value of the `jdk.io.File.enableADS` property to `true`.

FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From alanb at openjdk.java.net  Sat Apr 23 15:27:19 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Apr 2022 15:27:19 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <7o0mtJTdRLuSxHAVpek4wSvdkdcva84bwb87eq3S6Dg=.ae5b86c2-903d-46f2-bad4-3eb3790b93d3@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
 <7o0mtJTdRLuSxHAVpek4wSvdkdcva84bwb87eq3S6Dg=.ae5b86c2-903d-46f2-bad4-3eb3790b93d3@github.com>
Message-ID: <lNm6Xm8Dlm0C9vMgDZ0KDY0Ra6qQMJwho4FIin5z2oM=.42419515-f3cf-4a7b-9557-6f66ed85486c@github.com>

On Sat, 23 Apr 2022 12:35:24 GMT, David M. Lloyd <duke at openjdk.java.net> wrote:

> FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`.

Hopefully newer code can use OutputStream.nullOutputStream(). It's portable and avoids depending on these legacy Windows specific reserved names.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From bpb at openjdk.java.net  Sat Apr 23 15:35:19 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Sat, 23 Apr 2022 15:35:19 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
Message-ID: <ETI_nraTcMWSMxvuABba6xWn48tp1upUId7XmQr_NcQ=.0b5f095c-a6ca-42c8-9c96-1930b7235fee@github.com>

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change the default value of the `jdk.io.File.enableADS` property to `true`.

This topic will be examined further under JDK-8285511.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From bpb at openjdk.java.net  Sat Apr 23 15:54:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Sat, 23 Apr 2022 15:54:35 GMT
Subject: Integrated: 8285445: cannot open file "NUL:"
In-Reply-To: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
Message-ID: <_i1QicSU7NK3yFwxcZxtrCvJ9XiuE3ImZ_ueWuWqL8Y=.923eb19a-0377-4521-ba74-84bf8b28cd4c@github.com>

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change the default value of the `jdk.io.File.enableADS` property to `true`.

This pull request has now been integrated.

Changeset: 03cbb48e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03cbb48e6a1d806f204a39bbdbb4bc9be9e57a41
Stats:     57 lines in 2 files changed: 52 ins; 1 del; 4 mod

8285445: cannot open file "NUL:"

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From aturbanov at openjdk.java.net  Sun Apr 24 09:23:58 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 24 Apr 2022 09:23:58 GMT
Subject: RFR: 8285519: Simplify TimeUnit.convert calls
Message-ID: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>

TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
Compared via JMH benchmark: 150ns -> 125ns/op
<details>
<summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>


@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class TimeUnitBench {

    static final int SIZE = TimeUnit.values().length * 10;

    @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
    int bias;

    TimeUnit[] mod;

    @Setup
    public void setup() {
        mod = new TimeUnit[SIZE];

        TimeUnit[] vals = TimeUnit.values();
        for (int c = 0; c < SIZE; c++) {
            if (bias == -1) {
                // megamorphic
                mod[c] = vals[c % vals.length];
            } else {
                mod[c] = vals[bias];
            }
        }

        Random r = new Random();
        for (int c = 0; c < 10000; c++) {
            int i = r.nextInt();
            for (int o = 0; o < vals.length; o++) {
                if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
                    throw new IllegalStateException("switch " + o);
            }
        }
    }

    @Benchmark
    public void const_convert(Blackhole bh) {
        for (TimeUnit tu : mod) {
            bh.consume(do_convert(tu));
        }
    }

    @Benchmark
    public void value_convert(Blackhole bh) {
        for (TimeUnit tu : mod) {
            bh.consume(do_convert(tu, 1L));
        }
    }

    @Benchmark
    public void const_toNanos(Blackhole bh) {
        for (TimeUnit tu : mod) {
            bh.consume(do_toNanos(tu));
        }
    }

    @Benchmark
    public void value_toNanos(Blackhole bh) {
        for (TimeUnit tu : mod) {
            bh.consume(do_toNanos(tu, 1L));
        }
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private long do_toNanos(TimeUnit tu) {
        return tu.toNanos(1L);
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private long do_toNanos(TimeUnit tu, long value) {
        return tu.toNanos(value);
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private long do_convert(TimeUnit tu) {
        return TimeUnit.NANOSECONDS.convert(1L, tu);
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private long do_convert(TimeUnit tu, long value) {
        return TimeUnit.NANOSECONDS.convert(value, tu);
    }
}

Results:

Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op


</details>

-------------

Commit messages:
 - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

Changes: https://git.openjdk.java.net/jdk/pull/8376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8376&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285519
  Stats: 30 lines in 7 files changed: 2 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8376/head:pull/8376

PR: https://git.openjdk.java.net/jdk/pull/8376

From itakiguchi at openjdk.java.net  Sun Apr 24 09:26:41 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 24 Apr 2022 09:26:41 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if environment
 variable has non ASCII character
Message-ID: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>

On JDK19 with Linux ja_JP.eucjp locale,
System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
It seems this issue happens because of JEP 400.
Arguments for ProcessBuilder have same kind of issue.

-------------

Commit messages:
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

Changes: https://git.openjdk.java.net/jdk/pull/8378/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285517
  Stats: 188 lines in 4 files changed: 180 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Mon Apr 25 03:12:29 2022
From: duke at openjdk.java.net (kristylee88)
Date: Mon, 25 Apr 2022 03:12:29 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <LTmmN4U-eVPdbQ0xFIDjLcHcEB2OQk61Z9G5QUiPTu4=.53d62835-f8c4-4dde-82f3-9d32b5faa085@github.com>

On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From serb at openjdk.java.net  Mon Apr 25 04:55:24 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 04:55:24 GMT
Subject: RFR: 8285523: The test for JDK-8285445 can be improved
Message-ID: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>

The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix.

An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be [accepted](https://github.com/openjdk/jdk/blob/9d9f4e502f6ddc3116ed9b80f7168a1edfce839e/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L59).

-------------

Commit messages:
 - Initial version of 8285523

Changes: https://git.openjdk.java.net/jdk/pull/8379/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8379&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285523
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8379.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8379/head:pull/8379

PR: https://git.openjdk.java.net/jdk/pull/8379

From alanb at openjdk.java.net  Mon Apr 25 11:33:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 11:33:30 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <B7cyCNzdBNhM9YgxfNrNd2yn5BHydsQu3YLtQUMzt2k=.857fca5a-4dc2-4f8d-8e1a-3ed1e4e7c3be@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <aWIl77jLgGg-3jB_tnoXncK6soU5Fkmb-yn7pClytHI=.ebe4b76f-a9ac-45a4-a957-e14740915f28@github.com>
 <6zvq3JGAGia47_KJqSfix73TkqIbbFMsvsSrauq4WjE=.9bd9259a-8f85-4190-b3b8-4e37098432f2@github.com>
 <B7cyCNzdBNhM9YgxfNrNd2yn5BHydsQu3YLtQUMzt2k=.857fca5a-4dc2-4f8d-8e1a-3ed1e4e7c3be@github.com>
Message-ID: <TFeIUQI7QEZg3IcYu06bkNnJsOT7lEy4XJ-jCArYiSo=.7ea1916f-561e-4195-98c7-ffd353415398@github.com>

On Sat, 23 Apr 2022 05:55:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think Alan has a typo: "clears" -> "leads"

Apologies, there was a typo in my comment on the PR. I didn't mean for the word "clears" to go into the spec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From alanb at openjdk.java.net  Mon Apr 25 11:39:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 11:39:21 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>
Message-ID: <jwa8UgbCGv-94zlHPGrVDcmAVjtz_PBoNqG9edf4ZgA=.35542e32-e9ea-4703-9abf-c1bb7676bf90@github.com>

On Fri, 22 Apr 2022 18:14:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the spec for the new system properties.

Overall I think this looks good, assuming the typo in the spec ("clears" -> "leads") is fixed.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8270

From remi.catherinot at orange.com  Mon Apr 25 13:08:49 2022
From: remi.catherinot at orange.com (remi.catherinot at orange.com)
Date: Mon, 25 Apr 2022 13:08:49 +0000
Subject: System.exit deadlock if called within a hook
Message-ID: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>

Hi,

Exemple code to deadlock the JVM. Only Runtime.halt from within the JVM or a SIGKILL from outside stops it. Normal kills and Ctrl-C (which is a SIGTERM) fail to do so.

public class ExitInHookDemo {
            public static void main(String...args) {
                        Runtime.getRuntime().addShutdownHook(new Thread("hook") {
                                    public void run() { System.exit(1); }
});
            }
}

I've tried to more or less do a pure java patch in java.lang.Shutdown but the only way to have a real patch would be to have Thread.destroy still there and implemented or anything allowing Shutdown to destroy a thread. In essence, System.exit is a no return method call. So using Thread.stop which raise a ThreadDeath error is not enough (the method go back to the caller with the error). Only Thread.destroy has the contract of being a no return call. Yes the documentation said it is unsafe because it does not release locks & co, but right now that is exactly what is happening, so Thread.destroy limitations are acceptable. Throwing something that is not catchable, something legit to throw but not legit to catch, even by a catch Throwable, is not enough because it would still run finally blocks, which cannot happen for no return methods like System.exit and Runtime.halt: try { System.exit(0); /* code that should never be reached */ } catch (Throwable t) { /* code that should never be reached */ } finally { /* code that should also never be reached */ }

I've searched the known/documented bugs but I either missed the fact it was already reported, or I only got entries about removing Thread.destroy.

By the way, I'm not really asking to have Thread.destroy implemented were it is currently defined (a public method inside Thread). I mean at least java.lang.Shutdown should have a way to destroy Threads, even a private one. Threads destroyed that way should make threads stuck joining the destroyed one must be released.

I got the bug on java 1.8, oracle and openjdk ones. Not tested it one >=9 ones.

Here is what the approximation of a patch using pure java, but I'm no jdk expert and had no access to thread destruction, so it is not perfect. The code is from java.lang.Shutdown
    static void exit(int status) {
        boolean wasRunning = false; // < - - new var
        boolean runMoreFinalizers = false;
        synchronized (lock) {
            switch (state) {
            case RUNNING:       /* Initiate shutdown */
                state = HOOKS;
                wasRunning = true; // < - - first call to System.exit, the caller will run all of what is needed -hooks, maybe finalizers, etc.
                if (status != 0) runFinalizersOnExit = false; // < - - also moved the runFinalizersOnExit block to avoid having it changed/altered by several threads trying to exit with different status code
                break;
            case HOOKS:         /* Stall and halt */
                break;
            case FINALIZERS:
                if (status != 0) {
                    /* Halt immediately on nonzero status */
                    halt(status);
                } else {
                    /* Compatibility with old behavior:
                     * Run more finalizers and then halt
                     */
                    runMoreFinalizers = runFinalizersOnExit;
                }
                break;
            }
        }
        if (!wasRunning) Thread.currentThread().stop(); // < - - should be a destroy rather than a stop. This thread is not the 1st who called System.exit, and since it should never return, it must die asap. We are outside of the synchronized block so if any lock remains acquired by this thread, they are acquired by the caller which should have released them before calling exit on the 1st place. If the caller called us while having locks, it is a caller bug, not a Shutdown.exit one. Current implementation since it never returns (and yield the stuck bug I report) also never release any of the locks it has too
        // < - - beyond this line nothing has been modified
        if (runMoreFinalizers) {
            runAllFinalizers();
            halt(status);
        }
        synchronized (Shutdown.class) {
            /* Synchronize on the class object, causing any other thread
             * that attempts to initiate shutdown to stall indefinitely
             */
            sequence();
            halt(status);
        }
    }


Regards,
Ogrom.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


From alanb at openjdk.java.net  Mon Apr 25 13:14:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 13:14:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
In-Reply-To: <VSnZhWUivLjjIxjOmnsN1yKEregX_WELh2Pxh7YSo6c=.ebf9897c-07fc-46e9-ac7f-c5f583fe5692@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
 <VSnZhWUivLjjIxjOmnsN1yKEregX_WELh2Pxh7YSo6c=.ebf9897c-07fc-46e9-ac7f-c5f583fe5692@github.com>
Message-ID: <zVccMLDHbCm6XWdB_yjecU-CuM7XKMsE8lrUzOjUyRU=.cb8db938-8ee6-4f9a-a2ec-5f69227d24bc@github.com>

On Fri, 22 Apr 2022 02:26:50 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 179:
> 
>> 177:     private T get(Thread t) {
>> 178:         ThreadLocalMap map = getMap(t);
>> 179:         if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) {
> 
> Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled.
> 
> --------------------------------------------------------------------------------
> 
> This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does:
> 
> return initialValue();
> 
> 
> --------------------------------------------------------------------------------
> 
> Suggestion:
> 
>         if (map != null) {
>             if (map == ThreadLocalMap.NOT_SUPPORTED) {
>                 return initialValue();
>             }

It's benign but what you suggest may be clearer - thanks!

> src/java.base/share/classes/java/lang/ThreadLocal.java line 423:
> 
>> 421:          * Construct a new map without a table.
>> 422:          */
>> 423:         ThreadLocalMap() {
> 
> It?might be?possible for?this to?be?`private`:
> Suggestion:
> 
>         private ThreadLocalMap() {

Yes, this can be private.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon Apr 25 13:14:52 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 13:14:52 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
In-Reply-To: <a70SeaAKRSbibMp2-CSoHf1vNGAHc3b1ZQgS6xBOaVA=.f9e587c4-f01e-47f4-bc6b-0357a21b57a8@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com>
 <a70SeaAKRSbibMp2-CSoHf1vNGAHc3b1ZQgS6xBOaVA=.f9e587c4-f01e-47f4-bc6b-0357a21b57a8@github.com>
Message-ID: <v1zt31fudJ3J2s6m8-VSDjOmCMy4ctdMAT9zF8cdSDQ=.aee8c968-4cdb-49be-8573-fe31f43f241a@github.com>

On Fri, 15 Apr 2022 21:24:58 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115:
> 
>> 113:     }
>> 114: 
>> 115:     private Runnable target;
> 
> Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class)

Yes, it can.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon Apr 25 13:19:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 13:19:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <MJltutSoIIIZdUF3liaW9-uFMjvfPdHR0d73YDhsveY=.f3ca196f-bc54-41e2-be49-6f1dd6ea16f8@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - Refresh
 - Refresh
 - Merge with jdk-19+18
 - Refresh
 - Initial push

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05
  Stats: 104157 lines in 1144 files changed: 94155 ins; 4291 del; 5711 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Mon Apr 25 13:32:49 2022
From: duke at openjdk.java.net (David M. Lloyd)
Date: Mon, 25 Apr 2022 13:32:49 GMT
Subject: RFR: 8285445: cannot open file "NUL:"
In-Reply-To: <lNm6Xm8Dlm0C9vMgDZ0KDY0Ra6qQMJwho4FIin5z2oM=.42419515-f3cf-4a7b-9557-6f66ed85486c@github.com>
References: <-C-DaObT5qTLW_EEpwRHMaSMMmA7JAy8CVgWSgS2PFM=.3e5dc93a-586f-4875-8e6c-7cc3b2bb9c1d@github.com>
 <7o0mtJTdRLuSxHAVpek4wSvdkdcva84bwb87eq3S6Dg=.ae5b86c2-903d-46f2-bad4-3eb3790b93d3@github.com>
 <lNm6Xm8Dlm0C9vMgDZ0KDY0Ra6qQMJwho4FIin5z2oM=.42419515-f3cf-4a7b-9557-6f66ed85486c@github.com>
Message-ID: <dSxN5SB0lzyuqWXXn_AcOJoT16OQ7DMjwwd467cJ42E=.442822ed-31d1-4683-9aeb-bc7cc634551d@github.com>

On Sat, 23 Apr 2022 15:24:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`.
> 
> Hopefully newer code can use OutputStream.nullOutputStream(). It's portable and avoids depending on these legacy Windows specific reserved names.

One possible advantage of having a "real" OS-supported `null` stream (in addition to its uses by the process subsystem) is that it could be used to efficiently drain bytes from things like sockets and pipes using transfer methods, assuming adequate JDK support. On Linux at least, the `splice` syscall is able to move bytes between socket and pipe buffers and into file buffers without copying them into user space. For `/dev/null` this means the bytes are discarded on the kernel side.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8373

From dfuchs at openjdk.java.net  Mon Apr 25 13:35:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 25 Apr 2022 13:35:56 GMT
Subject: RFR: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper
Message-ID: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>

Hi,

Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual thread.
The issue has nothing to do with virtual thread, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created.

best regards,

-- daniel

-------------

Commit messages:
 - 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper

Changes: https://git.openjdk.java.net/jdk/pull/8382/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8382&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284779
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8382.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8382/head:pull/8382

PR: https://git.openjdk.java.net/jdk/pull/8382

From david.lloyd at redhat.com  Mon Apr 25 13:41:23 2022
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 25 Apr 2022 08:41:23 -0500
Subject: System.exit deadlock if called within a hook
In-Reply-To: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
References: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
Message-ID: <CANghgrRUw-qabE5kM=Jq8Z0RSXXFAZXpy6X+WfVtkxPRLJ_0UQ@mail.gmail.com>

On Mon, Apr 25, 2022 at 8:09 AM <remi.catherinot at orange.com> wrote:
> because it would still run finally blocks, which cannot happen for no return methods like System.exit and Runtime.halt

FWIW I don't think this is correct. `exit` and `halt` etc. cannot
*return* but they're definitely allowed to throw an exception
(`SecurityException` is presently specified) and thus are allowed to
unwind the stack, even through `finally` blocks.

-- 
- DML ? he/him


From dfuchs at openjdk.java.net  Mon Apr 25 13:56:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 25 Apr 2022 13:56:04 GMT
Subject: RFR: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper [v2]
In-Reply-To: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
References: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
Message-ID: <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>

> Hi,
> 
> Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual threads.
> The issue has nothing to do with virtual threads, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created.
> 
> best regards,
> 
> -- daniel

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year again

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8382/files
  - new: https://git.openjdk.java.net/jdk/pull/8382/files/0e7d60cb..191fa7ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8382&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8382&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8382.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8382/head:pull/8382

PR: https://git.openjdk.java.net/jdk/pull/8382

From alanb at openjdk.java.net  Mon Apr 25 13:56:04 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 13:56:04 GMT
Subject: RFR: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper [v2]
In-Reply-To: <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>
References: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
 <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>
Message-ID: <c5tf3Yox2Z5ZBd7MjEM14m_ji_hNZb99TxFZ243atk0=.6f9c246e-1a15-4914-928d-9cde78570177@github.com>

On Mon, 25 Apr 2022 13:52:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual threads.
>> The issue has nothing to do with virtual threads, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created.
>> 
>> best regards,
>> 
>> -- daniel
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year again

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java line 3:

> 1: /*
> 2:  * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

I think you meant 2022 :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8382

From dfuchs at openjdk.java.net  Mon Apr 25 13:56:05 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 25 Apr 2022 13:56:05 GMT
Subject: RFR: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper [v2]
In-Reply-To: <c5tf3Yox2Z5ZBd7MjEM14m_ji_hNZb99TxFZ243atk0=.6f9c246e-1a15-4914-928d-9cde78570177@github.com>
References: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
 <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>
 <c5tf3Yox2Z5ZBd7MjEM14m_ji_hNZb99TxFZ243atk0=.6f9c246e-1a15-4914-928d-9cde78570177@github.com>
Message-ID: <2e7_0LGEzaPLsX3hvJ5_jbp9aDjkv_8VOt8MqYsD18s=.f443b94b-a61f-452e-90b2-917f07492ace@github.com>

On Mon, 25 Apr 2022 13:48:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year again
>
> test/jdk/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> I think you meant 2022 :-)

How times fly! :-) Thanks for catching.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8382

From alanb at openjdk.java.net  Mon Apr 25 14:01:26 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 25 Apr 2022 14:01:26 GMT
Subject: RFR: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper [v2]
In-Reply-To: <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>
References: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
 <JdLUEdWD9HagV1UAeidKp89HnD8jqPWfiE_h1wE13Q4=.04b9672e-1d80-42fb-8553-e42e5139fb77@github.com>
Message-ID: <g6qgtgDnjN-aSVKK6cTshf4KTfsvCkQL-8ZDYilre6o=.d7ce0184-7b9c-424f-abfb-55e70b5db970@github.com>

On Mon, 25 Apr 2022 13:56:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual threads.
>> The issue has nothing to do with virtual threads, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created.
>> 
>> best regards,
>> 
>> -- daniel
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year again

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8382

From jiefu at openjdk.java.net  Mon Apr 25 14:17:27 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 25 Apr 2022 14:17:27 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <MUPQmersb0YhbyWhFJoVqAvCwrvnqjIzZY8OfLVn634=.8baec30e-434e-4c49-9abd-9fa5ac88ef5a@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <MUPQmersb0YhbyWhFJoVqAvCwrvnqjIzZY8OfLVn634=.8baec30e-434e-4c49-9abd-9fa5ac88ef5a@github.com>
Message-ID: <XsY9cIWU6ixPw69dStXi-40CHJNun7kpLXLsf3vTR9w=.da6621db-eed0-4801-83b0-f121dd69ec20@github.com>

On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> We can raise attention to that:
> 
> /** Produce {@code a>>>(n&(ESIZE*8-1))} 
>   * (The operand and result are converted if the operand type is {@code byte} or {@code short}, see below).  Integral only.
>   * ...
>   */

Hi @PaulSandoz ,

I add a piece of notice at the end of the brief description of `LSHR` since not everyone would click and see the details without the change.
What do you think?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From remi.catherinot at orange.com  Mon Apr 25 14:23:56 2022
From: remi.catherinot at orange.com (remi.catherinot at orange.com)
Date: Mon, 25 Apr 2022 14:23:56 +0000
Subject: System.exit deadlock if called within a hook
In-Reply-To: <CANghgrRUw-qabE5kM=Jq8Z0RSXXFAZXpy6X+WfVtkxPRLJ_0UQ@mail.gmail.com>
References: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
 <CANghgrRUw-qabE5kM=Jq8Z0RSXXFAZXpy6X+WfVtkxPRLJ_0UQ@mail.gmail.com>
Message-ID: <31983_1650896636_6266AEFC_31983_484_3_278e0e606a8141b6a288d8516a96a255@orange.com>

Ok, you're right that it can raise an exception when the calling thread does not have the security privileges needed. But what if it had them ? Right now the deadlock comes from the fact is doesn't got back to the caller with an exception and doesn't end the current thread. My 1st proposal was to have a way to end the current thread. If you think that is not acceptable and prefer the exception solution, then something like throw new IllegalStateException("Shutdown in progress") which is already used when adding new hooks while shutting down and adjust the System.exit method documentation accordingly (might be dangerous since it "breaks" actual documented and implemented contract, might be too heavy for a change).

First things first : do you think this is an issue the JVM has to solve (either using a destroy-current-thread solution, or a throw-IllegalStateException one), or do you think this was a hook misuse and maybe would only need maybe a clearer warning in the hooks's documentation, or do you think we keep everything as it is because I should have guessed better reading the actual documentation ?? ?

My demo code is simple, but the environment in which it happened and being able to understand the jstack output with lots of frameworks hooking here and there plus some uncaught exception hanlders kicking in was really really hard. In my case I ended up having a hook to run a delayed Runtime.halt call, which more feels like a JVM workaround rather than a framework workaround.

Regards,


Orange Restricted

-----Message d'origine-----
De?: David Lloyd <david.lloyd at redhat.com> 
Envoy??: lundi 25 avril 2022 15:41
??: CATHERINOT R?mi DTSI/PFS <remi.catherinot at orange.com>
Cc?: core-libs-dev at openjdk.java.net
Objet?: Re: System.exit deadlock if called within a hook

On Mon, Apr 25, 2022 at 8:09 AM <remi.catherinot at orange.com> wrote:
> because it would still run finally blocks, which cannot happen for no 
> return methods like System.exit and Runtime.halt

FWIW I don't think this is correct. `exit` and `halt` etc. cannot
*return* but they're definitely allowed to throw an exception (`SecurityException` is presently specified) and thus are allowed to unwind the stack, even through `finally` blocks.

--
- DML ? he/him

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


From hseigel at openjdk.java.net  Mon Apr 25 14:26:17 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 25 Apr 2022 14:26:17 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v3]
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <dcpCPCeaLFDRRzDOtjGRKHqbeZGX7KPUAsTtlR5d-NU=.cc35c9de-7020-4ed4-b135-ed7932b534c2@github.com>

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  Fix globals.hpp text

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8222/files
  - new: https://git.openjdk.java.net/jdk/pull/8222/files/5fdb220a..22185a6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8222&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8222&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8222.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8222/head:pull/8222

PR: https://git.openjdk.java.net/jdk/pull/8222

From hseigel at openjdk.java.net  Mon Apr 25 14:26:18 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 25 Apr 2022 14:26:18 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v2]
In-Reply-To: <mZbXGGdF0FQR-mlbmRrWtA9uaoQYPNQWe1YgH8-r6HI=.3edbd73e-92b9-42b9-bb60-d718bfa81fbd@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
 <mZbXGGdF0FQR-mlbmRrWtA9uaoQYPNQWe1YgH8-r6HI=.3edbd73e-92b9-42b9-bb60-d718bfa81fbd@github.com>
Message-ID: <8HN-IcjyRXNYtVcvjIwCSU3keFceRbOziJ6piS6ufU4=.d5e7220f-746a-4d9b-8dc8-fd136327720a@github.com>

On Fri, 22 Apr 2022 18:14:27 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore source, fix man page

Hi David,  Thanks for looking at this and for the suggested text.  Please review this latest commit to fix the text in globals.hpp.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From redestad at openjdk.java.net  Mon Apr 25 15:13:23 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Apr 2022 15:13:23 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
Message-ID: <czHXl4LKW4sUH1t9MVUIVc5WxFSVdoI4yuPlzxEl8bQ=.5ff73448-919d-44f2-bb9b-69b43a4be9f7@github.com>

On Wed, 20 Apr 2022 21:08:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
>> 
>>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> should be changed to 
>> 
>>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> as:
>> 
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove = check

Unfortunately this leads to an error for case-insensitive `regionMatches` between a latin-1-string that contains either of `\u00b5` or `\u00ff` (these two code-points have upper case codepoints outside of the latin-1 range) and a UTF-16 string:


jshell> "\u00b5".regionMatches(true, 0, "\u0100", 0, 1)
|  Exception java.lang.ArrayIndexOutOfBoundsException: Index 924 out of bounds for length 256
|        at CharacterDataLatin1.getProperties (CharacterDataLatin1.java:74)
|        at CharacterDataLatin1.toLowerCase (CharacterDataLatin1.java:140)
|        at StringLatin1.regionMatchesCI_UTF16 (StringLatin1.java:420)
|        at String.regionMatches (String.java:2238)
|        at (#4:1)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From david.lloyd at redhat.com  Mon Apr 25 15:29:28 2022
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 25 Apr 2022 10:29:28 -0500
Subject: System.exit deadlock if called within a hook
In-Reply-To: <31983_1650896636_6266AEFC_31983_484_3_278e0e606a8141b6a288d8516a96a255@orange.com>
References: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
 <CANghgrRUw-qabE5kM=Jq8Z0RSXXFAZXpy6X+WfVtkxPRLJ_0UQ@mail.gmail.com>
 <31983_1650896636_6266AEFC_31983_484_3_278e0e606a8141b6a288d8516a96a255@orange.com>
Message-ID: <CANghgrQwe9P8LRRSmwsew5Ryk5qTkM5JJQan5d+1U-q6DRmxBw@mail.gmail.com>

On Mon, Apr 25, 2022 at 9:25 AM <remi.catherinot at orange.com> wrote:
>
> Ok, you're right that it can raise an exception when the calling thread does not have the security privileges needed. But what if it had them ? Right now the deadlock comes from the fact is doesn't got back to the caller with an exception and doesn't end the current thread. My 1st proposal was to have a way to end the current thread. If you think that is not acceptable and prefer the exception solution, then something like throw new IllegalStateException("Shutdown in progress") which is already used when adding new hooks while shutting down and adjust the System.exit method documentation accordingly (might be dangerous since it "breaks" actual documented and implemented contract, might be too heavy for a change).
>
> First things first : do you think this is an issue the JVM has to solve (either using a destroy-current-thread solution, or a throw-IllegalStateException one), or do you think this was a hook misuse and maybe would only need maybe a clearer warning in the hooks's documentation, or do you think we keep everything as it is because I should have guessed better reading the actual documentation ?? ?

If you're asking me personally, I think it would make a lot of sense
to throw IllegalStateException or a new subclass thereof (e.g.
`ExitInProgressException` or something). However, my opinion doesn't
count. I suspect that those whose opinions *do* count will probably
say that this would be too much of a breaking change.

-- 
- DML ? he/him


From naoto at openjdk.java.net  Mon Apr 25 16:18:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 25 Apr 2022 16:18:19 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v3]
In-Reply-To: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
Message-ID: <UAcjPCgGCWS4VEN3p4n18XdcRfuBbKkbe54JlVLLX0M=.075eea41-fbfc-4cf3-be7c-7c21e5f5104f@github.com>

> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typos.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8270/files
  - new: https://git.openjdk.java.net/jdk/pull/8270/files/b5bcb870..a91fd9ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8270&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8270&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8270.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8270/head:pull/8270

PR: https://git.openjdk.java.net/jdk/pull/8270

From naoto at openjdk.java.net  Mon Apr 25 16:18:20 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 25 Apr 2022 16:18:20 GMT
Subject: RFR: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc [v2]
In-Reply-To: <LYaz0ymec53OaTXhHNrYPrioeSyh6Viun5llmsGjAaQ=.bc2f1807-dbe9-423a-a334-1f36f4832531@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
 <SHZ0SYQG27ZWyDWulHTS_T1wcWx2UK036p4Us9ln0Sc=.2baa9c9a-f8f2-41bc-97fc-0ecd43bdb2d0@github.com>
 <LYaz0ymec53OaTXhHNrYPrioeSyh6Viun5llmsGjAaQ=.bc2f1807-dbe9-423a-a334-1f36f4832531@github.com>
Message-ID: <dVprTI1iayJJh2pdfp5328dHMCRRnl1mrrpjmRZhPu0=.0b0bf22d-0c70-4f78-8a82-5433a2098b3f@github.com>

On Sat, 23 Apr 2022 05:53:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified the spec for the new system properties.
>
> src/java.base/share/classes/java/lang/System.java line 774:
> 
>> 772:      *     <td>Character encoding name for {@link System#out System.out}.
>> 773:      *     The Java runtime can be started with the system property set to {@code UTF-8},
>> 774:      *     starting it with the property set to another value clears to undefined behavior.
> 
> _leads_ to undefined behavior

Good catch! Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From duke at openjdk.java.net  Mon Apr 25 17:22:29 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 25 Apr 2022 17:22:29 GMT
Subject: Integrated: 8285477: Add a PRECISION public static field to j.l.Float
 and j.l.Double
In-Reply-To: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
References: <2xi0mXPTvIDKi-Mvi6BJXsTqAejEdLNf-Ajddz9Pa_Y=.0ba750e8-674d-4aff-a41f-84bb75f6c9e1@github.com>
Message-ID: <5xClS965CFgh0-Lso8UmGK_ODN7W1afhxbYMHP4EpBg=.4ae271a0-f711-40c5-a453-f365bb91df7a@github.com>

On Fri, 22 Apr 2022 14:26:07 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Add useful constants specified in IEEE 754.

This pull request has now been integrated.

Changeset: fb605944
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e
Stats:     52 lines in 2 files changed: 32 ins; 14 del; 6 mod

8285477: Add a PRECISION public static field to j.l.Float and j.l.Double

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8362

From ecki at zusammenkunft.net  Mon Apr 25 17:38:45 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 25 Apr 2022 17:38:45 +0000
Subject: Regression after April Java 17 Update (mime types)
Message-ID: <AM9P193MB1142B45AEA22E0D905602BD9FFF89@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello,

We just tried to push out the Java 17 April Update but it failed with some incompatible behavior. We found out it is caused due to a new mime-type (and a bug in Apache VFS) that JAR files could no longer be opened in an overlay (technically a JAR URL suddenly had a mime-type and therefore VFS no longer looked at the file extension).

Just wanted to give a heads up in case anybody else has that problem. The change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the OpenJDK announcement?

This specific case is a changed behavior (even when it has rather unexpected negative consequences), it would be therefore good to be called out specifically.

Gruss
Bernd


--
http://bernd.eckenfels.net

From duke at openjdk.java.net  Mon Apr 25 20:16:26 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 25 Apr 2022 20:16:26 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <czHXl4LKW4sUH1t9MVUIVc5WxFSVdoI4yuPlzxEl8bQ=.5ff73448-919d-44f2-bb9b-69b43a4be9f7@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
 <czHXl4LKW4sUH1t9MVUIVc5WxFSVdoI4yuPlzxEl8bQ=.5ff73448-919d-44f2-bb9b-69b43a4be9f7@github.com>
Message-ID: <H77-a8tIZqtaost5n3XKrlfNoIHmYc-lNqBZlZXxMlg=.39f372ac-bc89-469a-acd0-5c3e2710c813@github.com>

On Mon, 25 Apr 2022 15:10:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Unfortunately this leads to an error for case-insensitive `regionMatches` between a latin-1-string that contains either of `\u00b5` or `\u00ff` (these two code-points have upper case codepoints outside of the latin-1 range) and a UTF-16 string:
> 
> ```
> jshell> "\u00b5".regionMatches(true, 0, "\u0100", 0, 1)
> |  Exception java.lang.ArrayIndexOutOfBoundsException: Index 924 out of bounds for length 256
> |        at CharacterDataLatin1.getProperties (CharacterDataLatin1.java:74)
> |        at CharacterDataLatin1.toLowerCase (CharacterDataLatin1.java:140)
> |        at StringLatin1.regionMatchesCI_UTF16 (StringLatin1.java:420)
> |        at String.regionMatches (String.java:2238)
> |        at (#4:1)
> ```

@cl4es Yes, you are correct.

And if change it to `CharacterDataLatin1.instance.toLowerCase(u1)`, it would strongly harm performance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Mon Apr 25 20:20:24 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 25 Apr 2022 20:20:24 GMT
Subject: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
In-Reply-To: <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
 <sMuxMYZT504ulzQcDv4yT3FvL6rHg1BlWtzakpMP77Y=.57a98508-cf96-4e17-bd7f-4a02a87f3678@github.com>
Message-ID: <Rpcr-HB9VIHcQuDKx4Ti3nolnE2RcwmiB6lqeZsJ_Co=.6fe0efcc-fcd0-47de-85cf-c83b48ea8c2a@github.com>

On Wed, 20 Apr 2022 21:08:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
>> 
>>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> should be changed to 
>> 
>>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>>                 continue;
>>             }
>> 
>> as:
>> 
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove = check

close as not worthy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Mon Apr 25 20:20:24 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 25 Apr 2022 20:20:24 GMT
Subject: Withdrawn: 8285255: refine StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
References: <l4xFebpCIiWjBidERCxl70DUf6CzShlZX_0woNvGXus=.80c5fd55-0946-4bf3-8ddd-cb95e448aeaf@github.com>
Message-ID: <2w3r6EMdfpri6-XfkDEwaNSORr_DYS-sEUQy84ASpK0=.1019a754-ab65-410f-8b77-0fc38733f401@github.com>

On Tue, 19 Apr 2022 21:15:29 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches  https://github.com/openjdk/jdk/pull/8292/
> 
>             if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> should be changed to 
> 
>             if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) : c1) == Character.toLowerCase(u2)) {
>                 continue;
>             }
> 
> as:
> 
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and don't need a lowercase cauculation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8308

From duke at openjdk.java.net  Mon Apr 25 20:34:32 2022
From: duke at openjdk.java.net (iaroslavski)
Date: Mon, 25 Apr 2022 20:34:32 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <ROLvhoLHEbn37kBYeBjatpYtSTU6Ca9PwYtrcGKIVxs=.8501ae83-38d4-43d7-a122-43f6a1e9b4e3@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

waiting testing result from Laurent

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From lancea at openjdk.java.net  Mon Apr 25 20:53:26 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 25 Apr 2022 20:53:26 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
In-Reply-To: <MJltutSoIIIZdUF3liaW9-uFMjvfPdHR0d73YDhsveY=.f3ca196f-bc54-41e2-be49-6f1dd6ea16f8@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <MJltutSoIIIZdUF3liaW9-uFMjvfPdHR0d73YDhsveY=.f3ca196f-bc54-41e2-be49-6f1dd6ea16f8@github.com>
Message-ID: <JP4QUgxzSGPp2sYwzY-XarydNto4PfZm3Gg0jd9YB-0=.fa4cbebe-c901-4bb9-bf1d-726f9c503737@github.com>

On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - Refresh
>  - Refresh
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

Test changes look good.  One question/comment below

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From lancea at openjdk.java.net  Mon Apr 25 20:53:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 25 Apr 2022 20:53:28 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
Message-ID: <VlbnqGXvp0l0Rabuwu2jvOowuzdntzlHQvXtqyasY3Q=.73e6a6af-ed8a-42f7-8083-e4bd2e0dce77@github.com>

On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh

test/jdk/jdk/internal/vm/Continuation/Basic.java line 327:

> 325: 
> 326:     // @Test
> 327:     public void testPinnedNative() {

Are you disabling this test?  if so, you can do `@Test(enabled=false)`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Mon Apr 25 22:27:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 25 Apr 2022 22:27:46 GMT
Subject: RFR: JDK-8285614: Fix typo in java.lang.Float
Message-ID: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>

Fix typo introduced in JDK-8261123.

-------------

Commit messages:
 - JDK-8285614: Fix typo in java.lang.Float

Changes: https://git.openjdk.java.net/jdk/pull/8390/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8390&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285614
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8390.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8390/head:pull/8390

PR: https://git.openjdk.java.net/jdk/pull/8390

From naoto at openjdk.java.net  Mon Apr 25 22:38:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 25 Apr 2022 22:38:49 GMT
Subject: RFR: JDK-8285614: Fix typo in java.lang.Float
In-Reply-To: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
References: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
Message-ID: <J2NqfjXjovxIpWw8496LaSUWEEElfTvTFsSMJKuO2pE=.48617f2f-f8ee-4aeb-bf9e-0b1cbfb2cfb7@github.com>

On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo introduced in JDK-8261123.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8390

From lancea at openjdk.java.net  Mon Apr 25 22:52:03 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 25 Apr 2022 22:52:03 GMT
Subject: RFR: JDK-8285614: Fix typo in java.lang.Float
In-Reply-To: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
References: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
Message-ID: <wERSwozV5XVRS1RWShzLNPTkgCQDVI0ZLGrixWx6OKc=.98520044-7578-42ff-b7cd-2f1c4580521a@github.com>

On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo introduced in JDK-8261123.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8390

From dholmes at openjdk.java.net  Mon Apr 25 22:53:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 25 Apr 2022 22:53:04 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v3]
In-Reply-To: <dcpCPCeaLFDRRzDOtjGRKHqbeZGX7KPUAsTtlR5d-NU=.cc35c9de-7020-4ed4-b135-ed7932b534c2@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
 <dcpCPCeaLFDRRzDOtjGRKHqbeZGX7KPUAsTtlR5d-NU=.cc35c9de-7020-4ed4-b135-ed7932b534c2@github.com>
Message-ID: <ql4Oq5DlPrNd19VE5HP2aBE07712bK1Xy79pA0tfh-8=.c5290bd2-6b6c-48f1-9f73-8263afbcfcf0@github.com>

On Mon, 25 Apr 2022 14:26:17 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix globals.hpp text

That all looks good to me.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8222

From iris at openjdk.java.net  Mon Apr 25 22:56:57 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 25 Apr 2022 22:56:57 GMT
Subject: RFR: JDK-8285614: Fix typo in java.lang.Float
In-Reply-To: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
References: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
Message-ID: <rJhD5rDpFQQy4nZ9Pt6w18DIXhGh8rsiLSVWKFgS5tA=.d2f3af74-6815-4ea8-985e-03089f925917@github.com>

On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo introduced in JDK-8261123.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8390

From darcy at openjdk.java.net  Mon Apr 25 23:06:54 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 25 Apr 2022 23:06:54 GMT
Subject: Integrated: JDK-8285614: Fix typo in java.lang.Float
In-Reply-To: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
References: <f2v1Ac9DfLPdubWsLqYIJEK5VFMEiK-Mc7yDcqxh3RA=.1a653205-7097-4bab-a5b0-5b5bf5fc39b9@github.com>
Message-ID: <t160TArgCGrUCcFBwu_q0CQ3pOIz_xcK8x4fIyUkApg=.b89601fb-f6e2-4776-aa4d-935fef75da6a@github.com>

On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo introduced in JDK-8261123.

This pull request has now been integrated.

Changeset: d435d692
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d435d692b0bbc0164a1fd1bf3616ee61a3c1c58b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8285614: Fix typo in java.lang.Float

Reviewed-by: naoto, lancea, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/8390

From david.holmes at oracle.com  Mon Apr 25 23:24:06 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Apr 2022 09:24:06 +1000
Subject: System.exit deadlock if called within a hook
In-Reply-To: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
References: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
Message-ID: <68e8a53c-6fdf-7f52-7148-f1cbe0977d1b@oracle.com>

On 25/04/2022 11:08 pm, remi.catherinot at orange.com wrote:
> Hi,
> 
> Exemple code to deadlock the JVM. Only Runtime.halt from within the JVM or a SIGKILL from outside stops it. Normal kills and Ctrl-C (which is a SIGTERM) fail to do so.
> 
> public class ExitInHookDemo {
>              public static void main(String...args) {
>                          Runtime.getRuntime().addShutdownHook(new Thread("hook") {
>                                      public void run() { System.exit(1); }
> });
>              }
> }

This is a documented usage limitation of exit().

" All registered shutdown hooks, if any, are started in some unspecified 
order and allowed to run concurrently until they finish. Once this is 
done the virtual machine halts.

If this method is invoked after all shutdown hooks have already been run 
and the status is nonzero then this method halts the virtual machine 
with the given status code. Otherwise, this method blocks indefinitely. "

Here you have a hook that calls exit() before all hooks have been run, 
hence it blocks indefinitely. As the hook blocks indefinitely the 
running of hooks cannot finish as required and so the virtual machine 
does not halt.

Conceptually you are asking for the indefinitely blocked hook to be 
treated as-if "finished", but there is no actual mechanism to implement 
that. You don't need to "destroy" the thread to force it to be 
"finished", but you do need a way for exit() to check if the current 
thread is a hook and to adapt the logic so that thread.join() is not 
used to wait for true termination. It would be possible to construct 
something I think, but I don't know if such an enhancement would be 
considered worthwhile versus don't call exit() from a hook.

Cheers,
David
-----

> I've tried to more or less do a pure java patch in java.lang.Shutdown but the only way to have a real patch would be to have Thread.destroy still there and implemented or anything allowing Shutdown to destroy a thread. In essence, System.exit is a no return method call. So using Thread.stop which raise a ThreadDeath error is not enough (the method go back to the caller with the error). Only Thread.destroy has the contract of being a no return call. Yes the documentation said it is unsafe because it does not release locks & co, but right now that is exactly what is happening, so Thread.destroy limitations are acceptable. Throwing something that is not catchable, something legit to throw but not legit to catch, even by a catch Throwable, is not enough because it would still run finally blocks, which cannot happen for no return methods like System.exit and Runtime.halt: try { System.exit(0); /* code that should never be reached */ } catch (Throwable t) { /* code that should never be reached */ } finally { /* code that should also never be reached */ }
> 
> I've searched the known/documented bugs but I either missed the fact it was already reported, or I only got entries about removing Thread.destroy.
> 
> By the way, I'm not really asking to have Thread.destroy implemented were it is currently defined (a public method inside Thread). I mean at least java.lang.Shutdown should have a way to destroy Threads, even a private one. Threads destroyed that way should make threads stuck joining the destroyed one must be released.
> 
> I got the bug on java 1.8, oracle and openjdk ones. Not tested it one >=9 ones.
> 
> Here is what the approximation of a patch using pure java, but I'm no jdk expert and had no access to thread destruction, so it is not perfect. The code is from java.lang.Shutdown
>      static void exit(int status) {
>          boolean wasRunning = false; // < - - new var
>          boolean runMoreFinalizers = false;
>          synchronized (lock) {
>              switch (state) {
>              case RUNNING:       /* Initiate shutdown */
>                  state = HOOKS;
>                  wasRunning = true; // < - - first call to System.exit, the caller will run all of what is needed -hooks, maybe finalizers, etc.
>                  if (status != 0) runFinalizersOnExit = false; // < - - also moved the runFinalizersOnExit block to avoid having it changed/altered by several threads trying to exit with different status code
>                  break;
>              case HOOKS:         /* Stall and halt */
>                  break;
>              case FINALIZERS:
>                  if (status != 0) {
>                      /* Halt immediately on nonzero status */
>                      halt(status);
>                  } else {
>                      /* Compatibility with old behavior:
>                       * Run more finalizers and then halt
>                       */
>                      runMoreFinalizers = runFinalizersOnExit;
>                  }
>                  break;
>              }
>          }
>          if (!wasRunning) Thread.currentThread().stop(); // < - - should be a destroy rather than a stop. This thread is not the 1st who called System.exit, and since it should never return, it must die asap. We are outside of the synchronized block so if any lock remains acquired by this thread, they are acquired by the caller which should have released them before calling exit on the 1st place. If the caller called us while having locks, it is a caller bug, not a Shutdown.exit one. Current implementation since it never returns (and yield the stuck bug I report) also never release any of the locks it has too
>          // < - - beyond this line nothing has been modified
>          if (runMoreFinalizers) {
>              runAllFinalizers();
>              halt(status);
>          }
>          synchronized (Shutdown.class) {
>              /* Synchronize on the class object, causing any other thread
>               * that attempts to initiate shutdown to stall indefinitely
>               */
>              sequence();
>              halt(status);
>          }
>      }
> 
> 
> Regards,
> Ogrom.
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

From naoto at openjdk.java.net  Tue Apr 26 00:40:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 26 Apr 2022 00:40:38 GMT
Subject: RFR: 8282227: Locale information for nb is not working properly
Message-ID: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>

This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue.

-------------

Commit messages:
 - 8282227: Locale information for nb is not working properly

Changes: https://git.openjdk.java.net/jdk/pull/8394/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8394&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282227
  Stats: 79 lines in 2 files changed: 74 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8394.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8394/head:pull/8394

PR: https://git.openjdk.java.net/jdk/pull/8394

From joe.darcy at oracle.com  Tue Apr 26 02:17:11 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 25 Apr 2022 19:17:11 -0700
Subject: Java Floating Points.
In-Reply-To: <iCORp6NCIt8s2VCks4xmemCc3JvDIim4s2gktYmU2DSEfseRE4mWeqWv_xLuUD6RM_5AxjJoTq812Gc_z2HBnydZ9IyEn-xObfEU2sRTp-Y=@protonmail.com>
References: <iCORp6NCIt8s2VCks4xmemCc3JvDIim4s2gktYmU2DSEfseRE4mWeqWv_xLuUD6RM_5AxjJoTq812Gc_z2HBnydZ9IyEn-xObfEU2sRTp-Y=@protonmail.com>
Message-ID: <93895b99-7446-be09-8f7a-c109fe176d50@oracle.com>

In the spirit of repeating previous messages, I again refer interested 
readers to my 2018 email to core-libs-dev which addresses many of the 
technical points being (re)raised here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html

Appeal to authority is a commonly used rhetorical technique. A worse 
variant of appeal to authority is when the work being cited does not in 
fact support the argument being put forward. Case point, the document

 ??? "How Java?s Floating-Point Hurts Everyone Everywhere"
 ??? https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

originally authored by Prof. Kahan and myself in 1998, does not advocate 
decimal-only computation. The word "decimal" appears exactly zero times 
in the July 30, 2004 version of the document (Prof. Kahan often revises 
and reposts his documents).

In brief, the thesis of the "JavaHURT" paper is that the Java platform 
commits sins of omission by requiring IEEE 754 arithmetic while 
forbidding certain mandatory feature of the IEEE 754 standard and by 
precluding support for the 80-bit floating-point format found on 
contemporary x86 processors. Moral conclusions aside, it is correct that 
the Java platform then, as now, does not natively support those 
mandatory features of IEEE 754 (rounding modes, floating-point exception 
handling) for the built-in floating-point types float and double. No 
other widely used and available programming platform I know of supports 
those features either. In the intervening years, the 80-bit format 
originating with the x87 co-processor has been effectively deprecated by 
both Intel and AMD.

While IEEE 754 is commonly thought of as a hardware standard, the 
designers of the standard intended it to provide a programming platform. 
More recent revisions of IEEE 754 have tried to make this intention clearer.

Without researching the exact JDK where SSE support was first included, 
it was would have been at least 15 years ago, probably more.

The SSE instructions do *not* support decimal floating-point 
computation; they are primarily, but not exclusively, about 32-bit and 
64-bit binary floating-point operations:

 ??? https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

The POWER6 chip is one of the few that does have hardware support for 
decimal floating-point, a feature added in the 2008 revision of IEEE 754:

 ??? https://en.wikipedia.org/wiki/Decimal_floating_point

Rather than re-asking core-libs-dev every few days if the the platform 
stewards have suddenly decided to undertake this large, but poorly 
defined effort, I suggest trying you organize like minded parties, 
perhaps including A Z poweruserm at live.com.au, to yourselves build a 
library/environment/platform with the features you envision to 
concretely demonstrate its benefits.

-Joe

On 4/21/2022 11:55 PM, sminervini.prism wrote:
> mailto:core-libs-deb at openjdk.net
> To core-libs, OpenJDK, JCP, and all
>
> For the sake of the consequences of the real issues it raises,
> I include the rebuttal to Andrew Haley's earlier comments,
> and I reiterate that the real need is to improve the Java software
> at its roots level, more so.
>
> Andrew Haley said, and we reply:
>
> 1) Firstly, it is not possible to change Java's core floating-point
> arithmetic in a compatible way. We certainly will not adopt decimal
> floating-point for Java's core arithmetic.
>
> While I don't like re-submitting this article, certainly not on this forum,
> there has always been this article:
>
> https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> The age of this article does not matter. It is as bearing to action in 2022
> as it was then.
>
> -Even without recombiling floating point or StrictMath code, of course it could
> be changed, and compatibly. Runtime or compile time switches could be introduced.
> Key words could be introduced that may apply at many different levels. Maybe
> even annotations could be used for the compiler, which can already apply at
> any point that floating point arithmetic and StrictMath methods and fields
> may occur. Whevever there is a code space, there could be an annotation
> or a keyword. At the class or interface or static block level. At the
> variable, data, field and method level. Even at the main method,
> Thread level, Runnable or Future level, or even further.
>
> 2) Secondly, Java should not be your focus. We will not change Java's
> arithmetic in a way that is incompatible with other languages or
> which makes Java slower on existing hardware.
>
> -There could be dual mode floating point correction, implemented inside
> Java at any level you could like. Dual mode couldn't be incompatible
> with anything.
>
> 3) You must read and fully understand this before you go any further. It
> will require a lot of study:
>
> https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
>> May the Java Community Process reconsider the present floating point
>> operations and method calls situation, based on an imperfect
>> standard and improper workaround, and provide corrected, defaulting
>> or specifying-compatible waya for Java floating point arithmetic and
>> Calculator class method results to always cohere in their ranges,
>> without denormal and pronormal inclusion?
> In a word, no. That possibility is so unlikely that it is not worthy
> of consideration.
>
> -IEEE 754 has a blind spot, an oversight error. It says nothing about
> operation values that straddle the range of the arithmetic or method result,
> partway in, partway out. BigInteger, BigDecimal, or the big-math library
> at https://github.com/eobermuhlner/big-math are only temporary stop-gap measures
> that are two large in memory, more than needed, and too slow. The article included
> as part of 3) doesn't even mention SSE, the presence of end of range
> carrying additional bits.
>
> Speed at the expense of accurary, ie. providing a rapid falsehood, is also a
> logic error that can compromise the entire enterprise of computer software
> itself. What is required is the inclusion of SSE additional registers and their
> use; just a little bit of extra registry space to handle range end carries if they occur.
>
> We wish to appeal to reason and software needs on this subject, if not the odds!
>
> A mechanical clock is really amazing because it is complex, and because all the pieces whizz around together at amazing speed, but because it maintains those earlier two
> properties while maintaining accurate time. The clock loses usefulness,
> and even any usefulness, if the accurate time can't be set or maintained,
> at the rate it needs to operate at.
>
> The fact that more registers are referred to, to uphold float and double, has not been
> enough of a speed compromise to prevent 128 bit numbers elsewhere.
> Besides, the emptiness of extra bits past the range limit of float and double
> could be optimised and controlled by one flag bit.
>
> When the enhancements to the switch statements came along, all previous options were
> maintained, while including, even integrating, the new ones: the abbility to switch on String, and the ability to coelesce cases in any way. There ended up being no kind of ultimate problem, no matter which developers used which approach for accurate, logic correct software. Whatever approach is taken, floating point correction need be no better, and offers in-place advantages. And the present state of floating point is a logic error, with IEEE 754 on this precise point being silent, incorrect, and irrelevant.
>
> Is there someone else involved in core-libs-dev at openjdk.java.net, or the JCP,
> who can give a more particular response to this issue via the points raised here,
> and engender change to the attitudes to floating point arithmetic and
> floating point elementary functions, so that release versions of Java SE and
> OpenJDK can include FP error correction in this Java domain?
>
> Sergio MinerviniS.M.
>
> Sent with [ProtonMail](https://protonmail.com/) secure email.

From redestad at openjdk.java.net  Tue Apr 26 11:03:24 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Apr 2022 11:03:24 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
Message-ID: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>

The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.

Baseline:

Benchmark                                    Mode  Cnt   Score   Error  Units
MethodTypeAcquire.baselineRaw                avgt    5   0.673 ? 0.036  ns/op
MethodTypeAcquire.testGenericObject          avgt    5   0.520 ? 0.162  ns/op
MethodTypeAcquire.testMultiPType             avgt    5  47.922 ? 1.778  ns/op
MethodTypeAcquire.testMultiPType_Arg         avgt    5  28.992 ? 0.949  ns/op
MethodTypeAcquire.testMultiPType_ObjectAndA  avgt    5  56.698 ? 0.879  ns/op
MethodTypeAcquire.testMultiPType_ObjectOnly  avgt    5  55.705 ? 0.854  ns/op
MethodTypeAcquire.testObjectObject           avgt    5  31.729 ? 2.204  ns/op
MethodTypeAcquire.testReturnInt              avgt    5  26.171 ? 0.141  ns/op
MethodTypeAcquire.testReturnObject           avgt    5  24.340 ? 0.868  ns/op
MethodTypeAcquire.testReturnVoid             avgt    5  24.793 ? 2.816  ns/op
MethodTypeAcquire.testSinglePType            avgt    5  32.653 ? 1.082  ns/op


Patched:

Benchmark                                    Mode  Cnt   Score   Error  Units
MethodTypeAcquire.baselineRaw                avgt    5   0.727 ? 0.382  ns/op
MethodTypeAcquire.testGenericObject          avgt    5   0.658 ? 0.655  ns/op
MethodTypeAcquire.testMultiPType             avgt    5  48.066 ? 1.187  ns/op
MethodTypeAcquire.testMultiPType_Arg         avgt    5  27.097 ? 0.745  ns/op
MethodTypeAcquire.testMultiPType_ObjectAndA  avgt    5  58.074 ? 6.299  ns/op
MethodTypeAcquire.testMultiPType_ObjectOnly  avgt    5   0.538 ? 0.195  ns/op
MethodTypeAcquire.testObjectObject           avgt    5   0.520 ? 0.162  ns/op
MethodTypeAcquire.testReturnInt              avgt    5  28.093 ? 0.235  ns/op
MethodTypeAcquire.testReturnObject           avgt    5   0.540 ? 0.204  ns/op
MethodTypeAcquire.testReturnVoid             avgt    5  24.746 ? 0.706  ns/op
MethodTypeAcquire.testSinglePType            avgt    5  32.662 ? 1.924  ns/op


The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost.

-------------

Commit messages:
 - Copyrights
 - 8285633: Take better advantage of generic MethodType cache

Changes: https://git.openjdk.java.net/jdk/pull/8398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285633
  Stats: 101 lines in 8 files changed: 78 ins; 1 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8398/head:pull/8398

PR: https://git.openjdk.java.net/jdk/pull/8398

From dfuchs at openjdk.java.net  Tue Apr 26 11:58:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Apr 2022 11:58:56 GMT
Subject: Integrated: 8284779: Test
 java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails
 intermittently with vthreads wrapper
In-Reply-To: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
References: <bltdtPwLXjEhrHX4oJ2rbdlqXyfk-sDXqQErJZZWUl0=.bbb9ddfd-280d-4239-aae4-696ed9d37694@github.com>
Message-ID: <myDFCuEe8GZijPrB5f5L8qVJp5_7_cvUxyANvUksOJc=.7f19f9f2-1ef5-444c-b293-07a6943c85fc@github.com>

On Mon, 25 Apr 2022 13:30:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual threads.
> The issue has nothing to do with virtual threads, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created.
> 
> best regards,
> 
> -- daniel

This pull request has now been integrated.

Changeset: 552e1b0b
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/552e1b0b8a0cd49089f58dea92ca96cce86b311f
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8382

From eosterlund at openjdk.java.net  Tue Apr 26 13:51:17 2022
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 26 Apr 2022 13:51:17 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
In-Reply-To: <MJltutSoIIIZdUF3liaW9-uFMjvfPdHR0d73YDhsveY=.f3ca196f-bc54-41e2-be49-6f1dd6ea16f8@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <MJltutSoIIIZdUF3liaW9-uFMjvfPdHR0d73YDhsveY=.f3ca196f-bc54-41e2-be49-6f1dd6ea16f8@github.com>
Message-ID: <3euEQy5Mq4sADeywuO86A4TGzStWEaaRyEHdZRCoPao=.593b7f97-4ce1-44fb-a77d-5677a34ce2a8@github.com>

On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - Refresh
>  - Refresh
>  - Refresh
>  - Refresh
>  - Merge with jdk-19+18
>  - Refresh
>  - Initial push

I have done a long and extensive hands-on review of most of the JVM code (excluding most of the JVMTI changes). There is still room for improvements, but I think this is in a good enough shape to be integrated now, plus minus some patches in the ether between the fibers branch and this PR which I'm sure will pop up soon. So this looks good to me. Ship it!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From christoph.langer at sap.com  Tue Apr 26 15:18:38 2022
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Apr 2022 15:18:38 +0000
Subject: Regression after April Java 17 Update (mime types)
In-Reply-To: <AM9P193MB1142B45AEA22E0D905602BD9FFF89@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <AM9P193MB1142B45AEA22E0D905602BD9FFF89@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <PAXPR02MB7799C331228DB6CA2B86969F8AFB9@PAXPR02MB7799.eurprd02.prod.outlook.com>

Hi Bernd,

I just noticed your report regarding the regression after JDK-8273655. I'm directing this communication to jdk-updates-dev now as it seems more appropriate.

I assume with release notes you're referring to the Oracle 17.0.3 release notes? This change, if you look closely at the backports, was only brought to OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it would not be reflected in Oracle release notes. The best you can get for OpenJDK 17.0.3 release notes is [0], to my knowledge.

Do you have some more information regarding the incompatibility? What I'm understanding is that this backport unveils a problem with Apache VFS? Do you have a bug link for that one? If it's just uncovering a bug in another 3rd party software, I assume it doesn't merit a backout, though.

Best regards
Christoph

[0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html


> -----Original Message-----
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> On Behalf Of Bernd
> Eckenfels
> Sent: Montag, 25. April 2022 19:39
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Regression after April Java 17 Update (mime types)
> 
> Hello,
> 
> We just tried to push out the Java 17 April Update but it failed with some
> incompatible behavior. We found out it is caused due to a new mime-type (and
> a bug in Apache VFS) that JAR files could no longer be opened in an overlay
> (technically a JAR URL suddenly had a mime-type and therefore VFS no longer
> looked at the file extension).
> 
> Just wanted to give a heads up in case anybody else has that problem. The
> change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release
> notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the
> OpenJDK announcement?
> 
> This specific case is a changed behavior (even when it has rather unexpected
> negative consequences), it would be therefore good to be called out
> specifically.
> 
> Gruss
> Bernd
> 
> 
> --
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck
> enfels.net%2F&amp;data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f
> 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7
> C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8
> %3D&amp;reserved=0

From jvernee at openjdk.java.net  Tue Apr 26 15:33:55 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 26 Apr 2022 15:33:55 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
In-Reply-To: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
Message-ID: <dNRWkadihwc2yJOM1CEejaXuNXIyrAIS0UH3oGnPeIw=.c4fa5366-c2df-47f7-9282-f8bf4d78870f@github.com>

On Tue, 26 Apr 2022 10:57:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.
> 
> Baseline:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.673 ? 0.017  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.579 ? 0.125  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  46.671 ? 1.134  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  27.019 ? 0.437  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  57.217 ? 0.505  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15  57.114 ? 1.214  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15  33.380 ? 1.810  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.043 ? 0.187  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15  24.313 ? 0.074  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.360 ? 0.155  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.572 ? 1.101  ns/op
> 
> 
> Patched:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.683 ? 0.024  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.547 ? 0.047  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  48.532 ? 0.982  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  31.390 ? 5.269  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  60.165 ? 2.756  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15   0.599 ? 0.166  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15   0.541 ? 0.045  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.174 ? 0.257  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15   0.542 ? 0.045  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.621 ? 0.202  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.614 ? 1.109  ns/op
> 
> 
> The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost (~3ns/op, with overlapping error).

Marked as reviewed by jvernee (Reviewer).

test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line 104:

> 102:     @Benchmark
> 103:     public MethodType testMultiPType_ObjectOnly() {
> 104:         return MethodType.methodType(Object.class, Object.class, Object.class, Object.class, Object.class, Object.class, Object.class);

It might be interesting to add a benchmark where all types are `Object`, but non-constants, to see if that case improves as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From bpb at openjdk.java.net  Tue Apr 26 15:39:49 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 26 Apr 2022 15:39:49 GMT
Subject: Integrated: 8284930: Re-examine FilterInputStream mark/reset
In-Reply-To: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
References: <-zowvCciSXWskhITX9_YHDczfa_o1EyiRpPV31IUnmE=.bba252f5-7e4c-43f0-b933-09a0ff64df00@github.com>
Message-ID: <r4CWcoSaJlh5xf7B_Oc5_-KTBnMGUVxXaWT5dwZaBRU=.24ebb4b2-e069-431e-b6ab-24ef15333eee@github.com>

On Tue, 19 Apr 2022 23:26:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.FilterInputStream`.

This pull request has now been integrated.

Changeset: a3b78814
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a3b788144ecc37262a3560e9c234bc8fb41ca3df
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8284930: Re-examine FilterInputStream mark/reset

Reviewed-by: alanb, jpai, dfuchs, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8309

From naoto at openjdk.java.net  Tue Apr 26 16:09:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 26 Apr 2022 16:09:11 GMT
Subject: Integrated: 8283620: System.out does not use the encoding/charset
 specified in the Javadoc
In-Reply-To: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
References: <PkxO-A0pGhZl44nDxfv_YLNhiYgE393kFVHF9kjbYq8=.fc37e560-188d-4d3f-ac0b-cea890f03709@github.com>
Message-ID: <KQNPnmEPXVgGfPTHDCjF1QUDyEx8Y9ip0HfufY6FBs8=.78eb14db-84a1-4542-b918-5e65e1704d41@github.com>

On Fri, 15 Apr 2022 20:26:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Promoting the internal system properties for `System.out` and `System.err` so that users can override the encoding used for those streams to `UTF-8`, aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

This pull request has now been integrated.

Changeset: 03bcf7b6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03bcf7b6d196f6c5d851059cb6f580767eee4e94
Stats:     55 lines in 8 files changed: 22 ins; 4 del; 29 mod

8283620: System.out does not use the encoding/charset specified in the Javadoc

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8270

From rriggs at openjdk.java.net  Tue Apr 26 16:42:57 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 26 Apr 2022 16:42:57 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <zUPEkPzWRR-b-iZNfWR9FMOfQkazvAyNpc6dyL0z9MY=.57fc1374-b8c0-491e-9c4b-d9b6a83b6d61@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From duke at openjdk.java.net  Tue Apr 26 16:51:17 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 26 Apr 2022 16:51:17 GMT
Subject: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
Message-ID: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>

The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.

-------------

Commit messages:
 - Fix two typos in the spec of j.u.random.RandomGenerator

Changes: https://git.openjdk.java.net/jdk/pull/8404/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285658
  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404

PR: https://git.openjdk.java.net/jdk/pull/8404

From duke at openjdk.java.net  Tue Apr 26 16:51:18 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 26 Apr 2022 16:51:18 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator
In-Reply-To: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
Message-ID: <oBfqdG1Fb5bH16i-TFAPFVh3dJfWc0z84DN-3thoZus=.eff1790f-1f5f-45db-bf7c-233477391f5f@github.com>

On Tue, 26 Apr 2022 16:38:37 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.

This PR fixes the spec and replaces hard-coded literals with static compilation time symbolic expressions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From duke at openjdk.java.net  Tue Apr 26 16:55:44 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 26 Apr 2022 16:55:44 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v2]
In-Reply-To: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
Message-ID: <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>

> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8285658: Fix two typos in the spec of j.u.random.RandomGenerator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8404/files
  - new: https://git.openjdk.java.net/jdk/pull/8404/files/b3a802ae..8d4388bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404

PR: https://git.openjdk.java.net/jdk/pull/8404

From rriggs at openjdk.java.net  Tue Apr 26 16:57:53 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 26 Apr 2022 16:57:53 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <CHO1-s9dGVk7-qneDZT6O_WLer2pBq4h_7KuwgaQMEU=.81bb8ba9-3fc7-4fc7-95fd-67934ff049d2@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

Can you elaborate on the use case, what tests would it be used in?

The hardcoded `from` and `to` seem very rigid and require knowledge of the exact format. 
That might lead to very fragile tests.

Is this equivalent to looking for a substring aka `String.contains(xxx)` of the input file to replace (with line ending normalization)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From bpb at openjdk.java.net  Tue Apr 26 17:16:10 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 26 Apr 2022 17:16:10 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v2]
In-Reply-To: <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
 <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
Message-ID: <1-7vHKz7EiqrcN4fg4fd6D1mf-EUhfP99XUoeMqzFWI=.0960f47c-5ee7-4f57-b374-dc7714a0dc80@github.com>

On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285658: Fix two typos in the spec of j.u.random.RandomGenerator

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From redestad at openjdk.java.net  Tue Apr 26 17:24:53 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Apr 2022 17:24:53 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
In-Reply-To: <dNRWkadihwc2yJOM1CEejaXuNXIyrAIS0UH3oGnPeIw=.c4fa5366-c2df-47f7-9282-f8bf4d78870f@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
 <dNRWkadihwc2yJOM1CEejaXuNXIyrAIS0UH3oGnPeIw=.c4fa5366-c2df-47f7-9282-f8bf4d78870f@github.com>
Message-ID: <rU8vgD7Yd5t9E-jYTvNH_Cbo0HgoG2ed3Kb3ni6GxKc=.24772463-884e-465b-8151-61aa4c4cc60f@github.com>

On Tue, 26 Apr 2022 15:30:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.
>> 
>> Baseline:
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> MethodTypeAcquire.baselineRaw                avgt   15   0.673 ? 0.017  ns/op
>> MethodTypeAcquire.testGenericObject          avgt   15   0.579 ? 0.125  ns/op
>> MethodTypeAcquire.testMultiPType             avgt   15  46.671 ? 1.134  ns/op
>> MethodTypeAcquire.testMultiPType_Arg         avgt   15  27.019 ? 0.437  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  57.217 ? 0.505  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15  57.114 ? 1.214  ns/op
>> MethodTypeAcquire.testObjectObject           avgt   15  33.380 ? 1.810  ns/op
>> MethodTypeAcquire.testReturnInt              avgt   15  28.043 ? 0.187  ns/op
>> MethodTypeAcquire.testReturnObject           avgt   15  24.313 ? 0.074  ns/op
>> MethodTypeAcquire.testReturnVoid             avgt   15  24.360 ? 0.155  ns/op
>> MethodTypeAcquire.testSinglePType            avgt   15  33.572 ? 1.101  ns/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> MethodTypeAcquire.baselineRaw                avgt   15   0.683 ? 0.024  ns/op
>> MethodTypeAcquire.testGenericObject          avgt   15   0.547 ? 0.047  ns/op
>> MethodTypeAcquire.testMultiPType             avgt   15  48.532 ? 0.982  ns/op
>> MethodTypeAcquire.testMultiPType_Arg         avgt   15  31.390 ? 5.269  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  60.165 ? 2.756  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15   0.599 ? 0.166  ns/op
>> MethodTypeAcquire.testObjectObject           avgt   15   0.541 ? 0.045  ns/op
>> MethodTypeAcquire.testReturnInt              avgt   15  28.174 ? 0.257  ns/op
>> MethodTypeAcquire.testReturnObject           avgt   15   0.542 ? 0.045  ns/op
>> MethodTypeAcquire.testReturnVoid             avgt   15  24.621 ? 0.202  ns/op
>> MethodTypeAcquire.testSinglePType            avgt   15  33.614 ? 1.109  ns/op
>> 
>> 
>> The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost (~3ns/op, with overlapping error).
>
> test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line 104:
> 
>> 102:     @Benchmark
>> 103:     public MethodType testMultiPType_ObjectOnly() {
>> 104:         return MethodType.methodType(Object.class, Object.class, Object.class, Object.class, Object.class, Object.class, Object.class);
> 
> It might be interesting to add a benchmark where all types are `Object`, but non-constants, to see if that case improves as well.

Right.. I did a quick experiment and there's a large speed-up in the trivial `methodType(obj, obj)` case:

Benchmark                                      Mode  Cnt   Score   Error  Units
MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  30.052 ? 3.440  ns/op # baseline
MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  1.171  ? 0.001  ns/op # patch


I'll add a non-constant variant for the multi-arg Object variants, too. It should scale linearly and see a gain in the same ballpark. I think we need to keep the number of microbenchmarks here somewhat under control, though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From alanb at openjdk.java.net  Tue Apr 26 17:27:35 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 26 Apr 2022 17:27:35 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/05781877..0864cb09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05-06

  Stats: 582 lines in 34 files changed: 285 ins; 128 del; 169 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From weijun at openjdk.java.net  Tue Apr 26 17:29:53 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Apr 2022 17:29:53 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <m3zMC-TRvkiyzwmQ-YOkjkEWXhOddB9M8VUtB-_qBH0=.6c7359c7-9820-4af3-9475-3983f6ff0173@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

We have a test that dynamically downloads a source file, patches it, compiles it, and then runs it. We don't want to include a static copy of the file inside the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From jbhateja at openjdk.java.net  Tue Apr 26 17:35:56 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 26 Apr 2022 17:35:56 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <BZW29EXUQ-S7r_PO1Mcl2j3F-6Tcwezu5JWd00F3pJg=.c56a48e5-0b4c-4999-a69b-bc502abba40f@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> According to the Vector API doc, the LSHR operator computes a>>>(n&(ESIZE*8-1))

Documentation is correct if viewed strictly in context of subword vector lane, JVM internally promotes/sign extends subword type scalar variables into int type, but vectors are loaded from continuous memory holding subwords, it will not be correct for developer to imagine that individual subword type lanes will be upcasted into int lanes before being operated upon.

Thus both java implementation and compiler handling looks correct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From duke at openjdk.java.net  Tue Apr 26 17:48:51 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 26 Apr 2022 17:48:51 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v2]
In-Reply-To: <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
 <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
Message-ID: <qi9aTuCwK5HY17jEoJZfqa5syZID7JRn8wnduq7im0Y=.41688f30-dd02-4c89-89fb-c86152aa2d7f@github.com>

On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285658: Fix two typos in the spec of j.u.random.RandomGenerator

Should we use `{@value }` javadoc tag, which renders the literal in HTML but includes a link to the constant?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From darcy at openjdk.java.net  Tue Apr 26 18:57:57 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 26 Apr 2022 18:57:57 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v2]
In-Reply-To: <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
 <oFgi1n9Qy1C0lK7qpLxZFe6nIUXv3eqvna39pF3HPQI=.cec3e8e4-613d-4f53-a1e6-801e2ab918a9@github.com>
Message-ID: <wdCUtyfngBi2SY_SvyP76RMP2XJRNHAwatEVz8Q_Dqo=.88552f14-028a-4f84-8380-22823386731b@github.com>

On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285658: Fix two typos in the spec of j.u.random.RandomGenerator

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/java/util/random/RandomGenerator.java line 501:

> 499:      *
> 500:      * @implSpec The default implementation uses the {@link Float#PRECISION}
> 501:      * high-order bits from a call to {@link RandomGenerator#nextInt() nextInt}().

Typographical nit: please include the "()" inside the link tag for both methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From dfuchs at openjdk.java.net  Tue Apr 26 19:02:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Apr 2022 19:02:19 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <pIfEEExSisxawbX9SPnCGSEBt-gkqBpOY2b7P_ByPNU=.f8d5242e-acfb-41fa-87e7-24054007cd9b@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770:

> 768:         synchronized (p) {
> 769:             DatagramPackets.setLength(p, n);
> 770:             p.setSocketAddress(sender);

Hmmm... For integrity it might be better to call the public  `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to  `DatagramPackets.setLength(p, n);` will no longer be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From hseigel at openjdk.java.net  Tue Apr 26 19:04:10 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 26 Apr 2022 19:04:10 GMT
Subject: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
 [v3]
In-Reply-To: <dcpCPCeaLFDRRzDOtjGRKHqbeZGX7KPUAsTtlR5d-NU=.cc35c9de-7020-4ed4-b135-ed7932b534c2@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
 <dcpCPCeaLFDRRzDOtjGRKHqbeZGX7KPUAsTtlR5d-NU=.cc35c9de-7020-4ed4-b135-ed7932b534c2@github.com>
Message-ID: <AOOf4zZJr1theJxgPBAgxwL9KpJpIDBjnVBbMdSUoCk=.904f114c-79c2-4735-a39d-b9871555bf4f@github.com>

On Mon, 25 Apr 2022 14:26:17 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix globals.hpp text

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From hseigel at openjdk.java.net  Tue Apr 26 19:04:12 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 26 Apr 2022 19:04:12 GMT
Subject: Integrated: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
In-Reply-To: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
References: <B6GwPtWav3mxrcIDy88YykVcWM1UnDO87y8pnIHor74=.ebe49cf4-7e86-41c2-8814-12e40f618192@github.com>
Message-ID: <ZJbJFGEm1tlpqjZW8S0C7P_1UrMinJ_ytuKSVu87YXI=.8de64c8c-ba29-47b0-9ce6-cc3d6bc78840@github.com>

On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8284642.  The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  Additionally, the modified test and the test in the bug report were run locally.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 975a060a
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/975a060ade6e11b021222ae7f7a2de0d0c041308
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

Reviewed-by: stuefe, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/8222

From jlahoda at openjdk.java.net  Tue Apr 26 19:30:32 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 26 Apr 2022 19:30:32 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v7]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <iuX8CUmNyg1ZsRXBM78U4NZ3bE_uRsY_V204tb1HykA=.e44660c8-666a-4706-825e-8eb55e702d0c@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - Adding a test for a NPE from guards.
 - Cleanup
 - Merge branch 'master' into type-patterns-third
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/82f0ac02...9f290cd2

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=06
  Stats: 888 lines in 52 files changed: 453 ins; 244 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jvernee at openjdk.java.net  Tue Apr 26 19:33:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 26 Apr 2022 19:33:53 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
In-Reply-To: <rU8vgD7Yd5t9E-jYTvNH_Cbo0HgoG2ed3Kb3ni6GxKc=.24772463-884e-465b-8151-61aa4c4cc60f@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
 <dNRWkadihwc2yJOM1CEejaXuNXIyrAIS0UH3oGnPeIw=.c4fa5366-c2df-47f7-9282-f8bf4d78870f@github.com>
 <rU8vgD7Yd5t9E-jYTvNH_Cbo0HgoG2ed3Kb3ni6GxKc=.24772463-884e-465b-8151-61aa4c4cc60f@github.com>
Message-ID: <pQU-u0ii9X6JoW4ycs4lZx7HKttbcoDYIX_TPw901cg=.74984269-e713-41be-81e8-7ab273db0806@github.com>

On Tue, 26 Apr 2022 17:20:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line 104:
>> 
>>> 102:     @Benchmark
>>> 103:     public MethodType testMultiPType_ObjectOnly() {
>>> 104:         return MethodType.methodType(Object.class, Object.class, Object.class, Object.class, Object.class, Object.class, Object.class);
>> 
>> It might be interesting to add a benchmark where all types are `Object`, but non-constants, to see if that case improves as well.
>
> Right.. I did a quick experiment and there's a large speed-up in the trivial `methodType(obj, obj)` case:
> 
> Benchmark                                      Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  30.052 ? 3.440  ns/op # baseline
> MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  1.171  ? 0.001  ns/op # patch
> 
> 
> I'll add a non-constant variant for the multi-arg Object variants, too. It should scale linearly and see a gain in the same ballpark. I think we need to keep the number of microbenchmarks here somewhat under control, though.

That sounds good, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From dcubed at openjdk.java.net  Tue Apr 26 19:44:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 26 Apr 2022 19:44:21 GMT
Subject: Integrated: 8285677: ProblemList two tests from JDK-8285671 on
 macosx-x64
Message-ID: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>

A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64.

-------------

Commit messages:
 - 8285677: ProblemList two tests from JDK-8285671 on macosx-x64

Changes: https://git.openjdk.java.net/jdk/pull/8406/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8406&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285677
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8406/head:pull/8406

PR: https://git.openjdk.java.net/jdk/pull/8406

From dfuchs at openjdk.java.net  Tue Apr 26 19:44:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Apr 2022 19:44:21 GMT
Subject: Integrated: 8285677: ProblemList two tests from JDK-8285671 on
 macosx-x64
In-Reply-To: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>
References: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>
Message-ID: <yuqTLqZrBuq8sKOnajUfHXNcNqhV0tRkuq5opPLLsuw=.ae660178-4461-409b-aae8-a5cb01b520fc@github.com>

On Tue, 26 Apr 2022 19:35:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64.

LGTM Dan. Thanks for taking care of that!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8406

From dcubed at openjdk.java.net  Tue Apr 26 19:44:22 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 26 Apr 2022 19:44:22 GMT
Subject: Integrated: 8285677: ProblemList two tests from JDK-8285671 on
 macosx-x64
In-Reply-To: <yuqTLqZrBuq8sKOnajUfHXNcNqhV0tRkuq5opPLLsuw=.ae660178-4461-409b-aae8-a5cb01b520fc@github.com>
References: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>
 <yuqTLqZrBuq8sKOnajUfHXNcNqhV0tRkuq5opPLLsuw=.ae660178-4461-409b-aae8-a5cb01b520fc@github.com>
Message-ID: <shuVi5EGSibBeHcPjiBsFjIsPbSsF9Ip2-LUclSOfGY=.8b88eae0-be33-49b2-b3f2-47fa1637bcf4@github.com>

On Tue, 26 Apr 2022 19:39:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64.
>
> LGTM Dan. Thanks for taking care of that!

@dfuch - Thanks for the fast review! And no worries about handling
the ProblemListing...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8406

From dcubed at openjdk.java.net  Tue Apr 26 19:44:23 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 26 Apr 2022 19:44:23 GMT
Subject: Integrated: 8285677: ProblemList two tests from JDK-8285671 on
 macosx-x64
In-Reply-To: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>
References: <Z4TfWX5l_lxhSh79gNrgQboR637Lo_sa7kp3t1q_EoM=.479e0142-3582-4bcd-ae0e-af6e8524b51d@github.com>
Message-ID: <puYnOwgknllRGoApqSGxizpiRAOUuIGZ1-y6odHNMnY=.6d85042a-73bc-4f90-9a6c-d36f96e5eac8@github.com>

On Tue, 26 Apr 2022 19:35:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64.

This pull request has now been integrated.

Changeset: e3d714d3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e3d714d37e2679a4f8046d78964292a876bbe3d6
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8285677: ProblemList two tests from JDK-8285671 on macosx-x64

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8406

From ecki at zusammenkunft.net  Tue Apr 26 19:46:58 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 26 Apr 2022 19:46:58 +0000
Subject: Regression after April Java 17 Update (mime types)
In-Reply-To: <PAXPR02MB7799C331228DB6CA2B86969F8AFB9@PAXPR02MB7799.eurprd02.prod.outlook.com>
References: <AM9P193MB1142B45AEA22E0D905602BD9FFF89@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <PAXPR02MB7799C331228DB6CA2B86969F8AFB9@PAXPR02MB7799.eurprd02.prod.outlook.com>
Message-ID: <AM9P193MB11421AE1A340C63362BFAF21FFFB9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello Christoph,

The actual release notes I initially looked up are the April  Release notes from Azul (17.34) for 17.0.3. I already opened a case there. However I then also checked the Oracle Release Notes (I thought they would contain the same 17.0.3 changes).

The incompatibility in VFS was actually a shortcoming in VFS: if you want to determine who can handle a file type it would check the mime type or the extension. But it was coded in a way that if it has a mime type but no handler for that type it won?t check for the file extension. This way it could no longer browser URLs ending in .jar or uncompres .go files (or generally all files where there was previously only a file extension handler registered).

I would asume this negative consequences is hard to predict, especially since VFS could in this case prevemt it. However for an application it is unfortunate that this breaks (especially when hoping to ship a quarterly security update quickly). Bit generally it?s a noteworthy new feature.

Thanks for the reminder of the Shipilev release notes, I did actually not check them after looking at two vendors (and not finding a Release announcement mail like there was one for 17.0.2. Can I asume those are no longer sent after X.0.2 is published? I guess my comment to ?not including it in the release notes? was not valid for the OpenJDK Updates project and I will take it up with Azul to check the source they are using.

If you want to look deeper into this:

The VFS logic might be a bit hard to follow, it basically works on URLs and it has a filesystem layering mode which checks on mime type and/or extension: https://issues.apache.org/jira/browse/VFS-770
This is the actual fix commit for it: https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305
It is retrieving the contentType for a URL here https://github.com/apache/commons-vfs/blob/64da24778ea075ffc5de8588a29a0f50c6c8d94e/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java#L41

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Langer, Christoph <christoph.langer at sap.com>
Gesendet: Tuesday, April 26, 2022 5:18:38 PM
An: Bernd Eckenfels <ecki at zusammenkunft.net>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: RE: Regression after April Java 17 Update (mime types)

Hi Bernd,

I just noticed your report regarding the regression after JDK-8273655. I'm directing this communication to jdk-updates-dev now as it seems more appropriate.

I assume with release notes you're referring to the Oracle 17.0.3 release notes? This change, if you look closely at the backports, was only brought to OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it would not be reflected in Oracle release notes. The best you can get for OpenJDK 17.0.3 release notes is [0], to my knowledge.

Do you have some more information regarding the incompatibility? What I'm understanding is that this backport unveils a problem with Apache VFS? Do you have a bug link for that one? If it's just uncovering a bug in another 3rd party software, I assume it doesn't merit a backout, though.

Best regards
Christoph

[0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html


> -----Original Message-----
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> On Behalf Of Bernd
> Eckenfels
> Sent: Montag, 25. April 2022 19:39
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Regression after April Java 17 Update (mime types)
>
> Hello,
>
> We just tried to push out the Java 17 April Update but it failed with some
> incompatible behavior. We found out it is caused due to a new mime-type (and
> a bug in Apache VFS) that JAR files could no longer be opened in an overlay
> (technically a JAR URL suddenly had a mime-type and therefore VFS no longer
> looked at the file extension).
>
> Just wanted to give a heads up in case anybody else has that problem. The
> change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release
> notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the
> OpenJDK announcement?
>
> This specific case is a changed behavior (even when it has rather unexpected
> negative consequences), it would be therefore good to be called out
> specifically.
>
> Gruss
> Bernd
>
>
> --
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck
> enfels.net%2F&amp;data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f
> 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7
> C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8
> %3D&amp;reserved=0

From redestad at openjdk.java.net  Tue Apr 26 20:47:39 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Apr 2022 20:47:39 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
 [v2]
In-Reply-To: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
Message-ID: <k5X4ULRh_UuKLGzBirDiEA9lyrGTqnVMIaMrXtKLiic=.22f840d3-897c-40b9-9489-ef270ea425e7@github.com>

> The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.
> 
> Baseline:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.673 ? 0.017  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.579 ? 0.125  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  46.671 ? 1.134  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  27.019 ? 0.437  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  57.217 ? 0.505  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15  57.114 ? 1.214  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15  33.380 ? 1.810  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.043 ? 0.187  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15  24.313 ? 0.074  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.360 ? 0.155  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.572 ? 1.101  ns/op
> 
> 
> Patched:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.683 ? 0.024  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.547 ? 0.047  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  48.532 ? 0.982  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  31.390 ? 5.269  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  60.165 ? 2.756  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15   0.599 ? 0.166  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15   0.541 ? 0.045  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.174 ? 0.257  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15   0.542 ? 0.045  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.621 ? 0.202  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.614 ? 1.109  ns/op
> 
> 
> The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost (~3ns/op, with overlapping error).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add micros using non-constant arguments to assess performance in absense of constant folding

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8398/files
  - new: https://git.openjdk.java.net/jdk/pull/8398/files/6d2edc59..fcc020e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=00-01

  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8398/head:pull/8398

PR: https://git.openjdk.java.net/jdk/pull/8398

From redestad at openjdk.java.net  Tue Apr 26 21:00:54 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 26 Apr 2022 21:00:54 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
 [v2]
In-Reply-To: <pQU-u0ii9X6JoW4ycs4lZx7HKttbcoDYIX_TPw901cg=.74984269-e713-41be-81e8-7ab273db0806@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
 <dNRWkadihwc2yJOM1CEejaXuNXIyrAIS0UH3oGnPeIw=.c4fa5366-c2df-47f7-9282-f8bf4d78870f@github.com>
 <rU8vgD7Yd5t9E-jYTvNH_Cbo0HgoG2ed3Kb3ni6GxKc=.24772463-884e-465b-8151-61aa4c4cc60f@github.com>
 <pQU-u0ii9X6JoW4ycs4lZx7HKttbcoDYIX_TPw901cg=.74984269-e713-41be-81e8-7ab273db0806@github.com>
Message-ID: <GOe_p96KdZLOk5gINxBZOq5RgCio5KtXc72ERcwjJTo=.4c545bac-e339-415b-9328-f6fbce3123d2@github.com>

On Tue, 26 Apr 2022 19:30:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Right.. I did a quick experiment and there's a large speed-up in the trivial `methodType(obj, obj)` case:
>> 
>> Benchmark                                      Mode  Cnt   Score   Error  Units
>> MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  30.052 ? 3.440  ns/op # baseline
>> MethodTypeAcquire.testObjectObjectNonConstant  avgt    5  1.171  ? 0.001  ns/op # patch
>> 
>> 
>> I'll add a non-constant variant for the multi-arg Object variants, too. It should scale linearly and see a gain in the same ballpark. I think we need to keep the number of microbenchmarks here somewhat under control, though.
>
> That sounds good, thanks

Added 3 micros I think carry their own weight as they assess some different major pathways through the caching fast-path.

Baseline:

Benchmark                                             Mode  Cnt   Score   Error  Units
MethodTypeAcquire.testMultiPType_ObjectAndA_NonConst  avgt   15  63.523 ? 2.452  ns/op
MethodTypeAcquire.testMultiPType_ObjectOnly_NonConst  avgt   15  57.770 ? 0.501  ns/op
MethodTypeAcquire.testObjectObject_NonConst           avgt   15  30.090 ? 0.251  ns/op

Patched:

Benchmark                                             Mode  Cnt   Score    Error  Units
MethodTypeAcquire.testMultiPType_ObjectAndA_NonConst  avgt   15  64.570 ?  0.410  ns/op
MethodTypeAcquire.testMultiPType_ObjectOnly_NonConst  avgt   15   4.735 ?  0.063  ns/op
MethodTypeAcquire.testObjectObject_NonConst           avgt   15   1.171 ?  0.001  ns/op

The relative speed-up diminishes a bit for the loopy 6-arg `methodType` calls, but is still a healthy 12x. Overhead on the negative test might be there but is very much in the noise on my tests (tried doubling warmup time to no avail)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From duke at openjdk.java.net  Tue Apr 26 21:15:49 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 26 Apr 2022 21:15:49 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
Message-ID: <_wwF-r6XfbTRC-aiQsjlgLYH_jvXK5izdteClNxqnoU=.60c86172-6b83-418e-b0f0-2ebae9c6b5ec@github.com>

On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes in MethodType

Let's wait a bit

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From naoto at openjdk.java.net  Tue Apr 26 21:20:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 26 Apr 2022 21:20:49 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>

On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Thanks for fixing the issue.
As to the test, it has lots of redundancy, and too complicated to me. Can you simplify the test?

src/java.base/unix/classes/java/lang/ProcessImpl.java line 146:

> 144:     private static final LaunchMechanism launchMechanism = platform.launchMechanism();
> 145:     private static final byte[] helperpath = toCString(StaticProperty.javaHome() + "/lib/jspawnhelper");
> 146:     private static Charset jnuCharset = null;

Can we simply call `jnuCharset()` here?

test/jdk/java/lang/ProcessBuilder/Basic.java line 605:

> 603:             String fileEncoding = System.getProperty("file.encoding");
> 604:             Charset cs;
> 605:             if (nativeEncoding != null && !nativeEncoding.equals(fileEncoding)) {

What's the reason for comparing `file.encoding`? Does `Charset.forName(nativeEncoding, Charset.defaultCharset())` suffice?

test/jdk/java/lang/System/i18nEnvArg.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8285517

If the test should work only on a particular env, should describe here and add `@requires`  tag.

test/jdk/java/lang/System/i18nEnvArg.java line 50:

> 48: 
> 49:     public static void main(String[] args) throws Exception {
> 50:         ProcessBuilder pb = new ProcessBuilder(javeExe,

Can utilize `jdk.test.lib.process.ProcessTools`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From psandoz at openjdk.java.net  Tue Apr 26 21:56:57 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 26 Apr 2022 21:56:57 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
In-Reply-To: <QfD7xu2hGja_ind5uiq5P7B8p5ImQIQ_Mn-bM6qrVTo=.e2f541aa-ce51-406f-b3b3-5acb69cc1ffd@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <QfD7xu2hGja_ind5uiq5P7B8p5ImQIQ_Mn-bM6qrVTo=.e2f541aa-ce51-406f-b3b3-5acb69cc1ffd@github.com>
Message-ID: <Lw7M9isvnPBvwSBR4TAMVQU00hLz9glVQSipBwabRP8=.ce2069b7-0a95-40ce-bc97-dc9ebf01ff1a@github.com>

On Thu, 21 Apr 2022 04:23:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - 8284992: Fix misleading Vector API doc for LSHR operator

After talking with John here's what we think is a better approach than what I originally had in mind:
1. In the class doc of `VectorOperators` add a definition for `EMASK` occurring after the definition for `ESIZE`:

 * <li>{@code EMASK} &mdash; the bit mask of the operand type, where {@code EMASK=(1<<ESIZE*8)-1} 

2. Change `LSHR` to be:

/** Produce {@code (a&EMASK)>>>(n&(ESIZE*8-1))}.  Integral only. */

That more clearly gets across operating in the correct domain for sub-word operand types, which was the original intention (e.g. the right shift value).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From vdyakov at openjdk.java.net  Tue Apr 26 22:10:19 2022
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 26 Apr 2022 22:10:19 GMT
Subject: RFR: JDK-8236128: Allow jpackage create installers for services
 [v2]
In-Reply-To: <R2KLGE__w7gzMOpSvhUIAGy2DDNK1DwppVQjiZ8MZb0=.37254868-119d-488f-ba1a-f3581d252e8e@github.com>
References: <Rc1qJzW40px0VvmFGDZBcQ-Ow3w7ubJNmzHu7PkSmQE=.7d67b399-5d2f-4537-9275-4ae9b88ed33f@github.com>
 <R2KLGE__w7gzMOpSvhUIAGy2DDNK1DwppVQjiZ8MZb0=.37254868-119d-488f-ba1a-f3581d252e8e@github.com>
Message-ID: <z3x-B9ZcFpYgvokO_mPx3uechLSAHmRxjG9wj2_b0zY=.051877c7-543e-426c-9032-2f027228aea4@github.com>

On Thu, 14 Apr 2022 21:04:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
>>  CSR
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 121 commits:
> 
>  - Merge branch 'master' into JDK-8236128
>  - Whitespace cleanup
>  - Whitespace cleanup
>  - JDK-8236128: Allow jpackage create installers for services
>  - Sync l10n files. Fix copyright year
>  - Minor formatting fix
>  - Merge fix
>  - Merge fixed
>  - Merge branch 'master' into JDK-8236128
>  - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk into JDK-8236128
>  - ... and 111 more: https://git.openjdk.java.net/jdk/compare/f4edb59a...1a3d7cf5

Approved

-------------

PR: https://git.openjdk.java.net/jdk/pull/7793

From darcy at openjdk.java.net  Tue Apr 26 22:33:21 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 26 Apr 2022 22:33:21 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
Message-ID: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>

To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.

To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.

Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).

I'll update copyright years before pushing.

-------------

Commit messages:
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

Changes: https://git.openjdk.java.net/jdk/pull/8410/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285676
  Stats: 76 lines in 40 files changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410

From wetmore at openjdk.java.net  Tue Apr 26 23:05:58 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 23:05:58 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Mrv3-W6N7gjMctLzqz8_Dq_MPIoUkqUa2N0Gbg9Xf7g=.f0b54b3f-1f6b-4f9b-bac5-e29f1fe6aff5@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

The two `java.security` ones LGTM.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410

From jjg at openjdk.java.net  Tue Apr 26 23:38:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Apr 2022 23:38:42 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <MURKJqzm5cRIvi152qaevEt30OPStqQaWymnG2TkkBA=.f8562675-7851-4f1d-8854-94acd825c47b@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

src/java.base/share/classes/java/lang/ClassValue.java line 43:

> 41:  * it can use a {@code ClassValue} to cache information needed to
> 42:  * perform the message send quickly, for each class encountered.
> 43:  * @param <T> type of the derived value

stylistically, compared to other comments, you are missing an initial "the"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From smarks at openjdk.java.net  Wed Apr 27 01:48:49 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 01:48:49 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

I've looked at the changes in java.util (but not sub packages). They're fine, modulo some minor wording changes.

src/java.base/share/classes/java/util/AbstractMap.java line 601:

> 599:      * {@code Map.entrySet().toArray}.
> 600:      *
> 601:      * @param <K> the type of keys maintained

Please update to match java.util.Map, which says "the type of keys maintained by this map"

src/java.base/share/classes/java/util/AbstractMap.java line 748:

> 746:      *
> 747:      * @param <K> the type of keys maintained
> 748:      * @param <V> the type of mapped values

Please update to match Map.Entry, which says simply "the type of key" and "the type of the value"

src/java.base/share/classes/java/util/Dictionary.java line 44:

> 42:  * @param <K> the type of keys
> 43:  * @param <V> the type of mapped values
> 44:  *

Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410

From smarks at openjdk.java.net  Wed Apr 27 03:24:16 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 03:24:16 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
Message-ID: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>

Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

-------------

Commit messages:
 - Refactor contents checking to use checkElements() and checkEntries().
 - Rename some tests.
 - Rename isIdenticalEntry to hasIdenticalKeyValue.
 - Finish writing all pending tests except remove(k,v) and replace(k,v1,v2).
 - Some cleanup and more tests.
 - Initial cut at IdentityHashMap tests.

Changes: https://git.openjdk.java.net/jdk/pull/8354/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8354&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285295
  Stats: 546 lines in 1 file changed: 546 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354

PR: https://git.openjdk.java.net/jdk/pull/8354

From duke at openjdk.java.net  Wed Apr 27 03:24:17 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 27 Apr 2022 03:24:17 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <t-qr6twHFQChMhkxeAaDsn2BVnvmncYla_2i3-jmXYk=.e3d3622e-92e6-44d6-9010-7704b96d15f0@github.com>

On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

Just curious, will entrySet/keySet/values tests be here or in a separate file? They are identity-based collections as well, as shown by their contains/removeAll/retainAll.

test/jdk/java/util/IdentityHashMap/Basic.java line 75:

> 73:     private <E> void checkContents(Collection<E> c, BiPredicate<E,E> p, E... given) {
> 74:         @SuppressWarnings("unchecked")
> 75:         E[] contents = (E[]) c.toArray();

Maybe worthy to note that entry set toArray may return entries different from what the iterator returns, and some predicates may thus fail.

test/jdk/java/util/IdentityHashMap/Basic.java line 77:

> 75:         E[] contents = (E[]) c.toArray();
> 76: 
> 77:         assertEquals(c.size(), given.length);

I believe testng has the expected values in front in the `assertEquals` methods, as embodied in the exception messages, so this should be `assertEquals(given.length, c.size());`. Applies to other places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Wed Apr 27 03:24:17 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 03:24:17 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <BgOF3Kx54j0d5J8GkqQ0uYuec14H8KHxUnu8J_n-zBs=.4f87eb9b-1bf3-424e-94d7-afc71aa8ebe0@github.com>

On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

Probably the same file. It would be nice to be able to re-use some general Set and Collection tests, but the identity semantics make this difficult to do without extensive refactoring.

**

Oh wait, `removeAll` and `retainAll` use the membership contract of the argument, not those of this collection. The current keySet/values/entrySet tests test `toArray` and `contains`, which seems almost sufficient. Well, maybe tests for `remove` on these view collections would be helpful, but I think that's about it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Wed Apr 27 03:31:34 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 03:31:34 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <t-qr6twHFQChMhkxeAaDsn2BVnvmncYla_2i3-jmXYk=.e3d3622e-92e6-44d6-9010-7704b96d15f0@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <t-qr6twHFQChMhkxeAaDsn2BVnvmncYla_2i3-jmXYk=.e3d3622e-92e6-44d6-9010-7704b96d15f0@github.com>
Message-ID: <rWmdhDSYjBiRMBYe0JC9kialPedRcu2slvhNtkgWu3E=.55893817-ffcb-4cc4-ac40-16a3c5d2e441@github.com>

On Wed, 27 Apr 2022 03:11:58 GMT, liach <duke at openjdk.java.net> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 75:
> 
>> 73:     private <E> void checkContents(Collection<E> c, BiPredicate<E,E> p, E... given) {
>> 74:         @SuppressWarnings("unchecked")
>> 75:         E[] contents = (E[]) c.toArray();
> 
> Maybe worthy to note that entry set toArray may return entries different from what the iterator returns, and some predicates may thus fail.

Yeah I could add a note to caution against checking identity of `Entry` instances. That doesn't occur anywhere in these tests, does it?

> test/jdk/java/util/IdentityHashMap/Basic.java line 77:
> 
>> 75:         E[] contents = (E[]) c.toArray();
>> 76: 
>> 77:         assertEquals(c.size(), given.length);
> 
> I believe testng has the expected values in front in the `assertEquals` methods, as embodied in the exception messages, so this should be `assertEquals(given.length, c.size());`. Applies to other places.

No, TestNG is `assertEquals(actual, expected)` which is irritatingly the opposite of JUnit.

https://github.com/cbeust/testng/blob/master/testng-asserts/src/main/java/org/testng/asserts/Assertion.java#L151

This will make things quite tedious when/if we convert to JUnit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From alanb at openjdk.java.net  Wed Apr 27 06:26:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 06:26:50 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <pIfEEExSisxawbX9SPnCGSEBt-gkqBpOY2b7P_ByPNU=.f8d5242e-acfb-41fa-87e7-24054007cd9b@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
 <pIfEEExSisxawbX9SPnCGSEBt-gkqBpOY2b7P_ByPNU=.f8d5242e-acfb-41fa-87e7-24054007cd9b@github.com>
Message-ID: <VgFJJHMV5PCi9kbe1kmHwxXz9ZdvuQglcUAzgbrx13Y=.71892dc5-d1b3-4241-a7d2-dd50f4a3a707@github.com>

On Tue, 26 Apr 2022 18:58:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>
> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770:
> 
>> 768:         synchronized (p) {
>> 769:             DatagramPackets.setLength(p, n);
>> 770:             p.setSocketAddress(sender);
> 
> Hmmm... For integrity it might be better to call the public  `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to  `DatagramPackets.setLength(p, n);` will no longer be needed.

DatagramPackets.setLength is not really new, it's just moved. There's a flaw in DatagramPacket that forces its usage -  the details are in JDK-8232817.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Wed Apr 27 06:32:31 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 27 Apr 2022 06:32:31 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <uEUI0T4FZCx5Xzei1Y15lppkv6_Sgh9iePX4GyK7Q6Q=.8367d8ef-f74c-4b57-a472-fb4db4cc1301@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Looks fine to me.

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8364

From jpai at openjdk.java.net  Wed Apr 27 06:43:53 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 27 Apr 2022 06:43:53 GMT
Subject: RFR: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <H9YDX_YiYim_p9VRG0XNWjDqGEVZGZdl0t0cvFe6yR0=.99ace24c-2170-4349-a0df-699e992a7e9b@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
 <JAkoUdNyuiQQ761EaxXiD8np4IUaI0xkrrh_itxBrAg=.ee5d089a-6c1e-46a7-a006-4ed1bdc00f05@github.com>
 <esVzcnvNse9z5fKF5JV_ylzFNQOTe5aawBztlttMRkw=.44654865-2cce-4b32-be4d-245ba3ece07e@github.com>
 <a6O5WHpThRFhgr_TLQ4uWbajfMMCjvLEA436bIZwy2Y=.44f38ddb-ff4f-40c8-9259-0ee9a44d612a@github.com>
 <H9YDX_YiYim_p9VRG0XNWjDqGEVZGZdl0t0cvFe6yR0=.99ace24c-2170-4349-a0df-699e992a7e9b@github.com>
Message-ID: <7cSDG1gX4PxUPl68RPsU1heJZ6k60Bp1sip4k3Tfczk=.fc81d2c7-1743-4b9c-99b6-fddec4a434e6@github.com>

On Fri, 22 Apr 2022 08:04:09 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

>> Hello @izeye, I've created a JBS issue for this change https://bugs.openjdk.java.net/browse/JDK-8285440. Please edit the title of this PR to "8285440: Typo in Collections.addAll method javadoc" so that it triggers the workflow of the official review process.
>
> @jaikiran Thanks! I updated the title as you guided.

@izeye, this is now ready for integration. You will have to add a comment to this PR which says `/integrate`, after which I can sponsor this change to have it merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From sundar at openjdk.java.net  Wed Apr 27 06:43:56 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 27 Apr 2022 06:43:56 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <YL_YZOMz5aRKDYJD5THtdj9mOJL54kF2GfTBMA5f20g=.17c024be-503f-407a-8262-2d2ac78480e5@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

LGTM

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:

> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 187: 
> 188: main.plugin.category=\u7C7B\u522B

what's this?

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8364

From duke at openjdk.java.net  Wed Apr 27 07:34:29 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 27 Apr 2022 07:34:29 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v3]
In-Reply-To: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
Message-ID: <_QR6czh1e6cOfUNpb3SUiDPjfShKAPeGIALbCmfcKqs=.af2b4a97-9dab-4ceb-ad57-294103d8028c@github.com>

> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8285658: Fix two typos in the spec of j.u.random.RandomGenerator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8404/files
  - new: https://git.openjdk.java.net/jdk/pull/8404/files/8d4388bd..b33cfa30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404

PR: https://git.openjdk.java.net/jdk/pull/8404

From rpressler at openjdk.java.net  Wed Apr 27 07:36:00 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Wed, 27 Apr 2022 07:36:00 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
In-Reply-To: <VlbnqGXvp0l0Rabuwu2jvOowuzdntzlHQvXtqyasY3Q=.73e6a6af-ed8a-42f7-8083-e4bd2e0dce77@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com>
 <VlbnqGXvp0l0Rabuwu2jvOowuzdntzlHQvXtqyasY3Q=.73e6a6af-ed8a-42f7-8083-e4bd2e0dce77@github.com>
Message-ID: <lWWkCpYB4yCr-mAWNqk2-6Ku5vQAxTr3KOFnVat-Zis=.6a276d13-c93d-40a7-855e-e27a99d5ebc1@github.com>

On Mon, 25 Apr 2022 20:48:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh
>
> test/jdk/jdk/internal/vm/Continuation/Basic.java line 327:
> 
>> 325: 
>> 326:     // @Test
>> 327:     public void testPinnedNative() {
> 
> Are you disabling this test?  if so, you can do `@Test(enabled=false)`

I updated the test and enabled it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From rehn at openjdk.java.net  Wed Apr 27 08:46:55 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 27 Apr 2022 08:46:55 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <P6wLqjusUEMmCs4tHXfIKDKYLEyvWTbi-Gj7XNJBexs=.30714604-edc2-4a3d-98a1-9c8940c9ef2f@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

I have looked mostly on runtime, and to much lesser extent the others parts.
There are some loose ends, but nothing major that can't wait, so I think it's time.
Looks fine, thanks.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From jiefu at openjdk.java.net  Wed Apr 27 09:06:14 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Apr 2022 09:06:14 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
In-Reply-To: <Lw7M9isvnPBvwSBR4TAMVQU00hLz9glVQSipBwabRP8=.ce2069b7-0a95-40ce-bc97-dc9ebf01ff1a@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <QfD7xu2hGja_ind5uiq5P7B8p5ImQIQ_Mn-bM6qrVTo=.e2f541aa-ce51-406f-b3b3-5acb69cc1ffd@github.com>
 <Lw7M9isvnPBvwSBR4TAMVQU00hLz9glVQSipBwabRP8=.ce2069b7-0a95-40ce-bc97-dc9ebf01ff1a@github.com>
Message-ID: <uwGCzztpasvsdI_kqKbFmESigFtzDw8D0Clzvf8uJMg=.ba8ba91b-6d27-4a9b-8f2d-578d8809a2b0@github.com>

On Tue, 26 Apr 2022 21:41:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> After talking with John here's what we think is a better approach than what I originally had in mind:
> 
> 1. In the class doc of `VectorOperators` add a definition for `EMASK` occurring after the definition for `ESIZE`:
> 
> ```
>  * <li>{@code EMASK} &mdash; the bit mask of the operand type, where {@code EMASK=(1<<ESIZE*8)-1} 
> ```
> 
> 2. Change `LSHR` to be:
> 
> ```
> /** Produce {@code (a&EMASK)>>>(n&(ESIZE*8-1))}.  Integral only. */
> ```
> 
> That more clearly gets across operating in the correct domain for sub-word operand types, which was the original intention (e.g. the right shift value).

Good suggestion!
This makes sense to me.

Updated.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From jiefu at openjdk.java.net  Wed Apr 27 09:06:12 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Apr 2022 09:06:12 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Address review comments
 - Merge branch 'master' into JDK-8284992
 - Merge branch 'master' into JDK-8284992
 - Address review comments
 - Merge branch 'master' into JDK-8284992
 - 8284992: Fix misleading Vector API doc for LSHR operator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8291/files
  - new: https://git.openjdk.java.net/jdk/pull/8291/files/1c7f4584..7e82e721

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=01-02

  Stats: 8171 lines in 245 files changed: 5201 ins; 1132 del; 1838 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Wed Apr 27 09:07:04 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Wed, 27 Apr 2022 09:07:04 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
Message-ID: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>

When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.

Would you please review this fix?

-------------

Commit messages:
 - 8238373: Punctuation should be same in jlink help usage on Japanese language

Changes: https://git.openjdk.java.net/jdk/pull/8417/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8417&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238373
  Stats: 18 lines in 6 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8417.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8417/head:pull/8417

PR: https://git.openjdk.java.net/jdk/pull/8417

From jiefu at openjdk.java.net  Wed Apr 27 09:16:34 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Apr 2022 09:16:34 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <BZW29EXUQ-S7r_PO1Mcl2j3F-6Tcwezu5JWd00F3pJg=.c56a48e5-0b4c-4999-a69b-bc502abba40f@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <BZW29EXUQ-S7r_PO1Mcl2j3F-6Tcwezu5JWd00F3pJg=.c56a48e5-0b4c-4999-a69b-bc502abba40f@github.com>
Message-ID: <m6HFoR5G4jcLyFzY1JcZT6oTEISckMd-ahRlqC-dOmg=.dfea1f9d-bd70-48bb-9a09-7efeb942c6a5@github.com>

On Tue, 26 Apr 2022 17:31:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > According to the Vector API doc, the LSHR operator computes a>>>(n&(ESIZE*8-1))
> 
> Documentation is correct if viewed strictly in context of subword vector lane, JVM internally promotes/sign extends subword type scalar variables into int type, but vectors are loaded from continuous memory holding subwords, it will not be correct for developer to imagine that individual subword type lanes will be upcasted into int lanes before being operated upon.
> 
> Thus both java implementation and compiler handling looks correct.

Thanks @jatin-bhateja for taking a look at this.
After the discussion, I think it's fine to keep the current implementation of LSHR.
So we're now fixing the misleading doc here: https://github.com/openjdk/jdk/pull/8291 .

And I think it would be better to add one more operator for `>>>`.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From ssahoo at openjdk.java.net  Wed Apr 27 09:25:53 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 27 Apr 2022 09:25:53 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <R6C15dUB4U0epQ4kRf8d3cO1yS6KOeDYJZqwvBkGUoo=.ecfac2d5-99fb-4243-8335-51040e371f26@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

I can provide additional Test to Test this Test library.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From kbarrett at openjdk.java.net  Wed Apr 27 09:30:03 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 27 Apr 2022 09:30:03 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException
Message-ID: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>

Please review this fix to test/jdk/java/lang/ref/ReferenceClone.java.  It was
passing if CloneableReference::clone were to throw CloneNotSupportedException.
That should be a failure.

Testing:
Locally (linux-x64) verified test still passes.  Temporarily changed
CloneableReference::clone to throw and verified the expected failure gets
reported, unlike before.

-------------

Commit messages:
 - fail test if CloneableReference throws CloneNotSupportedException

Changes: https://git.openjdk.java.net/jdk/pull/8418/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8418&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285690
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8418.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8418/head:pull/8418

PR: https://git.openjdk.java.net/jdk/pull/8418

From sspitsyn at openjdk.java.net  Wed Apr 27 09:36:16 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 27 Apr 2022 09:36:16 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <uw2jRqWkBnqcRebvaf55H5r_NfKkKuN_T9_I0JA8iwk=.b7e5301f-c901-424a-bffc-7d1945048521@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

I've reviewed JDI, JDB and JDWP changes.
All look good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From stefank at openjdk.java.net  Wed Apr 27 09:52:43 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 27 Apr 2022 09:52:43 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <eTwHD-jLkaO6_bRyhSTyji43IBZyZU3nblxubPcN8FQ=.c630d3b5-8cd3-4a5c-b53e-105e4fff1a05@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

Similar comments to @fisk.

This is what I've been focusing on:
* In-depth:  gc/, oops/, memory/, utilities/
* Partially: runtime/
* Cleanups: hotspot/

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From tschatzl at openjdk.java.net  Wed Apr 27 10:00:39 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 27 Apr 2022 10:00:39 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <YXF3BRFSZbwXG8maBkho6FaDcCKZSnKoeBRqpbNmuS4=.fc687321-2e4c-4706-9c24-47d91b25e12d@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

Reviewed changes in gc/, oops/, memory/, partially in runtime/.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From kbarrett at openjdk.java.net  Wed Apr 27 10:11:15 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 27 Apr 2022 10:11:15 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
Message-ID: <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>

> Please review this fix to test/jdk/java/lang/ref/ReferenceClone.java.  It was
> passing if CloneableReference::clone were to throw CloneNotSupportedException.
> That should be a failure.
> 
> Testing:
> Locally (linux-x64) verified test still passes.  Temporarily changed
> CloneableReference::clone to throw and verified the expected failure gets
> reported, unlike before.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  update copyright, @bug list

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8418/files
  - new: https://git.openjdk.java.net/jdk/pull/8418/files/47043626..8f863628

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8418&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8418&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8418.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8418/head:pull/8418

PR: https://git.openjdk.java.net/jdk/pull/8418

From duke at openjdk.java.net  Wed Apr 27 10:22:16 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 10:22:16 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v3]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <njFoXkxTIyRfRaGfjyIMs1NinvB-feX2a_osfM5PibU=.a24b5d59-0200-48e1-983f-6ebb07f87a8f@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  add test in hotspot

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/cda7f85b..2defbf93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=01-02

  Stats: 38 lines in 3 files changed: 18 ins; 14 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From mcimadamore at openjdk.java.net  Wed Apr 27 10:25:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 27 Apr 2022 10:25:34 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v31]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <GchhUUYU46mxo_vVuefAxOwJM7E0utKzwm296TRIaAg=.501958fd-2607-4b01-8a67-9088d7f4c1c2@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge branch 'master' into foreign-preview
 - Add ValueLayout changes
 - Tweak support for array element var handle
 - Add @see
 - Initial push
 - Remove whitespaces
 - Drop `UnsupportedOperationException` from throws clause in FileChannel/FileChannelImpl
 - Add @ForceInline annotation on session accessor
   Beef up UnrolledAccess benchmark
 - Use a less expensive array element alignment check
   The bit to byte conversion shows up in hot paths
 - Fix UnrolledAccess benchmark
 - ... and 40 more: https://git.openjdk.java.net/jdk/compare/72f82dd7...746de5ce

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=30
  Stats: 65314 lines in 367 files changed: 43344 ins; 19432 del; 2538 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Wed Apr 27 10:31:21 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 10:31:21 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v4]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <4dW6RbWPbPD5zWkx_KmKQF4oa40qCwFSojo-38H6dT8=.1887e50c-28d7-4e55-9dbc-3d772d6ebec9@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  revert test file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/2defbf93..9bf30945

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=02-03

  Stats: 19 lines in 1 file changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed Apr 27 10:32:50 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 10:32:50 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v5]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <qhBU2a1lF-bULILYAi2FxG65N0i4u4oX7I9-tjoVOds=.e1bd32e8-997a-4f04-9389-00d3bbe90319@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  revert file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/9bf30945..f88ad50e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=03-04

  Stats: 18 lines in 1 file changed: 0 ins; 14 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed Apr 27 10:34:33 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 10:34:33 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v6]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  revert file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/f88ad50e..9dd1bbf3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From lancea at openjdk.java.net  Wed Apr 27 10:37:46 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Apr 2022 10:37:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <tw00X5u5ijFXjDPyGNnDazbwPRq3QH0aeozM_okAu5M=.e5c003fc-f55d-4d26-96cf-925647551b96@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

I have been through all of the tests and they look good.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From sminervini.prism at protonmail.com  Wed Apr 27 10:47:11 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Wed, 27 Apr 2022 10:47:11 +0000
Subject: Floating Point Repair?
Message-ID: <B07oVK5dIW_4UlWajbFJho9hLYFi4_XF7jPHpp-NHBdY46Tte8Xw5gSK7v19gtQlK6Okw3vN5GDbshNG-D-irlq5RRp-ktOTIKnkwleTHUE=@protonmail.com>

To the Java OpenJDK Java Community Process,

The way that we see float and double arithmetic and functions working is that a decimal value is submitted, maybe typed, and converted and stored in binary, operated on in binary, and the answer is successfully converted back to decimal. This appears to be a rational approach, given the way that all of Java's constructors, methods, fields, classes, interfaces and libraries are all oriented. Certainly given also the basic precept that binary is for computers and that decimal is for humans. Isn't this how all of IT should work, anyway?

IEE 754 doesn't specifically say anything about the base 10 digit degradations that can happen at the right hand side of float and double in numerous known examples, be it caused by representation, arithmetic, method calls, rounding, or anything else. However all examples like these, given the submitted understanding, become logic errors, that need to be repaired in either a default or mutual way, certainly an efficient way, simply because denary accuracy is required out of the compiled Java program, and for any further of that Java program.

The present workarounds, being BigInteger, BigDecimal, and the public, non-Oracle or OpenJDK, big-math, are too slow and too large in memory for key purposes, and don't allow for the use of arithmetic operators. Things that we need, as well as others too, further afield. While Valhalla may address some of these problems here, however far away that is, it still won't be as efficient and useful, but necessary, as decimal value range corrected float and double.

Our understanding is that the digit degredation can be repaired finitely, to work within values range, for float and double. Certainly given that generally, all method calls, and therefore all arithmetic operations, boil down to two binary numbers at a time with one operator, where the range of those two binary numbers is limited to the upper and lower range of the decimal number data that they have to have come from to start. Couldn't just a few extra registries always be able to capture just a smaller more amount of information, if all relevant maths is always innately two numbers, one operator, and the maximum decimal digit is 9, leading to the following telling result in little-endian binary,

910 = 10012 ?

What seems to be required is having, on top of two range value limits each for float and double, between minimum and maximum, float 32 bit and double 64 bit, hopefully when using an optimised floating point formula, maybe an adjustment of the present one,
is two more consideration range limits past the right hand side, past the smallest decimal digit. Extra SSE registers, or their descendents, exist in all relevant Java compatible CPU hardware for 32 bit and 64 bit registries in Floating Point Units in those CPUs. Can't these extra bit registries, even if outside of 32 and 64 bit, catch any extra-only bits, to tidyup the binary for the denary? Or is what may happen with SSE and RAM, or RAM on its own, a prohibitive consideration?

For decimal, with float and doubles, and the original view to them both, If changing the default is not an option, then surelya dual mode, compatability approach would address all concerns. Even a separate patch need not be out of reckoning.

Is all this thought and facthood and context enough to convince the JCP to genuinely do something to repair Java floating point errors, errors from the total range denary point of view?

Sent with [ProtonMail](https://protonmail.com/) secure email.

From remi.catherinot at orange.com  Wed Apr 27 10:56:31 2022
From: remi.catherinot at orange.com (remi.catherinot at orange.com)
Date: Wed, 27 Apr 2022 10:56:31 +0000
Subject: System.exit deadlock if called within a hook
In-Reply-To: <68e8a53c-6fdf-7f52-7148-f1cbe0977d1b@oracle.com>
References: <16407_1650892130_62669D62_16407_49_1_a86eaa38f9134a8aa551a0c27deb0d82@orange.com>
 <68e8a53c-6fdf-7f52-7148-f1cbe0977d1b@oracle.com>
Message-ID: <28455_1651056991_6269215F_28455_15_4_dff7f42d087c47ddb8d8a6b96daa2c9c@orange.com>

Ok,

Yes that would be hard to track down hooks "blocked" either directly or indirectly that way. Indirect blocking case are the hardest one, like a hook joining another thread that is blocked calling System.exit. This hook might really be blocked if joining again and again regardless of any join timeout/join interruption, and maybe just delayed because it joined with a timeout without retrying after a timeout: in both case, at some point, both logic (the blocked and not-so-blocked ones) have the same kind of stack and inter-thread join sequence. So scanning on join-chains is not reliable. So detecting blocked hooks is not either. I might have overlooked other solutions, but I think keeping the blocked threads alive and try to be smart at having the hook detected/handle them is a deadend.

Having a thread calling System.exit while System.exit is already in progress being able to "exit" itself (like pthread_exit for posix threads for exemple) would also solve those hook joining blocked thread scenario.

Having a thread being able to cease execution change what could be expected from the documented behavior. In term of execution flow, having the thread blocked indefinitely on a monitor enter or have it cease execution is the same : it won't run any other piece of code. Calling Thread.stop while on threads trying to monitor enter the synchronized block has no effect: they need to "enter" the monitor before being able to see the ThreadDeath error to throw. The thread running inside the synchronized block will never do a monitor exit since it calls halt within the synchronized boundaries. The difference between blocked versus cease is the garbage collector behavior: the blocked thread is still alive, still holds refs that cannot be GCed. the thread that cease execution allow objects to be GCed. Even if I don't think that would really be an issue, I still have to mention it.

By the way, the hook calling System.exit might be tricky to see/avoid. My demo code is simple but I got this more or less in this kind of execution flow
public static void main(String[] args) {
    Thread.setDefaultUncaughtExceptionHandler((th, trw)->{
        /* if trw is considered a fatal throwable then ask for a graceful JVM shutdown */ System.exit(1);
        /* OOM errors often screw too many things, leaving not-daemon thread hanging around, preventing JVM standard shutdown without either a System.exit or a Runtime.halt, so I think OOM errors are good candidates for being fatal throwables */
    });
    Runtime.getRuntime().addShutdownHook(new Thread("hook") {
        public void run() {
            // the hook does not need to do a hard work to throw an OOM, if running inside a saturated JVM, just a new String to log some message will do
            throw new OutOfMemoryError("error in hook");
        }
    });
}

Regards,
Remi


Orange Restricted

-----Message d'origine-----
De?: David Holmes <david.holmes at oracle.com> 
Envoy??: mardi 26 avril 2022 01:24
??: CATHERINOT R?mi DTSI/PFS <remi.catherinot at orange.com>; core-libs-dev at openjdk.java.net
Objet?: Re: System.exit deadlock if called within a hook

On 25/04/2022 11:08 pm, remi.catherinot at orange.com wrote:
> Hi,
> 
> Exemple code to deadlock the JVM. Only Runtime.halt from within the JVM or a SIGKILL from outside stops it. Normal kills and Ctrl-C (which is a SIGTERM) fail to do so.
> 
> public class ExitInHookDemo {
>              public static void main(String...args) {
>                          Runtime.getRuntime().addShutdownHook(new Thread("hook") {
>                                      public void run() { 
> System.exit(1); } });
>              }
> }

This is a documented usage limitation of exit().

" All registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. Once this is done the virtual machine halts.

If this method is invoked after all shutdown hooks have already been run and the status is nonzero then this method halts the virtual machine with the given status code. Otherwise, this method blocks indefinitely. "

Here you have a hook that calls exit() before all hooks have been run, hence it blocks indefinitely. As the hook blocks indefinitely the running of hooks cannot finish as required and so the virtual machine does not halt.

Conceptually you are asking for the indefinitely blocked hook to be treated as-if "finished", but there is no actual mechanism to implement that. You don't need to "destroy" the thread to force it to be "finished", but you do need a way for exit() to check if the current thread is a hook and to adapt the logic so that thread.join() is not used to wait for true termination. It would be possible to construct something I think, but I don't know if such an enhancement would be considered worthwhile versus don't call exit() from a hook.

Cheers,
David
-----

> I've tried to more or less do a pure java patch in java.lang.Shutdown 
> but the only way to have a real patch would be to have Thread.destroy 
> still there and implemented or anything allowing Shutdown to destroy a 
> thread. In essence, System.exit is a no return method call. So using 
> Thread.stop which raise a ThreadDeath error is not enough (the method 
> go back to the caller with the error). Only Thread.destroy has the 
> contract of being a no return call. Yes the documentation said it is 
> unsafe because it does not release locks & co, but right now that is 
> exactly what is happening, so Thread.destroy limitations are 
> acceptable. Throwing something that is not catchable, something legit 
> to throw but not legit to catch, even by a catch Throwable, is not 
> enough because it would still run finally blocks, which cannot happen 
> for no return methods like System.exit and Runtime.halt: try { 
> System.exit(0); /* code that should never be reached */ } catch 
> (Throwable t) { /* code that should never be reached */ } finally { /* 
> code that should also never be reached */ }
> 
> I've searched the known/documented bugs but I either missed the fact it was already reported, or I only got entries about removing Thread.destroy.
> 
> By the way, I'm not really asking to have Thread.destroy implemented were it is currently defined (a public method inside Thread). I mean at least java.lang.Shutdown should have a way to destroy Threads, even a private one. Threads destroyed that way should make threads stuck joining the destroyed one must be released.
> 
> I got the bug on java 1.8, oracle and openjdk ones. Not tested it one >=9 ones.
> 
> Here is what the approximation of a patch using pure java, but I'm no jdk expert and had no access to thread destruction, so it is not perfect. The code is from java.lang.Shutdown
>      static void exit(int status) {
>          boolean wasRunning = false; // < - - new var
>          boolean runMoreFinalizers = false;
>          synchronized (lock) {
>              switch (state) {
>              case RUNNING:       /* Initiate shutdown */
>                  state = HOOKS;
>                  wasRunning = true; // < - - first call to System.exit, the caller will run all of what is needed -hooks, maybe finalizers, etc.
>                  if (status != 0) runFinalizersOnExit = false; // < - - also moved the runFinalizersOnExit block to avoid having it changed/altered by several threads trying to exit with different status code
>                  break;
>              case HOOKS:         /* Stall and halt */
>                  break;
>              case FINALIZERS:
>                  if (status != 0) {
>                      /* Halt immediately on nonzero status */
>                      halt(status);
>                  } else {
>                      /* Compatibility with old behavior:
>                       * Run more finalizers and then halt
>                       */
>                      runMoreFinalizers = runFinalizersOnExit;
>                  }
>                  break;
>              }
>          }
>          if (!wasRunning) Thread.currentThread().stop(); // < - - should be a destroy rather than a stop. This thread is not the 1st who called System.exit, and since it should never return, it must die asap. We are outside of the synchronized block so if any lock remains acquired by this thread, they are acquired by the caller which should have released them before calling exit on the 1st place. If the caller called us while having locks, it is a caller bug, not a Shutdown.exit one. Current implementation since it never returns (and yield the stuck bug I report) also never release any of the locks it has too
>          // < - - beyond this line nothing has been modified
>          if (runMoreFinalizers) {
>              runAllFinalizers();
>              halt(status);
>          }
>          synchronized (Shutdown.class) {
>              /* Synchronize on the class object, causing any other thread
>               * that attempts to initiate shutdown to stall indefinitely
>               */
>              sequence();
>              halt(status);
>          }
>      }
> 
> 
> Regards,
> Ogrom.
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


From dfuchs at openjdk.java.net  Wed Apr 27 10:59:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Apr 2022 10:59:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Hi Joe, just two suggestions about the javax.management changes. Otherwise looks good!

src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96:

> 94:  *
> 95:  * @param <T> the Java type that instances described by this type must
> 96:  * have.

Instead of "instances" - would it be more correct to say "array elements"?

src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60:

> 58:  * @param <T> the Java type that instances described by this type must
> 59:  * have.
> 60:  *

I would suggest to say "that values described by this type"...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From prappo at openjdk.java.net  Wed Apr 27 11:13:27 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 27 Apr 2022 11:13:27 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <vknck6J2mGnJrlNFGLsdkIPJz4L3Joc3kIoGdJ1PmXw=.c9f196a3-79cf-4ac3-81e8-fbacd55e7a8b@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

I note that many years ago you filed JDK-6327933, which I'm currently looking at. If implemented, many of the issues from this PR will be addressed automatically, including those in `java.util.concurrent`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From duke at openjdk.java.net  Wed Apr 27 11:22:37 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 11:22:37 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v6]
In-Reply-To: <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
Message-ID: <EJM6OXohXpIistJJ4tuANWO8AGi7SsexH2eagayzAvM=.5b758463-1b0d-4c8c-aecc-65db8e47fb1f@github.com>

On Wed, 27 Apr 2022 10:34:33 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

Thanks for review.
@iklam @jerboaa 
I added test to TestMisc with print_container_info and -XshowSettings:system

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed Apr 27 11:31:34 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 27 Apr 2022 11:31:34 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v6]
In-Reply-To: <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
Message-ID: <HnljFZgRlKeBRw_1atbruvsZt2yWDnXPQLHNeFZ1v7k=.de5675df-a8ec-45b9-ba0a-5f22969a3dd1@github.com>

On Wed, 27 Apr 2022 10:34:33 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

I refer to the content of this test
https://github.com/openjdk/jdk/blob/0f81d8fcc3fb703760b1cddb01861ea5031023fb/test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java#L119

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From dfuchs at openjdk.java.net  Wed Apr 27 11:38:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Apr 2022 11:38:50 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149:

> 147:      *         access to the file or {@link java.lang.management.ManagementPermission
> 148:      *         ManagementPermission("control")} is denied
> 149:      * @since 19

Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mcimadamore at openjdk.java.net  Wed Apr 27 11:49:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 27 Apr 2022 11:49:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v32]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <hnrG3toVnWb_C_rmhGWf3gAPCabMnntYpRNS04RWle0=.da1718b8-e539-4349-99e6-52d40df2f3a3@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address CSR comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/746de5ce..6990183f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=31
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=30-31

  Stats: 114 lines in 9 files changed: 36 ins; 0 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Wed Apr 27 12:00:29 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 27 Apr 2022 12:00:29 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v33]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <c5zyF9Zj9fC_m9HPoGqBpMGq1DS7wrFNJ9Z4nyB-TQo=.d1e875cc-5be4-4379-88ac-0e9989089393@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Simplify libraryLookup impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6990183f..5866bbb5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=32
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=31-32

  Stats: 21 lines in 1 file changed: 6 ins; 11 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From weijun at openjdk.java.net  Wed Apr 27 13:34:43 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Apr 2022 13:34:43 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <SZYMWxOzsSnpVV8uf4Eb76kU_6SWNfQWY__OnhNZg_o=.2eea0a7b-088a-4044-b81a-689409b420f1@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

Or we can provide an example in the method spec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From alanb at openjdk.java.net  Wed Apr 27 13:44:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 13:44:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
 <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com>
Message-ID: <lib4iJ2kXatY7lEUdtuN10wmM7Q8LwOYRFXJ7o9eiNs=.4ea71e2b-8e16-4895-ad54-3e8b11480420@github.com>

On Wed, 27 Apr 2022 11:34:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>
> src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149:
> 
>> 147:      *         access to the file or {@link java.lang.management.ManagementPermission
>> 148:      *         ManagementPermission("control")} is denied
>> 149:      * @since 19
> 
> Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do.

Well spotted. The implSpec further up documents it but it should be in the throws list too.

> test/jdk/java/net/vthread/HttpALot.java line 76:
> 
>> 74:         var address = server.getAddress();
>> 75:         URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello");
>> 76: 
> 
> Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated.

A few of these tests started out as standalone classes that could be run without test infrastructure. This one, and InterruptHttp, can be easily changed to use the URIBuilder infra library, so we can do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From dfuchs at openjdk.java.net  Wed Apr 27 13:44:14 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Apr 2022 13:44:14 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
In-Reply-To: <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <XPzIJIvKMTkF_GeLp9DRh243Y3i1fYAwwJ1gCqFAuew=.ee51212a-c63e-4099-8ea3-723a50227f84@github.com>
Message-ID: <gE0FtlHYAJ64pQcZDJhCAorCPnXQfLlvv4Zqwn5AhDw=.baf83846-3c82-465b-bc43-56ec7a590cce@github.com>

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69

test/jdk/java/net/vthread/HttpALot.java line 76:

> 74:         var address = server.getAddress();
> 75:         URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello");
> 76: 

Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated.

test/jdk/java/net/vthread/InterruptHttp.java line 88:

> 86:             InetAddress lb = InetAddress.getLoopbackAddress();
> 87:             listener = new ServerSocket(0, -1, lb);
> 88:             address = "http://" + lb.getHostAddress() + ":" + listener.getLocalPort();

Same remark about using URIBuilder here. It would take care of properly formatting the address in case of IPv6 literals. This can be taken care of after this PR has been integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From rriggs at openjdk.java.net  Wed Apr 27 13:45:51 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Apr 2022 13:45:51 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <VPErD-AvOpFoRHi2krK1OaekC_nwItGsC9PevFQgl5k=.ffc63966-ef0d-45fb-b668-6b1f5cacfb4b@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

If it is just for one/few tests, it would fit better in the directory with the test or in the test itself.
This doesn't seem like enough of a general purpose function to be in the test library.

Overwriting the input file seems like a bad choice, it will be a trap for someone.
It prevents the use of the function in a case where the output is written to a different file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From weijun at openjdk.java.net  Wed Apr 27 13:55:44 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Apr 2022 13:55:44 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <82yO5eQ0fMvsbAIk9c_Rm6lt18hU3M1FUn-pMc6uPks=.b6a1e1a8-9d43-46c6-8c09-8d0d284d5588@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

Currently it's just for one test, but it's the exact kind of method that should go into the test library, i.e. a general purpose file manipulation utility that can be useful by everyone.

`patch` overwrites the input file (by default) too. We can always enhance it to support `-o`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From rriggs at openjdk.java.net  Wed Apr 27 14:01:39 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Apr 2022 14:01:39 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <kHaSGBh58kfqmoypikY4eLUzRNxtZJHHo5f50aN-1u8=.eeeae8c4-34e9-47a0-b257-9141118c22ac@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

Please change the issue/pr title to indicate it is a new API in the **test** library.
The problem with single purpose APIs with not enough forethought is that they are not discoverable
in the library and fall into disuse or are not appropriate for someone else to find and use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From weijun at openjdk.java.net  Wed Apr 27 14:12:46 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 27 Apr 2022 14:12:46 GMT
Subject: RFR: 8285452: Support new API to replace a file content using
 FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <rgoHrxE4CnVdOe8PswGUNL9z8CPNBtHWSuDmJf0luqk=.3bf1da7d-3223-49be-9519-469a8fd1ac7e@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

I've updated the title of the bug. Siba can update the PR title.

You're right that it's not easy to discover such APIs. We put it in `FileUtils` hoping people who does not want to write their own method will search from there first.

As for the API itself, we've imagined something like

FileUtils.patch(inputFile)
        .with(1, 10, List.of(lines), List.of(newLines))
        .with(100, 100, linesAsAString, newLinesAsAString)
        .writeTo(outputFile)

but the current form is the simplest case and could be kept even if we have a verbose one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From duke at openjdk.java.net  Wed Apr 27 14:21:43 2022
From: duke at openjdk.java.net (Johnny Lim)
Date: Wed, 27 Apr 2022 14:21:43 GMT
Subject: Integrated: 8285440: Typo in Collections.addAll method javadoc
In-Reply-To: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
References: <1BF8DKW3-4X2VOA-RN7AER_5KlVi2OEcLLG1I2gY-cM=.b751f331-feb8-4435-8c12-806e883939cb@github.com>
Message-ID: <9hHhjThbxOGRQyB1SEJCpVJl2P-ILuI-MkVrh8xVFCk=.ce318191-f9d3-4884-ac21-757a104e2a01@github.com>

On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim <duke at openjdk.java.net> wrote:

> This PR fixes a typo.

This pull request has now been integrated.

Changeset: 4919525d
Author:    Johnny Lim <izeye at naver.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4919525ddb55ba52d199a37c3b0e14e4a0c7c738
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8285440: Typo in Collections.addAll method javadoc

Reviewed-by: jpai, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/6942

From alanb at openjdk.java.net  Wed Apr 27 14:24:20 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 14:24:20 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8166/files
  - new: https://git.openjdk.java.net/jdk/pull/8166/files/0864cb09..f2ed4f9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06-07

  Stats: 505 lines in 15 files changed: 139 ins; 189 del; 177 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From dfuchs at openjdk.java.net  Wed Apr 27 14:36:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Apr 2022 14:36:07 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <-DAfgDmuhsODNWuhCRea8JMYvDS4Gq6fX1kmESiMDss=.37b60329-a65f-4ab9-a78c-79db99f80226@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Thanks for the refresh Alan! Things look good to me now. 
I have gone over java.io, the networking parts of java.nio, java.net, and the JMX related changes.
For what I have reviewed, I believe this is good to go.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From sgehwolf at openjdk.java.net  Wed Apr 27 14:38:42 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 27 Apr 2022 14:38:42 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v6]
In-Reply-To: <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
Message-ID: <zNOI4yBrdEKdpw5nOhXUe_tCANvypAwqa7ac_vVpl6Q=.9106d881-3006-4587-9429-552451593603@github.com>

On Wed, 27 Apr 2022 10:34:33 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

Changes requested by sgehwolf (Reviewer).

test/hotspot/jtreg/containers/docker/TestMisc.java line 60:

> 58:             testPrintContainerInfo();
> 59:             testPrintContainerInfoActiveProcessorCount();
> 60:             testPrintContainerMemoryInfo("100M", "150M");

Again. This test runs unconditionally. `--memory-swappiness` is not supported in cgroups v2. Thus, the test will fail on a cgroups v2 system. You need to only run this test on a cgroups v1 system. Have a look at `test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java` how could could detect this and only run on `cgroupv1` providers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From sgehwolf at openjdk.java.net  Wed Apr 27 14:38:43 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 27 Apr 2022 14:38:43 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v6]
In-Reply-To: <zNOI4yBrdEKdpw5nOhXUe_tCANvypAwqa7ac_vVpl6Q=.9106d881-3006-4587-9429-552451593603@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <mmgnNo3ARoPQ1eqLHW6pfFMW8PqwdoCok_wUggJ5-es=.9ce3a34c-1a6c-410f-aa61-9915450886fd@github.com>
 <zNOI4yBrdEKdpw5nOhXUe_tCANvypAwqa7ac_vVpl6Q=.9106d881-3006-4587-9429-552451593603@github.com>
Message-ID: <5-Sc1aP734VtoS8qLmCOzBlD4OBsad7CDM3zBVtnsLg=.d4edd548-746d-4094-8959-feb1740a3807@github.com>

On Wed, 27 Apr 2022 14:24:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert file
>
> test/hotspot/jtreg/containers/docker/TestMisc.java line 60:
> 
>> 58:             testPrintContainerInfo();
>> 59:             testPrintContainerInfoActiveProcessorCount();
>> 60:             testPrintContainerMemoryInfo("100M", "150M");
> 
> Again. This test runs unconditionally. `--memory-swappiness` is not supported in cgroups v2. Thus, the test will fail on a cgroups v2 system. You need to only run this test on a cgroups v1 system. Have a look at `test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java` how could could detect this and only run on `cgroupv1` providers.

On my cgroups v2 system (i.e. it's using 200m memory + 200m swap):

$ sudo docker run --rm -ti --memory-swappiness=0 --memory=200m fedora:35
WARNING: Your kernel does not support memory swappiness capabilities or the cgroup is not mounted. Memory swappiness discarded.
[root at fb3182c8e23c /]# cat /sys/fs/cgroup/memory.max 
209715200
[root at fb3182c8e23c /]# cat /sys/fs/cgroup/memory.swap.max 
209715200

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From lmesnik at openjdk.java.net  Wed Apr 27 14:43:11 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 27 Apr 2022 14:43:11 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <t6hI4RsUuj6FnpPS6LXMWY8sOCOQJKwDFc0DP9I4ZC4=.68b8da58-64aa-4dc2-9dd6-7b79998500e9@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Reviewed jvmti changes, hotspot tests (excluding tests modified by lmesnik), jdk svc tests changes.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From mbaesken at openjdk.java.net  Wed Apr 27 15:05:16 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 27 Apr 2022 15:05:16 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
Message-ID: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>

Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
Macros for Conditional Declarations
"Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."

However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

-------------

Commit messages:
 - JDK-8285730

Changes: https://git.openjdk.java.net/jdk/pull/8428/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285730
  Stats: 14 lines in 7 files changed: 1 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428

PR: https://git.openjdk.java.net/jdk/pull/8428

From alanb at openjdk.java.net  Wed Apr 27 15:14:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 15:14:43 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

src/java.base/windows/native/libnio/ch/wepoll.c line 159:

> 157: 
> 158: #undef _WIN32_WINNT
> 159: #define _WIN32_WINNT 0x0601

This is 3rd party code and would prefer not change it if possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From rriggs at openjdk.java.net  Wed Apr 27 15:35:45 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Apr 2022 15:35:45 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
Message-ID: <-T-TuLwA56yPK_O273MB-mYnV2xaVdm1Lmc75sediXc=.082b20a1-af1a-418f-be72-5dfd8de22b7c@github.com>

On Wed, 27 Apr 2022 10:11:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this fix to test/jdk/java/lang/ref/ReferenceClone.java.  It was
>> passing if CloneableReference::clone were to throw CloneNotSupportedException.
>> That should be a failure.
>> 
>> Testing:
>> Locally (linux-x64) verified test still passes.  Temporarily changed
>> CloneableReference::clone to throw and verified the expected failure gets
>> reported, unlike before.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright, @bug list

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8418

From rriggs at openjdk.java.net  Wed Apr 27 15:53:32 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Apr 2022 15:53:32 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <e6r94NB7QloVJ1ta6wGd2VUTBXfs55PIBjTWAJ3JmAM=.2e7ffc36-11c8-4575-88c8-cf2707dd7f12@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Since you've changed some code; you need to run tests for tiers 1-3.

(Note that even for trivial changes, hundreds of OpenJDK developers are notified and distracted; be considerate of other developers).

src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEventReaderImpl.java line 140:

> 138:             } else if(type == XMLEvent.START_ELEMENT) {
> 139:                 throw new XMLStreamException(
> 140:                 "elementGetText() function expects text only element but START_ELEMENT was encountered.", event.getLocation());

Should we be fixing typos in third party software; it can easily get wiped out in an update.

src/java.xml/share/classes/com/sun/xml/internal/stream/writers/WriterUtility.java line 97:

> 95:         }
> 96:         else{
> 97:             //attempt to retrieve default fEncoderoder

"fEncoderoder" looks out of place, please recheck.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From bpb at openjdk.java.net  Wed Apr 27 16:00:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Apr 2022 16:00:36 GMT
Subject: RFR: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator [v3]
In-Reply-To: <_QR6czh1e6cOfUNpb3SUiDPjfShKAPeGIALbCmfcKqs=.af2b4a97-9dab-4ceb-ad57-294103d8028c@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
 <_QR6czh1e6cOfUNpb3SUiDPjfShKAPeGIALbCmfcKqs=.af2b4a97-9dab-4ceb-ad57-294103d8028c@github.com>
Message-ID: <s7e29JfvAdPZKy-Hh-ka3HGYHJOJ_t8n7sWZ9x0kzE0=.d89fdc30-aefc-4864-a7da-5e2f91ab8ee5@github.com>

On Wed, 27 Apr 2022 07:34:29 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285658: Fix two typos in the spec of j.u.random.RandomGenerator

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From mchung at openjdk.java.net  Wed Apr 27 16:02:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 16:02:43 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
Message-ID: <Isqy_M25PRbTsUfG1segg3Cz3Iov8PAytVik2-F4V7o=.ecea58e0-90c6-4586-aae7-75530afd90b8@github.com>

On Wed, 27 Apr 2022 10:11:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this fix to test/jdk/java/lang/ref/ReferenceClone.java.  It was
>> passing if CloneableReference::clone were to throw CloneNotSupportedException.
>> That should be a failure.
>> 
>> Testing:
>> Locally (linux-x64) verified test still passes.  Temporarily changed
>> CloneableReference::clone to throw and verified the expected failure gets
>> reported, unlike before.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright, @bug list

Marked as reviewed by mchung (Reviewer).

test/jdk/java/lang/ref/ReferenceClone.java line 52:

> 50:         } catch (CloneNotSupportedException e) {
> 51:             throw new RuntimeException("CloneableReference::clone should not throw CloneNotSupportedException");
> 52:         }

Alternatively, it could simply let CNSE propagate.


CloneableReference ref = new CloneableReference(o);
ref.clone();


`test()` and `main` will need to declare this checked exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From naoto at openjdk.java.net  Wed Apr 27 16:21:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 16:21:45 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <GmnNF3Pw1uS8UZyjfpgWAdpdo4cwUe1dNso9Mvepm_Q=.d1c6f1ce-879d-4d83-be50-dbbe6d31dd49@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From naoto at openjdk.java.net  Wed Apr 27 16:21:46 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 16:21:46 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <YL_YZOMz5aRKDYJD5THtdj9mOJL54kF2GfTBMA5f20g=.17c024be-503f-407a-8262-2d2ac78480e5@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <YL_YZOMz5aRKDYJD5THtdj9mOJL54kF2GfTBMA5f20g=.17c024be-503f-407a-8262-2d2ac78480e5@github.com>
Message-ID: <pFAtlj9YmGwoG2a2UprliV_cYJc7Mbv_PGmJh6HR85c=.b69a42c5-2b93-4705-8430-02cabf3c9e1a@github.com>

On Wed, 27 Apr 2022 06:39:30 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B
> 
> what's this?

Removing the trailing space? A similar one is in the `ja` resource bundle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From asemenyuk at openjdk.java.net  Wed Apr 27 16:36:51 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 27 Apr 2022 16:36:51 GMT
Subject: Integrated: JDK-8236128: Allow jpackage create installers for services
In-Reply-To: <Rc1qJzW40px0VvmFGDZBcQ-Ow3w7ubJNmzHu7PkSmQE=.7d67b399-5d2f-4537-9275-4ae9b88ed33f@github.com>
References: <Rc1qJzW40px0VvmFGDZBcQ-Ow3w7ubJNmzHu7PkSmQE=.7d67b399-5d2f-4537-9275-4ae9b88ed33f@github.com>
Message-ID: <1i5o4dttJvCYEzeA0hbgafm3bYvgTtjSBqhSNl9GL_E=.707e7fc0-14a6-43ca-a8ac-9d81fabe47f4@github.com>

On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
>  CSR

This pull request has now been integrated.

Changeset: b675c597
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b675c597e3f22af9e75992dab27001b9875af32e
Stats:     3116 lines in 64 files changed: 2848 ins; 121 del; 147 mod

8236128: Allow jpackage create installers for services

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/7793

From naoto at openjdk.java.net  Wed Apr 27 16:44:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 16:44:45 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>

On Wed, 27 Apr 2022 08:59:20 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

Looks fine to me. Nit: please modify the copyright years for `javap` properties files, as you modified the base (`javap.properties`) file.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8417

From prappo at openjdk.java.net  Wed Apr 27 16:54:52 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 27 Apr 2022 16:54:52 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <VMe3Pe85o_qJoR-Yw5bZ1-GIeqHwyb_V8J-iS78KFlQ=.966dc7fe-0399-4342-94c0-f31f51914fe5@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

src/java.se/share/data/jdwp/jdwp.spec line 47:

> 45:         "Returns reference types for all the classes loaded by the target VM "
> 46:         "which match the given signature. "
> 47:         "Multiple reference types will be returned if two or more class "

This file's name scares me. The fact that there's no "serviceability" label on this PR adds to this feeling. I would ask around if I were you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From dcubed at openjdk.java.net  Wed Apr 27 17:12:29 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 27 Apr 2022 17:12:29 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <Woqu1RjxYGlU5yfd0BDt5g60h9OPW6hS9T8rR2BDM2c=.9c2299f8-3243-4706-a562-9b137b071ad4@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I've reviewed the JVM/TI, JDWP and JDI changes and I'm good with those.

I haven't reviewed the JDB changes (forgot about those) and I have not
(yet) reviewed the Runtime changes.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From kevinw at openjdk.java.net  Wed Apr 27 17:12:29 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 27 Apr 2022 17:12:29 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <gvh8hT_wOfRAiL6OyCgDNbWZ4FqRQ9SK48DVLbr9oGo=.028764c1-44d1-43e6-9dad-59355f354c91@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Been through the JDI changes and jdb/example code.
Built and manually tested some operations with jdb observing virtual threads.

Been through jdk.management/share/classes/com/sun/management and also manually tested jconsole attaching (e.g. dumpThreads operation in both TEXT_PLAIN and JSON).

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From dcubed at openjdk.java.net  Wed Apr 27 17:20:27 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 27 Apr 2022 17:20:27 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
Message-ID: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>

A trivial fix for JDK-8236128 causes validate-source failures.

-------------

Commit messages:
 - 8285736: JDK-8236128 causes validate-source failures

Changes: https://git.openjdk.java.net/jdk/pull/8429/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8429&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285736
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8429/head:pull/8429

PR: https://git.openjdk.java.net/jdk/pull/8429

From mikael at openjdk.java.net  Wed Apr 27 17:20:27 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 27 Apr 2022 17:20:27 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
In-Reply-To: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
References: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
Message-ID: <UOX4WkmdDXZa6h3y6HOFBkPRwP3KqNQglCnFxMQeS_E=.af476a4b-98af-4b89-b293-a0e63365fb99@github.com>

On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for JDK-8236128 causes validate-source failures.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8429

From asemenyuk at openjdk.java.net  Wed Apr 27 17:20:27 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 27 Apr 2022 17:20:27 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
In-Reply-To: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
References: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
Message-ID: <F1aGUeRpdc_kavIq7C5ir9GemvFwAZDsxIkZDiK2Etc=.848936f0-bc51-4696-bc1b-87c1f8d5fdb1@github.com>

On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for JDK-8236128 causes validate-source failures.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8429

From dcubed at openjdk.java.net  Wed Apr 27 17:20:28 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 27 Apr 2022 17:20:28 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
In-Reply-To: <UOX4WkmdDXZa6h3y6HOFBkPRwP3KqNQglCnFxMQeS_E=.af476a4b-98af-4b89-b293-a0e63365fb99@github.com>
References: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
 <UOX4WkmdDXZa6h3y6HOFBkPRwP3KqNQglCnFxMQeS_E=.af476a4b-98af-4b89-b293-a0e63365fb99@github.com>
Message-ID: <4xRztgFjXYmjcNABMjB-LTpZW8XsZ1O0564XO0DKLuI=.2f389f29-a7e6-4d4a-ba00-9d387b920e1d@github.com>

On Wed, 27 Apr 2022 16:55:11 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix for JDK-8236128 causes validate-source failures.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik and @alexeysemenyukoracle - Thanks for the fast reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8429

From dcubed at openjdk.java.net  Wed Apr 27 17:20:29 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 27 Apr 2022 17:20:29 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
In-Reply-To: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
References: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
Message-ID: <FLdbdGfsv4OF5EgXNK3Qu6c1K5qLsPyZ-E3VMAH9Pf0=.33b8b1b7-cc9c-4d17-9a6c-19a52939884d@github.com>

On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for JDK-8236128 causes validate-source failures.

The bot is being very, very, slow to integrate this...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8429

From dcubed at openjdk.java.net  Wed Apr 27 17:20:29 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 27 Apr 2022 17:20:29 GMT
Subject: Integrated: 8285736: JDK-8236128 causes validate-source failures
In-Reply-To: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
References: <YDPHM8nh9qB3L0AyyYUpIlGb6RXvtP0bTWpX3D2ZCKA=.81340a9a-9e97-4055-a2d2-07309d5e4f9b@github.com>
Message-ID: <zOIRPHe10gOFVq4mCO2akwnTuL9MzFdCrZbvkLMB9zo=.2fa5265d-4b49-4ecb-8f43-2b22776562c3@github.com>

On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix for JDK-8236128 causes validate-source failures.

This pull request has now been integrated.

Changeset: 5b42747b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b42747ba1606b34b05449518fa601d2451c5c66
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8285736: JDK-8236128 causes validate-source failures

Reviewed-by: mikael, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/8429

From psandoz at openjdk.java.net  Wed Apr 27 17:21:39 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Apr 2022 17:21:39 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
Message-ID: <Fz-GFQl2ITQuVDvPA5pGh1JDhez15gT8jAEO0iJwGmA=.47673f6c-6d8c-4b02-9feb-380f75ddc96f@github.com>

On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - Merge branch 'master' into JDK-8284992
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - 8284992: Fix misleading Vector API doc for LSHR operator

Thanks, looks good, we will need to create a CSR. Have you done that before?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From mchung at openjdk.java.net  Wed Apr 27 17:30:06 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 17:30:06 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <ikkqB-rNQuSTCkDKnFOAJs6H4-9DKFQSKyEQF5D-Qws=.4590c717-4914-43cd-9cf4-18933929c9d6@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58:

> 56: 
> 57:     // maps a class to the hashes of stack traces pinned by that code in that class
> 58:     private static final Map<Class<?>, Hashes> classToHashes = new WeakHashMap<>();

Can you use `ClassValue` in this case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From prappo at openjdk.java.net  Wed Apr 27 17:39:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 27 Apr 2022 17:39:45 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <KVPVwOIG_zdCd2N_xkC72wc1CunMHDZzLyHPuu8W61g=.6aa23c39-701d-46d3-8f1c-9be76215e4ea@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Thanks for doing this so carefully. If reviewers decide that parts of this PR need to be addressed upstream, we should probably consider contributing those parts to respective projects.

src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java line 970:

> 968:      * and sends a <code>rowSetChanged</code> event to all registered
> 969:      * listeners.
> 970:      * @throws SQLException if an error is occurs rolling back the RowSet

L976, same as above: "is occurs".

src/java.sql.rowset/share/classes/com/sun/rowset/JoinRowSetImpl.java line 636:

> 634:                 // to be INNER JOIN'ED to form a new rowset
> 635:                 // Compare table1.MatchColumn1.value1 == { table2.MatchColumn2.value1
> 636:                 //                              ... up to table2.MatchColumn2.valueN }

Curious: it is not some established string representation, is it?

src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java line 664:

> 662:      * and sends a {@code rowSetChanged} event to all registered
> 663:      * listeners.
> 664:      * @throws SQLException if an error is occurs rolling back the RowSet

L664: delete "is" in "is occurs".

src/java.sql.rowset/share/classes/com/sun/rowset/providers/RIXMLProvider.java line 239:

> 237: 
> 238:     /**
> 239:      * Returns the vendor name of the Reference Implementation Optimistic

L240: an optimistic _what_ provider? :-)

src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java line 238:

> 236: 
> 237:     /**
> 238:      * Creates a DOM Attribute @see org.w3c.dom.Node and associates it with the current DOM element @see org.w3c.dom.Node.

Not that it matters in this PR, but I think I should mention that `@see` tags do not work like that. (No action needed from you.)

src/java.xml/share/classes/javax/xml/transform/Transformer.java line 127:

> 125:      * namespace URI in curly braces ({}).
> 126:      * @param value The value object.  This can be any valid Java object. It is
> 127:      * up to the processor to provide the proper object coersion or to simply

That made me pause: some systems have the notion of _type coercion_; but your change looks right.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From amenkov at openjdk.java.net  Wed Apr 27 17:48:55 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 27 Apr 2022 17:48:55 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <nzSyhTeE2vjzqHItrCVztRnzS0IzOc82knj8oYNkDU8=.9236c198-b993-4c3a-bba5-42ad9baf7407@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Reviewed debugger-related code (JDI/JDWP/JDB/tests) and partially JVMTI.

-------------

Marked as reviewed by amenkov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From lancea at openjdk.java.net  Wed Apr 27 17:51:44 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Apr 2022 17:51:44 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <OG2ZuZRHzDKuAk49-QWgzb0F9R-b0TQV227Cnh1rFpY=.6318519d-7120-4cb0-ba6a-63e31b9cd18d@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Changes look OK with the exception of the comment pointed out below

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8364

From lancea at openjdk.java.net  Wed Apr 27 17:51:45 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 27 Apr 2022 17:51:45 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <KVPVwOIG_zdCd2N_xkC72wc1CunMHDZzLyHPuu8W61g=.6aa23c39-701d-46d3-8f1c-9be76215e4ea@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <KVPVwOIG_zdCd2N_xkC72wc1CunMHDZzLyHPuu8W61g=.6aa23c39-701d-46d3-8f1c-9be76215e4ea@github.com>
Message-ID: <UVbS5xsCpmxJGytrrzWTYu35GMx989VguEy4yxUU8S0=.780d83f7-9df8-490f-a8d9-6e1f0c0146b9@github.com>

On Wed, 27 Apr 2022 17:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/java.sql.rowset/share/classes/com/sun/rowset/providers/RIXMLProvider.java line 239:
> 
>> 237: 
>> 238:     /**
>> 239:      * Returns the vendor name of the Reference Implementation Optimistic
> 
> L240: an optimistic _what_ provider? :-)

Yep typo there.  The original authors needed to run spell check ;-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From mchung at openjdk.java.net  Wed Apr 27 17:55:23 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 17:55:23 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <uTZJkUXe_HjgUnwObE0_JcvLQqYK941hMnsiNT4ykgY=.3bc2612a-a53b-441c-afee-e9abb86bd5f9@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122:

> 120:      */
> 121: 
> 122:     public static final int SCOPED_CACHE_SHIFT;

I can't find this constant being used.   If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From prr at openjdk.java.net  Wed Apr 27 17:56:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Apr 2022 17:56:51 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <faXxzwdpTMHryL66kIS6m6kMXxNkuZilSGnWNdcqym4=.4dd9d26c-aa39-4c0b-b962-fefd1344856f@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

This is OK by me, but I wonder if the build folks might want to think about this and whether it should be centralised somehow
since it seems odd to mandate different versions of windows in different places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From rriggs at openjdk.java.net  Wed Apr 27 17:56:59 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 27 Apr 2022 17:56:59 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <RxOobLw-G6fiPyuPSbhvz4GTXIg1agpqpLl7NAuibhw=.263471f1-78e5-42c7-bf9f-2bdee2a65a3c@github.com>

On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 68:

> 66:     private static final Map<String,String> theUnmodifiableEnvironment;
> 67:     static final int MIN_NAME_LENGTH = 0;
> 68:     static final Charset cs = Charset.forName(StaticProperty.nativeEncoding(),

cs should have an all-CAPS name to make it clear its a static value throughout the implementation.
And `private` too.

test/jdk/java/lang/System/i18nEnvArg.java line 41:

> 39: 
> 40: public class i18nEnvArg {
> 41:     final static String text = "\u6F22\u5B57";

Can this be renamed to indicate it is the string under test?  like KANJI_TEXT or EUC_JP_TEXT or similar.

test/jdk/java/lang/System/i18nEnvArg.java line 49:

> 47:     final static int maxSize = 4096;
> 48: 
> 49:     public static void main(String[] args) throws Exception {

There are 3 main()'s in this test; it would be useful to add a comment indicating the purpose of each.

test/jdk/java/lang/System/i18nEnvArg.java line 60:

> 58:         Process p = pb.start();
> 59:         InputStream is = p.getInputStream();
> 60:         byte[] ba = new byte[maxSize];

You can use `InputStream.readAllBytes()` here to return a byte buffer.

Its not clear why all the bytes are read?  I assume its only for a possible error from the child.

test/jdk/java/lang/System/i18nEnvArg.java line 128:

> 126:             Method enviorn_mid = cls.getDeclaredMethod("environ");
> 127:             enviorn_mid.setAccessible(true);
> 128:             byte[][] environ = (byte[][]) enviorn_mid.invoke(null,

typo: "enviorn_mid" -> "environ_mid".

test/jdk/java/lang/System/i18nEnvArg.java line 138:

> 136:                 bb.put(environ[i+1]);
> 137:                 byte[] envb = Arrays.copyOf(ba, bb.position());
> 138:                 if (Arrays.equals(kanji, envb)) return;

It seems odd to exit the loop on the first match.

I think AIX always has environment variables not set by the caller.

test/jdk/java/lang/System/i18nEnvArg.java line 146:

> 144:                         sb.append((char)b);
> 145:                     } else {
> 146:                         sb.append(String.format("\\x%02X", (int)b & 0xFF));

The methods of java.util.HexFormat may be useful here.
It seems that the "5C" would fit into this "else" clause and not need a separate statement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From redestad at openjdk.java.net  Wed Apr 27 17:57:22 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 27 Apr 2022 17:57:22 GMT
Subject: Integrated: 8285633: Take better advantage of generic MethodType cache
In-Reply-To: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
Message-ID: <ZrUrCtAc7oscckhTC98aOJJLrupALlbSgjr-MjRpTSY=.dd9cdad2-eca0-4e73-9780-fb1b41d5c7fc@github.com>

On Tue, 26 Apr 2022 10:57:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.
> 
> Baseline:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.673 ? 0.017  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.579 ? 0.125  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  46.671 ? 1.134  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  27.019 ? 0.437  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  57.217 ? 0.505  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15  57.114 ? 1.214  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15  33.380 ? 1.810  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.043 ? 0.187  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15  24.313 ? 0.074  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.360 ? 0.155  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.572 ? 1.101  ns/op
> 
> 
> Patched:
> 
> Benchmark                                    Mode  Cnt   Score   Error  Units
> MethodTypeAcquire.baselineRaw                avgt   15   0.683 ? 0.024  ns/op
> MethodTypeAcquire.testGenericObject          avgt   15   0.547 ? 0.047  ns/op
> MethodTypeAcquire.testMultiPType             avgt   15  48.532 ? 0.982  ns/op
> MethodTypeAcquire.testMultiPType_Arg         avgt   15  31.390 ? 5.269  ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  60.165 ? 2.756  ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15   0.599 ? 0.166  ns/op
> MethodTypeAcquire.testObjectObject           avgt   15   0.541 ? 0.045  ns/op
> MethodTypeAcquire.testReturnInt              avgt   15  28.174 ? 0.257  ns/op
> MethodTypeAcquire.testReturnObject           avgt   15   0.542 ? 0.045  ns/op
> MethodTypeAcquire.testReturnVoid             avgt   15  24.621 ? 0.202  ns/op
> MethodTypeAcquire.testSinglePType            avgt   15  33.614 ? 1.109  ns/op
> 
> 
> The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost (~3ns/op, with overlapping error).

This pull request has now been integrated.

Changeset: 6c79671e
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c79671e50d572f3da3a286d34a98dcb83b8d906
Stats:     119 lines in 8 files changed: 96 ins; 1 del; 22 mod

8285633: Take better advantage of generic MethodType cache

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From jrose at openjdk.java.net  Wed Apr 27 18:07:46 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 27 Apr 2022 18:07:46 GMT
Subject: RFR: 8285633: Take better advantage of generic MethodType cache
 [v2]
In-Reply-To: <k5X4ULRh_UuKLGzBirDiEA9lyrGTqnVMIaMrXtKLiic=.22f840d3-897c-40b9-9489-ef270ea425e7@github.com>
References: <00ymgWes0qwjdnYAa2RFNmFeEBub6cBHudvP8pFGj-U=.672dc8f0-6004-425e-b760-0e290b0556ca@github.com>
 <k5X4ULRh_UuKLGzBirDiEA9lyrGTqnVMIaMrXtKLiic=.22f840d3-897c-40b9-9489-ef270ea425e7@github.com>
Message-ID: <_GN8wFgDdr6B_3fa3z6tL9AzzNwBdZZPiNUwdNDPoR4=.36bc6b53-3a70-479a-afa7-639dd2f5b5ce@github.com>

On Tue, 26 Apr 2022 20:47:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free.
>> 
>> Baseline:
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> MethodTypeAcquire.baselineRaw                avgt   15   0.673 ? 0.017  ns/op
>> MethodTypeAcquire.testGenericObject          avgt   15   0.579 ? 0.125  ns/op
>> MethodTypeAcquire.testMultiPType             avgt   15  46.671 ? 1.134  ns/op
>> MethodTypeAcquire.testMultiPType_Arg         avgt   15  27.019 ? 0.437  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  57.217 ? 0.505  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15  57.114 ? 1.214  ns/op
>> MethodTypeAcquire.testObjectObject           avgt   15  33.380 ? 1.810  ns/op
>> MethodTypeAcquire.testReturnInt              avgt   15  28.043 ? 0.187  ns/op
>> MethodTypeAcquire.testReturnObject           avgt   15  24.313 ? 0.074  ns/op
>> MethodTypeAcquire.testReturnVoid             avgt   15  24.360 ? 0.155  ns/op
>> MethodTypeAcquire.testSinglePType            avgt   15  33.572 ? 1.101  ns/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                    Mode  Cnt   Score   Error  Units
>> MethodTypeAcquire.baselineRaw                avgt   15   0.683 ? 0.024  ns/op
>> MethodTypeAcquire.testGenericObject          avgt   15   0.547 ? 0.047  ns/op
>> MethodTypeAcquire.testMultiPType             avgt   15  48.532 ? 0.982  ns/op
>> MethodTypeAcquire.testMultiPType_Arg         avgt   15  31.390 ? 5.269  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA  avgt   15  60.165 ? 2.756  ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly  avgt   15   0.599 ? 0.166  ns/op
>> MethodTypeAcquire.testObjectObject           avgt   15   0.541 ? 0.045  ns/op
>> MethodTypeAcquire.testReturnInt              avgt   15  28.174 ? 0.257  ns/op
>> MethodTypeAcquire.testReturnObject           avgt   15   0.542 ? 0.045  ns/op
>> MethodTypeAcquire.testReturnVoid             avgt   15  24.621 ? 0.202  ns/op
>> MethodTypeAcquire.testSinglePType            avgt   15  33.614 ? 1.109  ns/op
>> 
>> 
>> The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost (~3ns/op, with overlapping error).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add micros using non-constant arguments to assess performance in absense of constant folding

Good work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8398

From mchung at openjdk.java.net  Wed Apr 27 18:11:08 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 18:11:08 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <MPyzf5BvbMZxeJB0Gm_HXWyQfecRhkihTBgaRhnNU-o=.53327e01-94df-4ad2-a32c-e815d75f22c9@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/java.management/share/classes/sun/management/ThreadImpl.java line 447:

> 445:         if (threads != null) {
> 446:             long[] tids = Stream.of(threads)
> 447:                     .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread))

Returning an array of thread IDs of just the platform threads is good.   The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Wed Apr 27 18:21:13 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Apr 2022 18:21:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ikkqB-rNQuSTCkDKnFOAJs6H4-9DKFQSKyEQF5D-Qws=.4590c717-4914-43cd-9cf4-18933929c9d6@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ikkqB-rNQuSTCkDKnFOAJs6H4-9DKFQSKyEQF5D-Qws=.4590c717-4914-43cd-9cf4-18933929c9d6@github.com>
Message-ID: <MCiXAUIRNna0vA9Pmj3mbWzJkE9suqqVl9UzN_Hom3s=.7fb27bf8-b583-4f01-ae30-a44ecc4bd111@github.com>

On Wed, 27 Apr 2022 17:27:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58:
> 
>> 56: 
>> 57:     // maps a class to the hashes of stack traces pinned by that code in that class
>> 58:     private static final Map<Class<?>, Hashes> classToHashes = new WeakHashMap<>();
> 
> Can you use `ClassValue` in this case?

I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mchung at openjdk.java.net  Wed Apr 27 18:21:13 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 18:21:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <MCiXAUIRNna0vA9Pmj3mbWzJkE9suqqVl9UzN_Hom3s=.7fb27bf8-b583-4f01-ae30-a44ecc4bd111@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ikkqB-rNQuSTCkDKnFOAJs6H4-9DKFQSKyEQF5D-Qws=.4590c717-4914-43cd-9cf4-18933929c9d6@github.com>
 <MCiXAUIRNna0vA9Pmj3mbWzJkE9suqqVl9UzN_Hom3s=.7fb27bf8-b583-4f01-ae30-a44ecc4bd111@github.com>
Message-ID: <fSQVmpuuXBGki_vrs-PRM0ITQvlhhbyRlZV8HBad8_8=.17704f38-9bb7-43fa-8e70-c215b092d1f8@github.com>

On Wed, 27 Apr 2022 18:13:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58:
>> 
>>> 56: 
>>> 57:     // maps a class to the hashes of stack traces pinned by that code in that class
>>> 58:     private static final Map<Class<?>, Hashes> classToHashes = new WeakHashMap<>();
>> 
>> Can you use `ClassValue` in this case?
>
> I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer.

It's not critical and no problem if this is cleaned up as a follow-up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From kbarrett at openjdk.java.net  Wed Apr 27 18:23:43 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 27 Apr 2022 18:23:43 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <Isqy_M25PRbTsUfG1segg3Cz3Iov8PAytVik2-F4V7o=.ecea58e0-90c6-4586-aae7-75530afd90b8@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
 <Isqy_M25PRbTsUfG1segg3Cz3Iov8PAytVik2-F4V7o=.ecea58e0-90c6-4586-aae7-75530afd90b8@github.com>
Message-ID: <ABwJ4s9Y7jru4drg1ZNgszV1y6xebSj8IvW3ORtuGwE=.947c2d0f-15d8-47d5-abe8-56bc446033ab@github.com>

On Wed, 27 Apr 2022 15:57:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright, @bug list
>
> test/jdk/java/lang/ref/ReferenceClone.java line 52:
> 
>> 50:         } catch (CloneNotSupportedException e) {
>> 51:             throw new RuntimeException("CloneableReference::clone should not throw CloneNotSupportedException");
>> 52:         }
> 
> Alternatively, it could simply let CNSE propagate.
> 
> 
> CloneableReference ref = new CloneableReference(o);
> ref.clone();
> 
> 
> `test()` and `main` will need to declare this checked exception.

That was my initial thought, but it doesn't work - CNSE is a checked exception so must be handled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From mchung at openjdk.java.net  Wed Apr 27 18:28:44 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 18:28:44 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <ABwJ4s9Y7jru4drg1ZNgszV1y6xebSj8IvW3ORtuGwE=.947c2d0f-15d8-47d5-abe8-56bc446033ab@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
 <Isqy_M25PRbTsUfG1segg3Cz3Iov8PAytVik2-F4V7o=.ecea58e0-90c6-4586-aae7-75530afd90b8@github.com>
 <ABwJ4s9Y7jru4drg1ZNgszV1y6xebSj8IvW3ORtuGwE=.947c2d0f-15d8-47d5-abe8-56bc446033ab@github.com>
Message-ID: <sRa6R1-vECkQjvEufn9km_V9PkXhnoLyQkan37kBEBQ=.fc5404ae-5fa2-4d9e-832b-463b4b32fa80@github.com>

On Wed, 27 Apr 2022 18:19:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/jdk/java/lang/ref/ReferenceClone.java line 52:
>> 
>>> 50:         } catch (CloneNotSupportedException e) {
>>> 51:             throw new RuntimeException("CloneableReference::clone should not throw CloneNotSupportedException");
>>> 52:         }
>> 
>> Alternatively, it could simply let CNSE propagate.
>> 
>> 
>> CloneableReference ref = new CloneableReference(o);
>> ref.clone();
>> 
>> 
>> `test()` and `main` will need to declare this checked exception.
>
> That was my initial thought, but it doesn't work - CNSE is a checked exception so must be handled.

> test() and main will need to declare this checked exception.


diff --git a/test/jdk/java/lang/ref/ReferenceClone.java b/test/jdk/java/lang/ref/ReferenceClone.java
index bd1ead81bec..2f9386b81e4 100644
--- a/test/jdk/java/lang/ref/ReferenceClone.java
+++ b/test/jdk/java/lang/ref/ReferenceClone.java
@@ -31,12 +31,12 @@ import java.lang.ref.*;
 
 public class ReferenceClone {
     private static final ReferenceQueue<Object> QUEUE = new ReferenceQueue<>();
-    public static void main(String... args) {
+    public static void main(String... args) throws Exception {
         ReferenceClone refClone = new ReferenceClone();
         refClone.test();
     }
 
-    public void test() {
+    public void test() throws CloneNotSupportedException {
         // test Reference::clone that throws CNSE
         Object o = new Object();
         assertCloneNotSupported(new SoftRef(o));
@@ -45,9 +45,7 @@ public class ReferenceClone {
 
         // Reference subclass may override the clone method
         CloneableReference ref = new CloneableReference(o);
-        try {
             ref.clone();
-        } catch (CloneNotSupportedException e) {}
     }
 
     private void assertCloneNotSupported(CloneableRef ref) {
     ```

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From kbarrett at openjdk.java.net  Wed Apr 27 18:33:42 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 27 Apr 2022 18:33:42 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <sRa6R1-vECkQjvEufn9km_V9PkXhnoLyQkan37kBEBQ=.fc5404ae-5fa2-4d9e-832b-463b4b32fa80@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
 <Isqy_M25PRbTsUfG1segg3Cz3Iov8PAytVik2-F4V7o=.ecea58e0-90c6-4586-aae7-75530afd90b8@github.com>
 <ABwJ4s9Y7jru4drg1ZNgszV1y6xebSj8IvW3ORtuGwE=.947c2d0f-15d8-47d5-abe8-56bc446033ab@github.com>
 <sRa6R1-vECkQjvEufn9km_V9PkXhnoLyQkan37kBEBQ=.fc5404ae-5fa2-4d9e-832b-463b4b32fa80@github.com>
Message-ID: <_lfE5CHC3Jv6K2rCQw9nKY_OLY4COB4oz4Zkg5VEeZw=.ea09ccc9-e7b1-41ed-bbc1-079597fac0a2@github.com>

On Wed, 27 Apr 2022 18:25:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> That was my initial thought, but it doesn't work - CNSE is a checked exception so must be handled.
>
>> test() and main will need to declare this checked exception.
> 
> 
> diff --git a/test/jdk/java/lang/ref/ReferenceClone.java b/test/jdk/java/lang/ref/ReferenceClone.java
> index bd1ead81bec..2f9386b81e4 100644
> --- a/test/jdk/java/lang/ref/ReferenceClone.java
> +++ b/test/jdk/java/lang/ref/ReferenceClone.java
> @@ -31,12 +31,12 @@ import java.lang.ref.*;
>  
>  public class ReferenceClone {
>      private static final ReferenceQueue<Object> QUEUE = new ReferenceQueue<>();
> -    public static void main(String... args) {
> +    public static void main(String... args) throws Exception {
>          ReferenceClone refClone = new ReferenceClone();
>          refClone.test();
>      }
>  
> -    public void test() {
> +    public void test() throws CloneNotSupportedException {
>          // test Reference::clone that throws CNSE
>          Object o = new Object();
>          assertCloneNotSupported(new SoftRef(o));
> @@ -45,9 +45,7 @@ public class ReferenceClone {
>  
>          // Reference subclass may override the clone method
>          CloneableReference ref = new CloneableReference(o);
> -        try {
>              ref.clone();
> -        } catch (CloneNotSupportedException e) {}
>      }
>  
>      private void assertCloneNotSupported(CloneableRef ref) {
>      ```

Yes, that would work.  But I'd rather keep the code for that subtest close together, i.e. as currently written.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From erikj at openjdk.java.net  Wed Apr 27 18:45:50 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 27 Apr 2022 18:45:50 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <5-HeJlcacDvbVk9KSvjZuq9oVSneaCrDOB7F7hn-dJY=.63974f0b-5f61-4141-85de-43fe83af0fc0@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

Requiring different windows versions in different parts of the product doesn't make much sense, but I think it's even worse trying to keep all these different locations in sync. At least most of these have a comment explaining why that particular Windows version is required there. Changing these values invalidates those comments. 

If we are to do something about this, then we need to define this macro in a central location, and verify the value in configure. Then we would provide it either on compile command lines, or in a globally included config.h.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From dlong at openjdk.java.net  Wed Apr 27 19:11:17 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 27 Apr 2022 19:11:17 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <P0TwJAR4MZcU_GPwik-FJa2fS8tVPXwYAz_-V_I8EIA=.51e9f0d6-128c-4c76-880d-97250ad5e7d0@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Wed Apr 27 19:23:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 27 Apr 2022 19:23:45 GMT
Subject: Integrated: 8285658: Fix two typos in the spec of
 j.u.random.RandomGenerator
In-Reply-To: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
References: <WxCOHDn-AxuAJB2SWKEB-10w48RRzZ9yPoWwnUuSPTE=.0be2dddc-8d64-4c32-bf17-daa443b2ac39@github.com>
Message-ID: <feprrQqRPD5R0qp4eJWDW-tWGwm8li4Uz01Jmp0DiSo=.b0d25460-a8f8-4fd6-b6d3-2bd23a84332b@github.com>

On Tue, 26 Apr 2022 16:38:37 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values.

This pull request has now been integrated.

Changeset: 1f868f1d
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f868f1d091602cc462ee0fe5fa613a3638a5f1c
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8285658: Fix two typos in the spec of j.u.random.RandomGenerator

Reviewed-by: bpb, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8404

From alanb at openjdk.java.net  Wed Apr 27 19:25:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 19:25:53 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <uTZJkUXe_HjgUnwObE0_JcvLQqYK941hMnsiNT4ykgY=.3bc2612a-a53b-441c-afee-e9abb86bd5f9@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <uTZJkUXe_HjgUnwObE0_JcvLQqYK941hMnsiNT4ykgY=.3bc2612a-a53b-441c-afee-e9abb86bd5f9@github.com>
Message-ID: <B1D90Hy321EJQAgk9WL5LFd-Js380-Q0h9tb9zn-1gE=.95aaf056-5dd6-43bd-9f86-9a7b5bc47841@github.com>

On Wed, 27 Apr 2022 17:53:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122:
> 
>> 120:      */
>> 121: 
>> 122:     public static final int SCOPED_CACHE_SHIFT;
> 
> I can't find this constant being used.   If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now.

It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it.

> src/java.management/share/classes/sun/management/ThreadImpl.java line 447:
> 
>> 445:         if (threads != null) {
>> 446:             long[] tids = Stream.of(threads)
>> 447:                     .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread))
> 
> Returning an array of thread IDs of just the platform threads is good.   The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...."

I think you mean the comment on the private method. Yes, that could be clearer that it just returns platform threads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From blackdrag at gmx.org  Wed Apr 27 19:26:01 2022
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Wed, 27 Apr 2022 21:26:01 +0200
Subject: Floating Point Repair?
In-Reply-To: <B07oVK5dIW_4UlWajbFJho9hLYFi4_XF7jPHpp-NHBdY46Tte8Xw5gSK7v19gtQlK6Okw3vN5GDbshNG-D-irlq5RRp-ktOTIKnkwleTHUE=@protonmail.com>
References: <B07oVK5dIW_4UlWajbFJho9hLYFi4_XF7jPHpp-NHBdY46Tte8Xw5gSK7v19gtQlK6Okw3vN5GDbshNG-D-irlq5RRp-ktOTIKnkwleTHUE=@protonmail.com>
Message-ID: <1d2bf215-6c21-1713-428a-e87cfa9450a1@gmx.org>

On 27.04.22 12:47, sminervini.prism wrote:
> To the Java OpenJDK Java Community Process,
[...]

You could propose a new data type that follows BCDs from IEE754-2008.
You would have to define conversions of course.

You would have to of course define type conversions, find somebody doing
whatever a JSR is today, extend hotspot and the java compiler, or
prototype with a software emulation.

bye Jochen

From smarks at openjdk.java.net  Wed Apr 27 19:29:55 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 19:29:55 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v20]
In-Reply-To: <HtzrBgqCSFojC7IBMWpx6Pt9vkLthcnyLQpSW95JtmA=.3bc61a82-9a33-4976-8019-d08e42ba1ac5@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <HtzrBgqCSFojC7IBMWpx6Pt9vkLthcnyLQpSW95JtmA=.3bc61a82-9a33-4976-8019-d08e42ba1ac5@github.com>
Message-ID: <U732gQ0c4q7xUeCC0m8s_8eWKALojLrNOu0EqeEQ67I=.be7f9cc2-dee7-4fc1-bbe2-c9fce99a235c@github.com>

On Thu, 21 Apr 2022 03:48:21 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update setSeed docs on Random class
>  - Add nicer toString method to random wrapper

Hi, thanks for the updates.

I've made some modifications to the specs of `setSeed` and `next(bits)` for good measure, since the latter also needed to be updated to accommodate overrides made by subclasses. If these changes are satisfactory, please pull them into this PR, and I'll update the CSR correspondingly. Changes are in this branch:

https://github.com/stuart-marks/jdk/tree/JDK-8279598-RandomGenerator-adapter

-------------

PR: https://git.openjdk.java.net/jdk/pull/7001

From dlong at openjdk.java.net  Wed Apr 27 19:46:58 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 27 Apr 2022 19:46:58 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <rOdvKm1tC2KRCNzwpnTYw_MIH8bCnCZyU5FgUzMGpa8=.e877f726-8703-44cb-b14f-295866710f26@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

The compiler changes look good to me.

Marked as reviewed by dlong (Reviewer).

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Wed Apr 27 19:46:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 27 Apr 2022 19:46:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <fSQVmpuuXBGki_vrs-PRM0ITQvlhhbyRlZV8HBad8_8=.17704f38-9bb7-43fa-8e70-c215b092d1f8@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ikkqB-rNQuSTCkDKnFOAJs6H4-9DKFQSKyEQF5D-Qws=.4590c717-4914-43cd-9cf4-18933929c9d6@github.com>
 <MCiXAUIRNna0vA9Pmj3mbWzJkE9suqqVl9UzN_Hom3s=.7fb27bf8-b583-4f01-ae30-a44ecc4bd111@github.com>
 <fSQVmpuuXBGki_vrs-PRM0ITQvlhhbyRlZV8HBad8_8=.17704f38-9bb7-43fa-8e70-c215b092d1f8@github.com>
Message-ID: <-k-fd3inPeP7D7elq5T4NOXMUrScsScjLsBqx3q6ucI=.37b4419d-32f1-48af-9c41-09979ca578ce@github.com>

On Wed, 27 Apr 2022 18:16:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer.
>
> It's not critical and no problem if this is cleaned up as a follow-up.

Good idea, this could be improved. As Paul says, it's not performance critical as this is a diagnostic option for printing the stack trace when pinned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Wed Apr 27 19:47:01 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Apr 2022 19:47:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <ogb--lLTzf2-7rfNk7W_Aq2OlVyCs4av1CMM7dyEuZ8=.932c4168-5818-48e3-9e6c-2961bcbd2d57@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45:

> 43:  * threads is unbounded.
> 44:  */
> 45: class ThreadPerTaskExecutor implements ExecutorService {

This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`.

`SharedThreadContainer` supports a number of different shared container policies that could be made clearer.

Architecturally i think this could be better layered but it can be iterated on later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Wed Apr 27 20:14:59 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Apr 2022 20:14:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <7hqD-RqcX58pubiORXgyjVjuyg_-yi1NZqJ8CJIPH20=.480769c3-4033-4741-904d-10c77de38cc4@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/java.base/share/classes/java/lang/Thread.java line 116:

> 114:  * <em>carrier threads</em>. Locking and I/O operations are examples of operations
> 115:  * where a carrier thread may be re-scheduled from one virtual thread to another.
> 116:  * Code executing in a virtual thread is not aware of underlying carrier thread.

Suggestion:

 * Code executing in a virtual thread is not aware of the underlying carrier thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From bpb at openjdk.java.net  Wed Apr 27 20:20:05 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Apr 2022 20:20:05 GMT
Subject: RFR: 8285745: Re-examine PushbackInputStream mark/reset
Message-ID: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>

Please review this request to remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.PushbackInputStream`.

-------------

Commit messages:
 - 8285745: Re-examine PushbackInputStream mark/reset

Changes: https://git.openjdk.java.net/jdk/pull/8433/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8433&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285745
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8433/head:pull/8433

PR: https://git.openjdk.java.net/jdk/pull/8433

From bpb at openjdk.java.net  Wed Apr 27 20:20:06 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Apr 2022 20:20:06 GMT
Subject: RFR: 8285745: Re-examine PushbackInputStream mark/reset
In-Reply-To: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
References: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
Message-ID: <TLXJj4jSEpD0BIWSJNm7I9-axckUD1VwyHOfw9AF-hU=.425cb3d8-2a4e-4f29-90e8-6699de39e377@github.com>

On Wed, 27 Apr 2022 20:10:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this request to remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.PushbackInputStream`.

Please see also https://github.com/openjdk/jdk/pull/8309.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8433

From naoto at openjdk.java.net  Wed Apr 27 20:30:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 20:30:10 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8
Message-ID: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>

Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.

-------------

Commit messages:
 - 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8

Changes: https://git.openjdk.java.net/jdk/pull/8434/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8434&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272352
  Stats: 13 lines in 1 file changed: 3 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8434/head:pull/8434

PR: https://git.openjdk.java.net/jdk/pull/8434

From duke at openjdk.java.net  Wed Apr 27 22:04:11 2022
From: duke at openjdk.java.net (altrisi)
Date: Wed, 27 Apr 2022 22:04:11 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
Message-ID: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>

Changes the definition of `CollectorImpl` to be a record.

-------------

Commit messages:
 - Remove explicit `static` modifier
 - 8284640: CollectorImpl class could be a record class

Changes: https://git.openjdk.java.net/jdk/pull/8179/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8179&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284640
  Stats: 43 lines in 1 file changed: 0 ins; 37 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8179.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8179/head:pull/8179

PR: https://git.openjdk.java.net/jdk/pull/8179

From duke at openjdk.java.net  Wed Apr 27 22:04:12 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 27 Apr 2022 22:04:12 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <E0eM7y5Y4V-1jltpIv8IDn6GrvcuoUGNpuDKfCo93vc=.82a93388-63b1-431f-8d23-cd91ce965086@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.java.net> wrote:

> Changes the definition of `CollectorImpl` to be a record.

src/java.base/share/classes/java/util/stream/Collectors.java line 197:

> 195:      * @param <R> the type of the result
> 196:      */
> 197:     static record CollectorImpl<T, A, R>(Supplier<A> supplier,

Suggestion:

    record CollectorImpl<T, A, R>(Supplier<A> supplier,

[Nested records are implicitly static.](https://docs.oracle.com/javase/specs/jls/se18/html/jls-8.html#jls-8.10-220)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8179

From dholmes at openjdk.java.net  Wed Apr 27 22:25:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 27 Apr 2022 22:25:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <rWorImiZNvGNpXp8KHtwgCoB2Tb14yf_u0NrjWj_U5U=.e68fed00-088f-485d-a00d-c0e82b4ee430@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

There is obviously a lot of history here and different parts of the codebase had hit different minimum OS version requirements at different times. While at one time we would have had to cater for building on systems with and without a given API those days are long gone for the code being touched here (AFAICS). As Erik states we should be able to set a minimum _WIN32_WINNT_ value needed to build all the codebase and simply have that checked and set at configure time. The code itself would not need to define _WIN32_WINNT.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From mchung at openjdk.java.net  Wed Apr 27 22:31:07 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 27 Apr 2022 22:31:07 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <O12IAPAOEmnh67lVIwNMOpHDQD-fm8-TfkSFUypwjz8=.401bbed4-1bba-443a-9d3a-b9fa2b4628de@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I reviewed most of the source files in `java.base` except `java.util.concurrent`.  I also reviewed `java.logging`, `java.management` and `jdk.management` modules.   The changes are easy to follow and clean.  Looks good to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From psandoz at openjdk.java.net  Wed Apr 27 22:43:45 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 27 Apr 2022 22:43:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <fRMZ3g8JU4pbbQcxq7mBdqBZ-jkXTF-8hkwUXR7YDcg=.a0646c66-09e8-4168-a620-e0b692067852@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

It's great to see end game in play for this multi-year effort, impressive work by all involved.

I looked through code in the base module. Generally looks well structured and documented.

The fork join code is naturally hard to review. I did try! (it takes the prize for the highest Java code density in the JDK). I mostly looked for regular and repeated structure rather than trying to fully understand/review the intricate concurrency details.

IMO there is some post integration work to do around the architecture of thread containers, i presume the structured concurrency implementation (use of thread flock) will help with that.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Wed Apr 27 22:53:03 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 22:53:03 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version
Message-ID: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>

Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.

Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764

I'll update copyright years before an integration.

-------------

Commit messages:
 - Update comment in template.
 - JDK-8285497: Add system property for Java SE specification maintenance version

Changes: https://git.openjdk.java.net/jdk/pull/8437/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285764
  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From jiefu at openjdk.java.net  Wed Apr 27 23:01:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Apr 2022 23:01:44 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <Fz-GFQl2ITQuVDvPA5pGh1JDhez15gT8jAEO0iJwGmA=.47673f6c-6d8c-4b02-9feb-380f75ddc96f@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
 <Fz-GFQl2ITQuVDvPA5pGh1JDhez15gT8jAEO0iJwGmA=.47673f6c-6d8c-4b02-9feb-380f75ddc96f@github.com>
Message-ID: <AvDBoHeEdaKADJWGfGeK8n71j_jzX-AjxkGOGcxk6X0=.083bf2ed-b814-440b-8b71-19f495765790@github.com>

On Wed, 27 Apr 2022 17:17:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Thanks, looks good, we will need to create a CSR. Have you done that before?

No, and I don't know much about a CSR.
Is there any example for a doc fix CSR to follow?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From bpb at openjdk.java.net  Wed Apr 27 23:10:10 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 27 Apr 2022 23:10:10 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <3XCjG_IelbjoKjjlqgOq0me4CmVTvVNP-cUMgi2W8V4=.53a46e15-552c-4962-a620-5d97a85c138d@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

The changes to the `java.io` package and related files in `libjava`, and the changes to the non-networking parts of the `java.nio.channels`, `sun.nio.ch`, and `sun.nio.fs` packages and related files in `libnio` all look fine to me.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Wed Apr 27 23:10:43 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:10:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
Message-ID: <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>

On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> src/java.base/share/classes/java/util/AbstractMap.java line 601:
> 
>> 599:      * {@code Map.entrySet().toArray}.
>> 600:      *
>> 601:      * @param <K> the type of keys maintained
> 
> Please update to match java.util.Map, which says "the type of keys maintained by this map"

I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.

> src/java.base/share/classes/java/util/Dictionary.java line 44:
> 
>> 42:  * @param <K> the type of keys
>> 43:  * @param <V> the type of mapped values
>> 44:  *
> 
> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.

The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From duke at openjdk.java.net  Wed Apr 27 23:14:14 2022
From: duke at openjdk.java.net (Shruthi)
Date: Wed, 27 Apr 2022 23:14:14 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java
Message-ID: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>

Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java

The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

-------------

Commit messages:
 - Removing Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java

Changes: https://git.openjdk.java.net/jdk/pull/8318/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285097
  Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Wed Apr 27 23:14:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 27 Apr 2022 23:14:14 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <qpaEfv4krCI5whWbxRXaSP1os36_5pOAJTQbSASq53Y=.45bf2304-7d33-4e7e-9c74-4e50040a1c69@github.com>

On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi <duke at openjdk.java.net> wrote:

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

@shruacha1234, a few notes specific to openJDK PRs:
- Please change the issue name to: "8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java" this will correctly link the issue in bugs.openjdk.net
- Please enable github actions. This allows the pre-tests to run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Wed Apr 27 23:14:15 2022
From: duke at openjdk.java.net (Shruthi)
Date: Wed, 27 Apr 2022 23:14:15 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <GQPlQMlWNGyos8hgD6tMd1UIryRrD1jrK9b_dUmj_GU=.2869a442-22db-47e6-a04c-53e8528d1e2f@github.com>

On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi <duke at openjdk.java.net> wrote:

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

This contribution is on behalf of my employer, IBM, which is a corporate OCA signatory.

`/covered`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From darcy at openjdk.java.net  Wed Apr 27 23:15:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:15:42 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces
In-Reply-To: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
Message-ID: <FqWMvgtk0Spd3D-dO9NYW5AFX7RKzroP49uZczgJm3E=.d0fabe8c-0df2-42f3-a08d-adad36c419e1@github.com>

On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96:
> 
>> 94:  *
>> 95:  * @param <T> the Java type that instances described by this type must
>> 96:  * have.
> 
> Instead of "instances" - would it be more correct to say "array elements"?

Will change to "the Java component type that arrays described by ArrayType must have"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From jiefu at openjdk.java.net  Wed Apr 27 23:16:47 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 27 Apr 2022 23:16:47 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8
In-Reply-To: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
Message-ID: <WmPuJuzSMIHlgB1oMCrVib0WW2TnWBPJqAcjbEF8FcA=.3b6f59d9-6043-42cd-b04b-f85572530e17@github.com>

On Wed, 27 Apr 2022 20:23:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.

Is it possible to write a jtreg test for this fix?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8434

From darcy at openjdk.java.net  Wed Apr 27 23:21:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:21:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <rfkwVrxJUYtAglhFuLinI39eAp43OOLUutHk_yTO8Es=.4191cbf0-e27c-48b3-bbf9-bff30684d10b@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8285676
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/fe47dd2f..e0ac5dcb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00-01

  Stats: 5958 lines in 128 files changed: 4827 ins; 485 del; 646 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Wed Apr 27 23:21:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 27 Apr 2022 23:21:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <Yowb9HvfI12BYoNV5lO8UNm3n19-kn6QLGAqjnJPvDk=.658abf24-fbcc-4100-bc38-69e9fcc2e6cc@github.com>
Message-ID: <EL78CD9RDpLjQbXH_gjyKLrDIEL4cF0ASceOdtkSqYc=.d8df7bd0-6307-4c27-9116-faecf433b872@github.com>

On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8285676
>>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
>
> src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60:
> 
>> (failed to retrieve contents of file, check the PR for context)
> I would suggest to say "that values described by this type"...

Will change to "the Java type that values described by this SimpleType must have."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From naoto at openjdk.java.net  Wed Apr 27 23:27:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 27 Apr 2022 23:27:50 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8
In-Reply-To: <WmPuJuzSMIHlgB1oMCrVib0WW2TnWBPJqAcjbEF8FcA=.3b6f59d9-6043-42cd-b04b-f85572530e17@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
 <WmPuJuzSMIHlgB1oMCrVib0WW2TnWBPJqAcjbEF8FcA=.3b6f59d9-6043-42cd-b04b-f85572530e17@github.com>
Message-ID: <NTwYN1C4RGTYzoJ34GyQfo7UtdWtSWfw2HQu5JUT1yc=.a7283e42-889d-4636-b1cd-0a1eaeae439d@github.com>

On Wed, 27 Apr 2022 23:12:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Is it possible to write a jtreg test for this fix? Thanks.

I am happy to write a test if possible, but AFAIK it requires configuring Windows settings (and reboot), so I don't think jtreg is capable of doing so. Thus I added `noreg-hard` to the JBS issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8434

From smarks at openjdk.java.net  Wed Apr 27 23:31:55 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 27 Apr 2022 23:31:55 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v2]
In-Reply-To: <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
 <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
Message-ID: <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>

On Wed, 27 Apr 2022 23:04:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/AbstractMap.java line 601:
>> 
>>> 599:      * {@code Map.entrySet().toArray}.
>>> 600:      *
>>> 601:      * @param <K> the type of keys maintained
>> 
>> Please update to match java.util.Map, which says "the type of keys maintained by this map"
>
> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.

Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map".

>> src/java.base/share/classes/java/util/Dictionary.java line 44:
>> 
>>> 42:  * @param <K> the type of keys
>>> 43:  * @param <V> the type of mapped values
>>> 44:  *
>> 
>> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map.
>
> The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it.

My bad, `Dictionary` was not retrofitted to implement `Map` but it gained `K` and `V` type parameters to align with `Map`. No need to change this; it doesn't really matter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From psandoz at openjdk.java.net  Thu Apr 28 00:11:40 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 28 Apr 2022 00:11:40 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
Message-ID: <oqlXj6g1S-HmkXhXrppzJl43kBAMr7aueCvopb4KVck=.68834b5b-a7b6-4eef-bf70-b8e169bb0706@github.com>

On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - Merge branch 'master' into JDK-8284992
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - 8284992: Fix misleading Vector API doc for LSHR operator

I created one, filled it in, and assigned it to you (for other examples you can search in the issue tracker, this one quite is simple so i thought it was quicker to do myself to show you). For any specification change we need to review and track that change (independent of any implementation changes, if any).

If you are ok with it I can add myself as reviewer, then you can "Finalize" it (see button on same line as "Edit"), triggering a review request, from which we may receive comments to address, and once addressed and final, it will unblock the PR for integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From coleenp at openjdk.java.net  Thu Apr 28 00:31:46 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 28 Apr 2022 00:31:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <mjizGXkzJW0HajOva2bxTSMhWM8YtPOeyaXZ0oAIqHI=.845a9df7-3201-4480-8b4c-9f643201f48f@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I've reviewed the new files in Hotspot runtime and the cpu directories, as well as the changes to existing files in runtime, oops, utilities, interpreter and classfile.
I'm happy to approve this PR. Thank you to everyone for their hard work in reviewing this code, and well done to @pron and @AlanBateman and all the loom team for bringing us this significant and exciting new feature for Java!

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388:

> 2386: }
> 2387: 
> 2388: void

@sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration.  It looks so strange.  I noticed that it's pre-existing for other functions in this file.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From sviswanathan at openjdk.java.net  Thu Apr 28 00:50:40 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 28 Apr 2022 00:50:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
Message-ID: <Zs4vCQJvlQMoBVVbQ-EWeIad-aN48Gddsh-ft51_6PQ=.01b18a0c-b15e-4791-95be-895a413080f0@github.com>

On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename the "usePred" to "offsetInRange"

Rest of the patch looks good to me.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1232:

> 1230:   // out when current case uses the predicate feature.
> 1231:   if (!supports_predicate) {
> 1232:     bool use_predicate = false;

If we rename this to needs_predicate it will be easier to understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From jiefu at openjdk.java.net  Thu Apr 28 01:24:31 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Apr 2022 01:24:31 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <oqlXj6g1S-HmkXhXrppzJl43kBAMr7aueCvopb4KVck=.68834b5b-a7b6-4eef-bf70-b8e169bb0706@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
 <oqlXj6g1S-HmkXhXrppzJl43kBAMr7aueCvopb4KVck=.68834b5b-a7b6-4eef-bf70-b8e169bb0706@github.com>
Message-ID: <2DJBWb-HkCKrwfKIMEnziafFtYrzWnZOOBPW_MkfdUM=.b1171b9a-ec44-4934-9fa1-f43c44bfcff3@github.com>

On Thu, 28 Apr 2022 00:08:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I created one, filled it in, and assigned it to you (for other examples you can search in the issue tracker, this one quite is simple so i thought it was quicker to do myself to show you). For any specification change we need to review and track that change (independent of any implementation changes, if any).
> 
> If you are ok with it I can add myself as reviewer, then you can "Finalize" it (see button on same line as "Edit"), triggering a review request, from which we may receive comments to address, and once addressed and final, it will unblock the PR for integration.

Thanks @PaulSandoz for your help.

Yes, I think it's good enough.

I made a small change which just adding a `(`.
<img width="664" alt="image" src="https://user-images.githubusercontent.com/19923746/165657177-f44f7f7d-44da-4921-a98c-5f6b9a3d9e36.png">

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From darcy at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to more review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/e0ac5dcb..db4919a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410

From prr at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <WSNF09SBgw2xrvMnmYct_zfP7iLL_QWUJ2BMs7SCzTg=.dde930a6-f976-4de9-85ba-d0c1bf094660@github.com>

On Thu, 28 Apr 2022 01:31:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Thu Apr 28 01:34:19 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 01:34:19 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <RP5pEdBu7p3ahgfvtS8xGO42CfAqviuauaYR6Iq_HZw=.f150aa97-e496-41c2-96b5-011975f9a112@github.com>
 <RMzI2aRmREJTRF1hSH5u1MGcDtmwsYsyMz7Ft5qAYiI=.f9088e0f-f0ff-4d24-9538-d7392b86e7e3@github.com>
 <fkKoR7pfREQcqsmRI_-jRBbhdLZKwRXZy_M5Ds9NJRw=.07181639-b665-4781-b2ac-3c839611f19e@github.com>
Message-ID: <sKsmjRtcuOZvIyMTUBHXWUbsfNj4Gesl0jQVM5sck08=.72b0f059-77ec-438b-916d-1a5483bd49a2@github.com>

On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred.
>
> Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map".

Will change to the Map.Entry wording "the type of key" and "the type of the value", respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From sspitsyn at openjdk.java.net  Thu Apr 28 02:24:53 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 28 Apr 2022 02:24:53 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <mjizGXkzJW0HajOva2bxTSMhWM8YtPOeyaXZ0oAIqHI=.845a9df7-3201-4480-8b4c-9f643201f48f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <mjizGXkzJW0HajOva2bxTSMhWM8YtPOeyaXZ0oAIqHI=.845a9df7-3201-4480-8b4c-9f643201f48f@github.com>
Message-ID: <r2kycXXhkOw897_1XhZ_Xrrpzusp5ftJr9pANHYO9tg=.3b796459-762c-4ebc-9af4-fb66a5467bca@github.com>

On Wed, 27 Apr 2022 19:00:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388:
> 
>> 2386: }
>> 2387: 
>> 2388: void
> 
> @sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration.  It looks so strange.  I noticed that it's pre-existing for other functions in this file.

I'm okay to follow any style. We can do it after the integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Thu Apr 28 03:10:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 28 Apr 2022 03:10:37 GMT
Subject: RFR: 8285745: Re-examine PushbackInputStream mark/reset
In-Reply-To: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
References: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
Message-ID: <4eL-IO15XeRUHMCBAhgMPLFsSmSPssPfTjxBKm_6PZ4=.46e01f02-bee7-4873-8bf3-cc0f432ce62d@github.com>

On Wed, 27 Apr 2022 20:10:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this request to remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.PushbackInputStream`.

Looks fine to me.
Given that `mark()` currently is a no-op and `reset()` throws an exception, the `synchronized` wouldn't be doing anything when it comes to calls on an exact instance of `PushbackInputStream`.
Calls on subclasses of `PushbackInputStream` which did support mark/reset, would be overriding this method already and handling any synchronization themselves.

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8433

From joehw at openjdk.java.net  Thu Apr 28 04:01:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 28 Apr 2022 04:01:44 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <u9gF9k2y8vWPI4XNfHZGlavyDbAR1_TAl83Ia22Eh88=.ba9b7609-9fb6-4b07-a115-f02c1bae4e10@github.com>

On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi <duke at openjdk.java.net> wrote:

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java line 598:

> 596:        "rtf() not supported by XRTreeFragSelectWrapper"},
> 597: 
> 598:   { ER_ASNODEITERATOR_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER,

Please replace the usage in XRTreeFragSelectWrapper, and also update the LastModified tag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From alanb at openjdk.java.net  Thu Apr 28 05:21:44 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 05:21:44 GMT
Subject: RFR: 8285745: Re-examine PushbackInputStream mark/reset
In-Reply-To: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
References: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
Message-ID: <DREQu9xEbq8YG7208-e2khl5lu4qMF4usNzLv9G2r9k=.e01e52a8-6ae9-49af-a022-25c0ee630c25@github.com>

On Wed, 27 Apr 2022 20:10:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this request to remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.PushbackInputStream`.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8433

From smarks at openjdk.java.net  Thu Apr 28 05:29:56 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 28 Apr 2022 05:29:56 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <aUtXb7RXWV5F1pwZgBZHPPgjufuY4g86HbYhQZz3fTc=.e535eddb-6a1e-40e7-8c02-0c4acbf02799@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Reviewed java.io, java.lang, java.lang.ref.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From jbhateja at openjdk.java.net  Thu Apr 28 06:30:42 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 28 Apr 2022 06:30:42 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <ShLFw_aG07Xu9hESNnl8dRU6l2oLAlSubKfCPRwkYFg=.be04c9e4-d18d-486f-b502-a6c207400d92@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <qGT_pT7bJXtmGLdET7zfdn61OCP6K0qO3druyXapADc=.86ab137e-49d0-437c-ae54-90370c270ef6@github.com>
 <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com>
 <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com>
 <kqI-nPVHEWDVrqR16zP0gvSnLZJZhyFAmJ4maHvqqD8=.fec2585b-9785-478c-aa1c-5e80f320863c@github.com>
 <ObTJCUgfcC_HWOapui4POW4nfZ5WljmJtSQaKewL21U=.d4591ddf-0dbe-42b3-99fe-0faf376eaf08@github.com>
 <CFDqLPf7iBeKTwj_20Imdqm1RbxqV8CA7rgtMZLvkfk=.d5c9224e-e3a3-4db6-b22b-e5b9c873ae26@github.com>
 <ShLFw_aG07Xu9hESNnl8dRU6l2oLAlSubKfCPRwkYFg=.be04c9e4-d18d-486f-b502-a6c207400d92@github.com>
Message-ID: <bQs1apWI699XqCJH1JrSr0oL0Jfj6dTV0_PlWPj6CWQ=.4e540227-431a-4cf1-962b-b43ec3e97ca1@github.com>

On Wed, 20 Apr 2022 02:44:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values.
>> 
>> It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary.  Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios.
>
> Thanks for the comment! So how about adding the check for the valid array range like the masked vector load?
> Codes like:
> 
> public final
>     void intoArray(byte[] a, int offset,
>                    VectorMask<Byte> m) {
>         if (m.allTrue()) {
>             intoArray(a, offset);
>         } else {
>             ByteSpecies vsp = vspecies();
>             if (offset >= 0 && offset <= (a.length - vsp.length())) {     // a full range check
>                 intoArray0(a, offset, m, /* usePred */ false);                   // can be vectorized by load+blend_store
>             } else {
>                 checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>                 intoArray0(a, offset, m, /* usePred */ true);                    // only be vectorized by the predicated store
>             }
>         }
>     }

Thanks, this looks ok since out of range condition will not be intrinsified if targets does not support predicated vector store.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From mbaesken at openjdk.java.net  Thu Apr 28 07:16:38 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Apr 2022 07:16:38 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
Message-ID: <jTYB50MGyVQqaGZ8LsgICew0lkS-GYdN9UCjkKsM0y0=.a14f468d-1d6d-4cad-a012-0f030a5f1313@github.com>

On Wed, 27 Apr 2022 15:10:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> src/java.base/windows/native/libnio/ch/wepoll.c line 159:
> 
>> 157: 
>> 158: #undef _WIN32_WINNT
>> 159: #define _WIN32_WINNT 0x0601
> 
> This is 3rd party code and would prefer not change it if possible.

Hi Alan, I agree (thats why I did not change the define in harfbuzz,  but I missed that wepoll.c is 3rd party code as well).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Thu Apr 28 07:19:42 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Apr 2022 07:19:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

Hi Erik/David/Phil, we already have a good central place where we set the definition of WIN32_LEAN_AND_MEAN 

autoconf/flags-cflags.m4:460:    ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE \
autoconf/flags-cflags.m4:462:    ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN"

should we add there the _WIN32_WINNT=0x0601  define  (and remove the differing defines instead at the other places) ?
(defines of _WIN32_WINNT in 3rd party code would stay like wepoll.c and harfbuzz).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From aph at openjdk.java.net  Thu Apr 28 07:46:45 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 28 Apr 2022 07:46:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <B1D90Hy321EJQAgk9WL5LFd-Js380-Q0h9tb9zn-1gE=.95aaf056-5dd6-43bd-9f86-9a7b5bc47841@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <uTZJkUXe_HjgUnwObE0_JcvLQqYK941hMnsiNT4ykgY=.3bc2612a-a53b-441c-afee-e9abb86bd5f9@github.com>
 <B1D90Hy321EJQAgk9WL5LFd-Js380-Q0h9tb9zn-1gE=.95aaf056-5dd6-43bd-9f86-9a7b5bc47841@github.com>
Message-ID: <O6or7w1SICB-i2sYeTyKRXsE4dHE4gHH-yQCR1vrmQU=.ae17ac0d-615d-4e40-8753-dfefc4e330ea@github.com>

On Wed, 27 Apr 2022 19:21:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122:
>> 
>>> 120:      */
>>> 121: 
>>> 122:     public static final int SCOPED_CACHE_SHIFT;
>> 
>> I can't find this constant being used.   If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now.
>
> It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it.

Yes, it's dead. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu Apr 28 07:52:58 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 07:52:58 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ogb--lLTzf2-7rfNk7W_Aq2OlVyCs4av1CMM7dyEuZ8=.932c4168-5818-48e3-9e6c-2961bcbd2d57@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ogb--lLTzf2-7rfNk7W_Aq2OlVyCs4av1CMM7dyEuZ8=.932c4168-5818-48e3-9e6c-2961bcbd2d57@github.com>
Message-ID: <ZvIynG2LVg-copZPWGLqklGHpKGEsAWw4DutIxyTFX8=.143feb69-5ac7-4896-a220-af0f656981c7@github.com>

On Wed, 27 Apr 2022 19:43:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45:
> 
>> 43:  * threads is unbounded.
>> 44:  */
>> 45: class ThreadPerTaskExecutor implements ExecutorService {
> 
> This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`.
> 
> `SharedThreadContainer` supports a number of different shared container policies that could be made clearer.
> 
> Architecturally i think this could be better layered but it can be iterated on later.

Indeed, the layering is a bit awkward and I plan to replace it. It came about as a short term solution to avoid double bookkeeping of virtual threads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From dfuchs at openjdk.java.net  Thu Apr 28 08:03:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 28 Apr 2022 08:03:43 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <N43fg2ZtC9VIYO6SXPz4dxYjotBQhGA2Fz5iliN_eEg=.6fd7ceac-fbde-4d97-a6cc-5c5e16a70ec9@github.com>

On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Thanks for the updates Joe. Your new wording looks good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8410

From alanb at openjdk.java.net  Thu Apr 28 08:14:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 08:14:25 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
Message-ID: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>

On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55:

> 53:  * against the <i>original path</i> of the directory (irrespective of if the
> 54:  * directory is moved since it was opened).
> 55:  * @param <T> the type of path

It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead?

src/java.base/share/classes/java/nio/file/WatchEvent.java line 51:

> 49:     /**
> 50:      * An event kind, for the purposes of identification.
> 51:      * @param <T> the type of the context value

This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From shade at openjdk.java.net  Thu Apr 28 08:32:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Apr 2022 08:32:49 GMT
Subject: Integrated: 8283994: Make Xerces DatatypeException stackless
In-Reply-To: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
References: <fJ2pMRMsfluAfRl4t-Z_hMDfHjCSTyBJG3Vpt1qSXOo=.7c2f5699-46d6-4832-a152-708c3849b4c5@github.com>
Message-ID: <nwIl-IltbYugSK-8By6cNP4MJrkmER1vga8j3ByXiUs=.135b0cb0-de1b-4abd-a81b-00e9c90a4ebf@github.com>

On Wed, 30 Mar 2022 11:38:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug report for more details. This change improves SPECjvm2008:xml.validation for about +3%:
> 
> 
>  baseline: 298.353 ? 1.008  ops/min
>  patched:  309.912 ? 1.347  ops/min
> 
> Of course, the real improvements might be even higher, as exception might be thrown from much deeper call hierarchy.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jaxp_all`
>  - [x] Linux x86_64 fastdebug, `javax/xml`

This pull request has now been integrated.

Changeset: 85f8d14e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/85f8d14edf0128e94bfc8102619a6ddbc37ead70
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8283994: Make Xerces DatatypeException stackless

Reviewed-by: joehw, jpai

-------------

PR: https://git.openjdk.java.net/jdk/pull/8036

From jpai at openjdk.java.net  Thu Apr 28 10:27:43 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 28 Apr 2022 10:27:43 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <WWsZi9yPGIMWM7QGf2EjJn18ks5_fg3SUdQz5NBArTs=.ed8436ea-7a63-441a-896b-7c3468cd50ed@github.com>

On Wed, 27 Apr 2022 22:27:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Hello Joe, should the property description have a note stating what kind of a value this property holds, if at all present? Would it be free form text or an integer value?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From duke at openjdk.java.net  Thu Apr 28 12:23:52 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 28 Apr 2022 12:23:52 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <rWmdhDSYjBiRMBYe0JC9kialPedRcu2slvhNtkgWu3E=.55893817-ffcb-4cc4-ac40-16a3c5d2e441@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <t-qr6twHFQChMhkxeAaDsn2BVnvmncYla_2i3-jmXYk=.e3d3622e-92e6-44d6-9010-7704b96d15f0@github.com>
 <rWmdhDSYjBiRMBYe0JC9kialPedRcu2slvhNtkgWu3E=.55893817-ffcb-4cc4-ac40-16a3c5d2e441@github.com>
Message-ID: <L0LyByi4MF9Maeka1wMj0mo6FralT8tHFRUZOcr1-GE=.73ed81e7-e0d1-40a5-9fba-ce070b49d2f1@github.com>

On Wed, 27 Apr 2022 03:28:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/IdentityHashMap/Basic.java line 77:
>> 
>>> 75:         E[] contents = (E[]) c.toArray();
>>> 76: 
>>> 77:         assertEquals(c.size(), given.length);
>> 
>> I believe testng has the expected values in front in the `assertEquals` methods, as embodied in the exception messages, so this should be `assertEquals(given.length, c.size());`. Applies to other places.
>
> No, TestNG is `assertEquals(actual, expected)` which is irritatingly the opposite of JUnit.
> 
> https://github.com/cbeust/testng/blob/master/testng-asserts/src/main/java/org/testng/asserts/Assertion.java#L151
> 
> This will make things quite tedious when/if we convert to JUnit.

There?s?a?reason why?I?prefer using?[AssertJ], where?the?calls?are:

Assertions.assertThat(actual)
	.isEqualTo(expected);


[AssertJ]: https://assertj.github.io/doc

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From mullan at openjdk.java.net  Thu Apr 28 12:34:52 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Apr 2022 12:34:52 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <kSYZs8lir1GcbhdGw6FfH3evXskguzH9aeKr5wD4_6g=.70ef40fe-e67e-4231-8a5f-05d2c7a5b0b9@github.com>

On Wed, 27 Apr 2022 22:27:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Should this be added to the default permissions in the `lib/security/java.policy` file along with other similar properties?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From erikj at openjdk.java.net  Thu Apr 28 12:36:42 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 28 Apr 2022 12:36:42 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <B6xmDBhPc8oL1MWp13PNRBe1uzGr8wscK18o_Cg5ajw=.d2b9fbdc-9a73-4a7a-8aa4-a9f2ea2262bb@github.com>
Message-ID: <ea-HmEVAi3_om1Q2mI5VZBokopo16R16lIgbdFWyRKw=.d9a13032-2321-49bb-b1bd-c27dcb604367@github.com>

On Thu, 28 Apr 2022 07:16:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Erik/David/Phil, we already have a good central place where we set the definition of WIN32_LEAN_AND_MEAN
> 
> autoconf/flags-cflags.m4:460: ALWAYS_DEFINES_JDK="-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE autoconf/flags-cflags.m4:462: ALWAYS_DEFINES_JVM="-DNOMINMAX -DWIN32_LEAN_AND_MEAN"
> 
> should we add there the _WIN32_WINNT=0x0601 define (and remove the differing defines instead at the other places) ? (defines of _WIN32_WINNT in 3rd party code would stay like wepoll.c and harfbuzz).

Seems reasonable to me at least.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From jpai at openjdk.java.net  Thu Apr 28 13:21:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 28 Apr 2022 13:21:47 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <QpNLntXsiKovND5NI-RBkP6UdLyiql8aWHrlGxBBfsw=.6c82b934-7b90-4fba-a88e-38e7d7ba42f1@github.com>

On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

test/jdk/java/util/IdentityHashMap/Basic.java line 244:

> 242:     public void testKeySetNoRemove() {
> 243:         Set<Box> keySet = map.keySet();
> 244:         keySet.remove(new Box(k1a));

Should we assert here that this returns `false`?

test/jdk/java/util/IdentityHashMap/Basic.java line 253:

> 251:     public void testKeySetRemove() {
> 252:         Set<Box> keySet = map.keySet();
> 253:         keySet.remove(k1a);

Similarly should we assert `true` here and few other places in this PR which does the remove?

test/jdk/java/util/IdentityHashMap/Basic.java line 257:

> 255:         checkEntries(map.entrySet(), entry(k1b, v1b),
> 256:                                      entry(k2, v2));
> 257:     }

Would an additional check `assertFalse(map.equals(map2));` be useful here (and other similar tests where we do "remove").

test/jdk/java/util/IdentityHashMap/Basic.java line 325:

> 323:         Box newKey = new Box(k1a);
> 324:         Box newVal = new Box(v1a);
> 325:         map.put(newKey, newVal);

Should we capture the return value and assert that it is `null`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From jpai at openjdk.java.net  Thu Apr 28 13:26:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 28 Apr 2022 13:26:45 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <b3JzD_0udODqToaoGgHX3u7lriMBvzMxeYKNEelJMOo=.1745f0fb-a737-4ca6-ad22-751893e3aa32@github.com>

On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

test/jdk/java/util/IdentityHashMap/Basic.java line 337:

> 335:     public void testPutOverwrite() {
> 336:         Box newVal = new Box(v1a);
> 337:         map.put(k1a, newVal);

Should we capture the return value and assert that it's not null and is identity equal to `v1a`?

Perhaps, similarly at a few other places where we do put and putIfAbsent?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From jlahoda at openjdk.java.net  Thu Apr 28 14:45:29 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 28 Apr 2022 14:45:29 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v8]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <qW_cfdlzZbZGgZ9TFRqQs8bUPmGL8gJ5QMelV52ksfA=.8b9b34e4-67f9-48d4-ab03-7a2c331e82a1@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - Adding a test for a NPE from guards.
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/4919525d...115605ae

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=07
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From egahlin at openjdk.java.net  Thu Apr 28 14:47:16 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 28 Apr 2022 14:47:16 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168:

> 166:   assert(!tl->is_excluded(), "invariant");
> 167:   if (virtual_thread) {
> 168:     // TODO: blob cache for virtual threads

Fix this now or after integration?

src/hotspot/share/jfr/metadata/metadata.xml line 121:

> 119:     thread="true" stackTrace="true">
> 120:     <Field type="Thread" name="carrierThread" label="Carrier Thread" description="Thread enlisted as a carrier" />
> 121:     <Field type="Class" name="contClass" label="Continuation class" description="Class of the continuation" />

"Continuation class" = >" Continuation Class"
numFrames = frames
numRefs = references
"Number of interpreted frames" => "Interpreted Frames"
"Number of references" => "References"
"Stack size in bytes" => "Stack Size" contentType"bytes"

src/hotspot/share/jfr/metadata/metadata.xml line 130:

> 128:     thread="true" stackTrace="true">
> 129:     <Field type="Thread" name="carrierThread" label="Carrier Thread" description="Thread enlisted as a carrier" />
> 130:     <Field type="Class" name="contClass" label="Continuation class" description="Class of the continuation" />

contClass => continuationClass
"Continuation class" => "Continuation Class"
"Class of the continuation" Remove (not needed)
"Number of interpreted frames" => "Interpreted Frames"
numFrames => frames
"Number of references" => "References"
numRefs => references
"Stack size in bytes" => "Stack Size" contentType="bytes"

src/hotspot/share/jfr/metadata/metadata.xml line 138:

> 136:   <Event name="ContinuationFreezeYoung" experimental="true" category="Java Virtual Machine" label="Continuation Freeze Young" thread="true" stackTrace="false" startTime="false">
> 137:     <Field type="ulong" name="id" label="Continuation ID" />
> 138:     <Field type="uint" name="size" label="Size" />

"Allocated new" => "Allocated New"

src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94:

> 92: static const size_t global_buffer_size = 512 * K;
> 93: 
> 94: static const size_t thread_local_buffer_prealloc_count = 32;

Why is more memory needed? Moore's law or something specific to virtual threads?

src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81:

> 79:   be_writer.write(size);
> 80:   be_writer.write(time);
> 81:   be_writer.write(JfrTicks::now().value() - time);

Why is this changed?

src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35:

> 33: 
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread end")

"Virtual thread end" => "Virtual Thread End"
Remove description.

src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35:

> 33: 
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread pinned")

"Virtual thread pinned" => "Virtual Thread Pinned"
Remove description

src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35:

> 33: 
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread start")

"virtual thread start" => "Virtual Thread Start"
Remove description

src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35:

> 33: 
> 34: @Category({"Java Runtime"})
> 35: @Label("Virtual thread submit task failed")

The label is a bit a long, would "Virtual Thread Submit Failed" work?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From ssahoo at openjdk.java.net  Thu Apr 28 14:53:44 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Thu, 28 Apr 2022 14:53:44 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v3]
In-Reply-To: <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <88veDlkpC7cohXIhph_0qeqcyFf5vMpqX8RKjmUpn2c=.8b200a70-84b5-4af1-829d-194841c61bd0@github.com>
Message-ID: <qXLHYPxsRF7gdm0zT3t9CPGfonBmUFt2Jwoq_QsTab8=.80904ab2-f703-4629-abf6-a03af6d280e9@github.com>

On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update FileUtils.java

I will do a small change in method signature patch(Path path, int fromLine, int toLine, List<String> from, String to) where the argument "List<String> from" to be "String from". Also a new open Test will be added into this change-set.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From mgronlun at openjdk.java.net  Thu Apr 28 15:06:01 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 28 Apr 2022 15:06:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
Message-ID: <nNJlzyNCNXA3ODgQEobT8jHJErq4OLpQKoWBfjO7JMI=.d4df0210-5c08-4539-b338-0c1062be7c1f@github.com>

On Thu, 28 Apr 2022 14:37:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81:
> 
>> 79:   be_writer.write(size);
>> 80:   be_writer.write(time);
>> 81:   be_writer.write(JfrTicks::now().value() - time);
> 
> Why is this changed?

It was a small optimization attempted before the current system of writing virtual thread checkpoints in bulk. Will restore it, thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mgronlun at openjdk.java.net  Thu Apr 28 15:11:10 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 28 Apr 2022 15:11:10 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
Message-ID: <y3cGikrYbQzj0UuigEMo92nSRp-RLURyFwqVip8xNLU=.c93f2645-d053-41c6-bd93-d08a377b7538@github.com>

On Thu, 28 Apr 2022 14:41:04 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94:
> 
>> 92: static const size_t global_buffer_size = 512 * K;
>> 93: 
>> 94: static const size_t thread_local_buffer_prealloc_count = 32;
> 
> Why is more memory needed? Moore's law or something specific to virtual threads?

The carrier thread will write the metadata for the mounted virtual threads lazily with virtual threads as part of the event write. They write this thread locally, and the memory increase accommodates fewer roundtrips to fetch new buffers. The previous size was small because it would only hold at most one entry.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From kbarrett at openjdk.java.net  Thu Apr 28 15:18:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 28 Apr 2022 15:18:45 GMT
Subject: RFR: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException [v2]
In-Reply-To: <-T-TuLwA56yPK_O273MB-mYnV2xaVdm1Lmc75sediXc=.082b20a1-af1a-418f-be72-5dfd8de22b7c@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
 <Nyhm8B47gBf6p9LQZbDp9fnKNdWmhxL52FEdSaSLHK0=.637ee30f-3352-45e8-800f-756582d6332d@github.com>
 <-T-TuLwA56yPK_O273MB-mYnV2xaVdm1Lmc75sediXc=.082b20a1-af1a-418f-be72-5dfd8de22b7c@github.com>
Message-ID: <uxlIhePOX6Kq8RnfbYs_jC9hLiVFz32sWyEg7gIRUak=.94c08d64-cd11-42ba-a151-2df6edb93b45@github.com>

On Wed, 27 Apr 2022 15:32:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright, @bug list
>
> LGTM

Thanks for reviews @RogerRiggs and @mlchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From kbarrett at openjdk.java.net  Thu Apr 28 15:18:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 28 Apr 2022 15:18:45 GMT
Subject: Integrated: 8285690: CloneableReference subtest should not throw
 CloneNotSupportedException
In-Reply-To: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
References: <beBTlZK443OFSAJl3Wt6Kx2YcD4ZzkW4kVnYcAk1Gv8=.58714552-a2bb-4df4-ae8c-c4ec651f8fd9@github.com>
Message-ID: <O1wuvUt7BNlMJqkuVpCYDLFnTw1xdaGG_PGjlCmSo9M=.69ca8d48-e709-4187-a696-e4835c1e1218@github.com>

On Wed, 27 Apr 2022 09:24:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix to test/jdk/java/lang/ref/ReferenceClone.java.  It was
> passing if CloneableReference::clone were to throw CloneNotSupportedException.
> That should be a failure.
> 
> Testing:
> Locally (linux-x64) verified test still passes.  Temporarily changed
> CloneableReference::clone to throw and verified the expected failure gets
> reported, unlike before.

This pull request has now been integrated.

Changeset: 2d8d1402
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2d8d1402147f6ddd15732ce7098a8438317a2681
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8285690: CloneableReference subtest should not throw CloneNotSupportedException

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8418

From mgronlun at openjdk.java.net  Thu Apr 28 15:47:16 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 28 Apr 2022 15:47:16 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
Message-ID: <G8wfS1AG25WmMcN_nL_wj8xbmWgry1xKSoe7UZb0uA0=.f8988587-dbe5-412c-bd5b-1a838d6f114e@github.com>

On Thu, 28 Apr 2022 14:44:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168:
> 
>> 166:   assert(!tl->is_excluded(), "invariant");
>> 167:   if (virtual_thread) {
>> 168:     // TODO: blob cache for virtual threads
> 
> Fix this now or after integration?

Well spotted. It is an optimization and can happen after integration. I will create an enhancement for tracking; thank you.

> src/hotspot/share/jfr/metadata/metadata.xml line 121:
> 
>> 119:     thread="true" stackTrace="true">
>> 120:     <Field type="Thread" name="carrierThread" label="Carrier Thread" description="Thread enlisted as a carrier" />
>> 121:     <Field type="Class" name="contClass" label="Continuation class" description="Class of the continuation" />
> 
> "Continuation class" = >" Continuation Class"
> numFrames = frames
> numRefs = references
> "Number of interpreted frames" => "Interpreted Frames"
> "Number of references" => "References"
> "Stack size in bytes" => "Stack Size" contentType"bytes"

Will fix.

> src/hotspot/share/jfr/metadata/metadata.xml line 130:
> 
>> 128:     thread="true" stackTrace="true">
>> 129:     <Field type="Thread" name="carrierThread" label="Carrier Thread" description="Thread enlisted as a carrier" />
>> 130:     <Field type="Class" name="contClass" label="Continuation class" description="Class of the continuation" />
> 
> contClass => continuationClass
> "Continuation class" => "Continuation Class"
> "Class of the continuation" Remove (not needed)
> "Number of interpreted frames" => "Interpreted Frames"
> numFrames => frames
> "Number of references" => "References"
> numRefs => references
> "Stack size in bytes" => "Stack Size" contentType="bytes"

Will fix.

> src/hotspot/share/jfr/metadata/metadata.xml line 138:
> 
>> 136:   <Event name="ContinuationFreezeYoung" experimental="true" category="Java Virtual Machine" label="Continuation Freeze Young" thread="true" stackTrace="false" startTime="false">
>> 137:     <Field type="ulong" name="id" label="Continuation ID" />
>> 138:     <Field type="uint" name="size" label="Size" />
> 
> "Allocated new" => "Allocated New"

Will fix, thanks.

> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35:
> 
>> 33: 
>> 34: @Category({"Java Runtime"})
>> 35: @Label("Virtual thread end")
> 
> "Virtual thread end" => "Virtual Thread End"
> Remove description.

Will fix.

> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35:
> 
>> 33: 
>> 34: @Category({"Java Runtime"})
>> 35: @Label("Virtual thread pinned")
> 
> "Virtual thread pinned" => "Virtual Thread Pinned"
> Remove description

Will fix.

> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35:
> 
>> 33: 
>> 34: @Category({"Java Runtime"})
>> 35: @Label("Virtual thread start")
> 
> "virtual thread start" => "Virtual Thread Start"
> Remove description

Will fix, thanks.

> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35:
> 
>> 33: 
>> 34: @Category({"Java Runtime"})
>> 35: @Label("Virtual thread submit task failed")
> 
> The label is a bit a long, would "Virtual Thread Submit Failed" work?

It works. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu Apr 28 15:47:17 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 15:47:17 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <G8wfS1AG25WmMcN_nL_wj8xbmWgry1xKSoe7UZb0uA0=.f8988587-dbe5-412c-bd5b-1a838d6f114e@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <i46-lWS4_uujrRqxca_vB3O_06YLJCYmi64pT0W-xAk=.7fca7930-b3e9-4cf3-b98f-62ece3878236@github.com>
 <G8wfS1AG25WmMcN_nL_wj8xbmWgry1xKSoe7UZb0uA0=.f8988587-dbe5-412c-bd5b-1a838d6f114e@github.com>
Message-ID: <81ywC27bKQgyP3gndP6y02PPiOfHrTAlU-YA46fZvZ0=.9f0253da-a679-43b9-b445-a598cc193518@github.com>

On Thu, 28 Apr 2022 15:10:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35:
>> 
>>> 33: 
>>> 34: @Category({"Java Runtime"})
>>> 35: @Label("Virtual thread submit task failed")
>> 
>> The label is a bit a long, would "Virtual Thread Submit Failed" work?
>
> It works. Thanks.

Yes, this is okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From andrew at openjdk.java.net  Thu Apr 28 15:48:42 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 15:48:42 GMT
Subject: RFR: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
References: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
Message-ID: <2rA1uuiuqH3n_U_AOUTQUvqaJZulFEGOGbciN-roli8=.95662066-7855-4730-b4af-6d5cf29de123@github.com>

On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix.
> 
> An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be [accepted](https://github.com/openjdk/jdk/blob/9d9f4e502f6ddc3116ed9b80f7168a1edfce839e/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L59).

Changes look right to me. The test seems to have been based on the situation pre-patch, where setting the property to `true` worked around the bug. With the patch, only the `false` case actually exhibits the bug.

test/jdk/java/io/FileOutputStream/OpenNUL.java line 31:

> 29:  * @run main/othervm OpenNUL
> 30:  * @run main/othervm -Djdk.io.File.enableADS OpenNUL
> 31:  * @run main/othervm -Djdk.io.File.enableADS=FalsE OpenNUL

Is there a reason for the mixed case? Just to check equalsIgnoreCase is being used?

-------------

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8379

From bpb at openjdk.java.net  Thu Apr 28 16:11:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 28 Apr 2022 16:11:35 GMT
Subject: RFR: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
References: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
Message-ID: <DGXyB48wQdkqbUvx42dC_TD9rRTsqDECE5jBUqkgiIY=.0fb9c891-ac91-49b5-b660-38a138ac9f7f@github.com>

On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix.
> 
> An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be [accepted](https://github.com/openjdk/jdk/blob/9d9f4e502f6ddc3116ed9b80f7168a1edfce839e/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L59).

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8379

From darcy at openjdk.java.net  Thu Apr 28 16:47:38 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:47:38 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
 <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
Message-ID: <APLsOL7a9pdpPrF0yqc21hFBBblzmz4ufzfe0fkIPHE=.284c73bd-5701-4d0a-8dc2-f8906298db79@github.com>

On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55:
> 
>> 53:  * against the <i>original path</i> of the directory (irrespective of if the
>> 54:  * directory is moved since it was opened).
>> 55:  * @param <T> the type of path
> 
> It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead?

Will change in the next push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Thu Apr 28 16:58:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:58:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to more review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/db4919a9..aaa8f828

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Thu Apr 28 16:58:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 16:58:40 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v3]
In-Reply-To: <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <EKgw2cuyScL05pjYGZSXIoPhtm_UOy1JVl-YQ5Eh1W8=.96f0bf77-d828-4ad2-8976-822c9d4668e2@github.com>
 <Ib04OwgWvasO3awv0GtN9pNgsFFhA6ZyEhJTfrO5KKY=.88362bf9-a83f-448a-9cfc-53743a6af63f@github.com>
Message-ID: <vABdYW2fqKSy9FCs9pJIoHYgJdFs7TWXSKeO_pk6bBE=.224ba49c-2848-45f1-a3c9-561555f4880d@github.com>

On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/WatchEvent.java line 51:
> 
>> 49:     /**
>> 50:      * An event kind, for the purposes of identification.
>> 51:      * @param <T> the type of the context value
> 
> This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind.

Okay -- I'll for the T type parameter of the Kind interface I'll reuse the wording of the T type parameter of the enclosing WatchEvent interface. (The type variable on Kind could be renamed to show that the two type parameters are distinct.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From alanb at openjdk.java.net  Thu Apr 28 17:30:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 28 Apr 2022 17:30:50 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
Message-ID: <RWkPlAb3Lvs0UWXjBkya0RmLKXZunv02SSxQ1-PdeQk=.9aa846c3-bed9-4e8d-bb8d-ba91180bba58@github.com>

On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Thu Apr 28 17:36:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 17:36:32 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Respond to review feedback.
 - Respond to CSR feedback.
 - Merge branch 'master' into JDK-8285497
 - Update comment in template.
 - JDK-8285497: Add system property for Java SE specification maintenance version

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/4ea4708b..101ad872

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=00-01

  Stats: 670 lines in 38 files changed: 614 ins; 8 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Thu Apr 28 17:36:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 17:36:33 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version
In-Reply-To: <kSYZs8lir1GcbhdGw6FfH3evXskguzH9aeKr5wD4_6g=.70ef40fe-e67e-4231-8a5f-05d2c7a5b0b9@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <kSYZs8lir1GcbhdGw6FfH3evXskguzH9aeKr5wD4_6g=.70ef40fe-e67e-4231-8a5f-05d2c7a5b0b9@github.com>
Message-ID: <SLFTGMWw5m3mwCHWq1L_OBjX3P5CkPNCl6MokBhuxAc=.0e742ad1-1d32-40bf-96f9-0f9cfe25afb6@github.com>

On Thu, 28 Apr 2022 12:31:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Should this be added to the default permissions in the `conf/security/java.policy` file along with other similar properties?

Seems reasonable; good catch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From mchung at openjdk.java.net  Thu Apr 28 17:49:48 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 28 Apr 2022 17:49:48 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v4]
In-Reply-To: <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <HMJ5qGsBGbV8az1D1GJFSu_fyBfjfzFGBZm3wgQLcQM=.aebea4cc-686f-4a39-88b8-3f90d64ebf61@github.com>
Message-ID: <LA-4M_w3p_hqJLf6j0DBR2uUpK0rcPr7xE18GQP4Tao=.ed7751d6-0f7e-44a8-b9c0-ced7724b4cd5@github.com>

On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From sviswanathan at openjdk.java.net  Thu Apr 28 17:57:46 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 28 Apr 2022 17:57:46 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
Message-ID: <IsEWSJZbkxGAagNIK5nuCU6CWsOP3n-zh0wOgdI5kFE=.480ea82c-cd6b-4a33-8659-adbe1ad48e3e@github.com>

On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename the "usePred" to "offsetInRange"

@PaulSandoz Could you please take a look at the Java changes when you find time. This PR from @XiaohongGong is a very good step towards long standing Vector API  wish list for better tail loop handling.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From darcy at openjdk.java.net  Thu Apr 28 18:05:39 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 18:05:39 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Update copyright years.
 - Merge branch 'master' into JDK-8285676
 - Respond to more review feedback.
 - Respond to more review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8285676
 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8410/files
  - new: https://git.openjdk.java.net/jdk/pull/8410/files/aaa8f828..cb1fe1c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03-04

  Stats: 687 lines in 59 files changed: 610 ins; 8 del; 69 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8410.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410

PR: https://git.openjdk.java.net/jdk/pull/8410

From darcy at openjdk.java.net  Thu Apr 28 18:05:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 18:05:40 GMT
Subject: Integrated: JDK-8285676: Add missing @param tags for type parameters
 on classes and interfaces
In-Reply-To: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
Message-ID: <Xa8RvIRtpco75Ib21j-Mcvs5Pvj3iyog7CA9y0YzJ3o=.31542016-78a7-461c-9c07-1c8a45128d19@github.com>

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

This pull request has now been integrated.

Changeset: bba456a8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bba456a8dbf9027e4b015567c17a79fc7441aa08
Stats:     102 lines in 40 files changed: 76 ins; 0 del; 26 mod

8285676: Add missing @param tags for type parameters on classes and interfaces

Reviewed-by: wetmore, smarks, dfuchs, prr, alanb, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From mcimadamore at openjdk.java.net  Thu Apr 28 18:10:57 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 28 Apr 2022 18:10:57 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Downcall and upcall tests use wrong layout which is missing some trailing padding

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/5866bbb5..945317ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=32-33

  Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From aturbanov at openjdk.java.net  Thu Apr 28 18:27:59 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 28 Apr 2022 18:27:59 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
Message-ID: <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>

On Thu, 28 Apr 2022 18:05:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing.
>> 
>> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code.
>> 
>> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496).
>> 
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into JDK-8285676
>  - Respond to more review feedback.
>  - Respond to more review feedback.
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8285676
>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:

> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
> 47:  * whether some object is the referent of a phantom reference.
> 48:  * @param<T> the type of the referent

Shouldn't there be a space after `@param` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From mr at openjdk.java.net  Thu Apr 28 18:56:56 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 28 Apr 2022 18:56:56 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
Message-ID: <6rdkFRa6k3nWZhZPtNs1puMx4syIswCbboUeYs-F-TQ=.cf2497c8-0d48-4bef-bc3b-e89f50c3c57f@github.com>

On Thu, 28 Apr 2022 17:36:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update comment in template.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

Also, don't forget to update the CSR with the new specification text, for the record.
Otherwise, looks good!

src/java.base/share/classes/java/lang/VersionProps.java.template line 113:

> 111:         props.put("java.specification.version", VERSION_SPECIFICATION);
> 112: 
> 113:         // Uncomment next props.put call after the first maintenance review for a

s/review/release/

-------------

Changes requested by mr (Lead).

PR: https://git.openjdk.java.net/jdk/pull/8437

From mchung at openjdk.java.net  Thu Apr 28 19:08:52 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 28 Apr 2022 19:08:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
Message-ID: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>

On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Update copyright years.
>>  - Merge branch 'master' into JDK-8285676
>>  - Respond to more review feedback.
>>  - Respond to more review feedback.
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8285676
>>  - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
>
> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
> 
>> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
>> 47:  * whether some object is the referent of a phantom reference.
>> 48:  * @param<T> the type of the referent
> 
> Shouldn't there be a space after `@param` ?

Good catch.  Sorry I missed it. This occurs in all `java/lang/ref` files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From egahlin at openjdk.java.net  Thu Apr 28 19:34:10 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 28 Apr 2022 19:34:10 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <yGjmQWAThfsKhrk4NXF7JGvETAa-SjSCmrRFtJWq8zI=.50af461c-cf4e-4acb-978b-4d0cee9d1bb0@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mullan at openjdk.java.net  Thu Apr 28 19:40:45 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Apr 2022 19:40:45 GMT
Subject: RFR: JDK-8285764: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
Message-ID: <RIc5Ta0bMaAUcC7_5APkqOf28o_1PtwfLanrCcPWndQ=.32ae12e3-dc5e-4516-a21a-f5325dba33bf@github.com>

On Thu, 28 Apr 2022 17:36:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update comment in template.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

src/java.base/share/conf/security/java.policy line 34:

> 32:                    "java.specification.version", "read";
> 33:     permission java.util.PropertyPermission
> 34:                    "java.specification.maintenance.version", "read";

For consistency, you should probably also add a hard-coded permission to the `sun.security.provider.PolicyFile.initStaticPolicy()` method which is used as a fallback if there is a problem parsing the `java.policy` file. I doubt this will cause any issues as I don't suspect many/any applications will suddenly start reading this property and running with an SM but again it is mainly for consistency as all the other default permissions in this file are also granted in that method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From psandoz at openjdk.java.net  Thu Apr 28 19:51:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 28 Apr 2022 19:51:44 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
Message-ID: <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>

On Wed, 27 Apr 2022 09:06:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - Merge branch 'master' into JDK-8284992
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - 8284992: Fix misleading Vector API doc for LSHR operator

It should be possible for you finalize now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From bpb at openjdk.java.net  Thu Apr 28 20:02:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 28 Apr 2022 20:02:36 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6478546: Decrease malloc'ed buffer maximum size to 64 kB

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8235/files
  - new: https://git.openjdk.java.net/jdk/pull/8235/files/8bb1e14f..40d46f8f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.java.net/jdk/pull/8235

From darcy at openjdk.java.net  Thu Apr 28 20:15:36 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:15:36 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v3]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <pmy7rLAzm2nOeFCtHtt_Os8nmUTZxZXmWQFMKDRegNg=.92cca727-0b9a-488e-ba42-366b1c4db0ae@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/101ad872..fc7730d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=01-02

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From uschindler at openjdk.java.net  Thu Apr 28 20:16:46 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Thu, 28 Apr 2022 20:16:46 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>
Message-ID: <oUK20vbDwxivpYv2Wbf45jedC5g3BLnVAmDgcvSRAmY=.1026336c-b852-4b7e-a281-46957ccb7401@github.com>

On Thu, 28 Apr 2022 20:02:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6478546: Decrease malloc'ed buffer maximum size to 64 kB

By the way: FileOutputStream has exactly the same problem with `write(byte[])`. I see no test for it, but I assume this is now also fixed. That's a longstanding issue in Lucene (this is why we use a ChunkedOutputStream when writing files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From darcy at openjdk.java.net  Thu Apr 28 20:10:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:10:42 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <RIc5Ta0bMaAUcC7_5APkqOf28o_1PtwfLanrCcPWndQ=.32ae12e3-dc5e-4516-a21a-f5325dba33bf@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
 <RIc5Ta0bMaAUcC7_5APkqOf28o_1PtwfLanrCcPWndQ=.32ae12e3-dc5e-4516-a21a-f5325dba33bf@github.com>
Message-ID: <3c2fphKBECUnvUECpw_7yMdtlA85xjH_4kqpb1aN_q0=.a8a81eeb-62e2-47ee-b74e-703bb73c81e7@github.com>

On Thu, 28 Apr 2022 19:37:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Respond to review feedback.
>>  - Respond to CSR feedback.
>>  - Merge branch 'master' into JDK-8285497
>>  - Update comment in template.
>>  - JDK-8285497: Add system property for Java SE specification maintenance version
>
> src/java.base/share/conf/security/java.policy line 34:
> 
>> 32:                    "java.specification.version", "read";
>> 33:     permission java.util.PropertyPermission
>> 34:                    "java.specification.maintenance.version", "read";
> 
> For consistency, you should probably also add a hard-coded permission to the `sun.security.provider.PolicyFile.initStaticPolicy()` method which is used as a fallback if there is a problem parsing the `java.policy` file. I doubt this will cause any issues as I don't suspect many/any applications will suddenly start reading this property and running with an SM but again it is mainly for consistency as all the other default permissions in this file are also granted in that method.

Will do; thanks. Just to double-check, under the current proposal, this property will be undefined most of the time. I assume it is fine for the permissions to grant the ability to read a property that is not actually there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Thu Apr 28 20:18:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:18:46 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version
In-Reply-To: <WWsZi9yPGIMWM7QGf2EjJn18ks5_fg3SUdQz5NBArTs=.ed8436ea-7a63-441a-896b-7c3468cd50ed@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <WWsZi9yPGIMWM7QGf2EjJn18ks5_fg3SUdQz5NBArTs=.ed8436ea-7a63-441a-896b-7c3468cd50ed@github.com>
Message-ID: <zdukdgBLcufFOKekzlhAlpY5xh2Kb2yJCIrz7Lm7Veo=.e873f7c7-5da8-4a74-9a5e-09b4494ec61b@github.com>

On Thu, 28 Apr 2022 10:24:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Joe, should the property description have a note stating what kind of a value this property holds, if at all present? Would it be free form text or an integer value?



> 

There is some discussion about the sequence of values in comments on the JBS issue. I think it would be reasonable to have the sequence:

undefined -> 1 -> 2 -> 3 ...

where 1, 2, 3 are strings. I'll update the text to be more explicit about the eventual sequence once the discussion is concluded; thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Thu Apr 28 20:18:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:18:46 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <6rdkFRa6k3nWZhZPtNs1puMx4syIswCbboUeYs-F-TQ=.cf2497c8-0d48-4bef-bc3b-e89f50c3c57f@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
 <6rdkFRa6k3nWZhZPtNs1puMx4syIswCbboUeYs-F-TQ=.cf2497c8-0d48-4bef-bc3b-e89f50c3c57f@github.com>
Message-ID: <kUJ_F6yI9OQ2Rq0PY51sZNAdx0EcaGNfXq7ufkASfxk=.30c012dc-d0fc-4874-a55c-e46ca11c7282@github.com>

On Thu, 28 Apr 2022 18:53:11 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Also, don't forget to update the CSR with the new specification text, for the record. Otherwise, looks good!

Will do; I'll update the CSR to reflect that change as well as to be more explicit about the sequence of values, once that is determined.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From mr at openjdk.java.net  Thu Apr 28 20:27:43 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 28 Apr 2022 20:27:43 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v3]
In-Reply-To: <pmy7rLAzm2nOeFCtHtt_Os8nmUTZxZXmWQFMKDRegNg=.92cca727-0b9a-488e-ba42-366b1c4db0ae@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <pmy7rLAzm2nOeFCtHtt_Os8nmUTZxZXmWQFMKDRegNg=.92cca727-0b9a-488e-ba42-366b1c4db0ae@github.com>
Message-ID: <qAg-oH43fb5qWHIviyoWkWTLJ99XRhLSxkkgmUxtcmc=.83daaa98-af36-4e82-94a4-dba000e7669d@github.com>

On Thu, 28 Apr 2022 20:15:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by mr (Lead).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From mullan at openjdk.java.net  Thu Apr 28 20:27:44 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Apr 2022 20:27:44 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <3c2fphKBECUnvUECpw_7yMdtlA85xjH_4kqpb1aN_q0=.a8a81eeb-62e2-47ee-b74e-703bb73c81e7@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
 <RIc5Ta0bMaAUcC7_5APkqOf28o_1PtwfLanrCcPWndQ=.32ae12e3-dc5e-4516-a21a-f5325dba33bf@github.com>
 <3c2fphKBECUnvUECpw_7yMdtlA85xjH_4kqpb1aN_q0=.a8a81eeb-62e2-47ee-b74e-703bb73c81e7@github.com>
Message-ID: <WZi4v1i3KUmjvPEq_13Vh1rwfu6xjRsay_7ZvEMSVi4=.65198fef-d120-4b0f-a9ea-44fafd28ed42@github.com>

On Thu, 28 Apr 2022 20:07:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.policy line 34:
>> 
>>> 32:                    "java.specification.version", "read";
>>> 33:     permission java.util.PropertyPermission
>>> 34:                    "java.specification.maintenance.version", "read";
>> 
>> For consistency, you should probably also add a hard-coded permission to the `sun.security.provider.PolicyFile.initStaticPolicy()` method which is used as a fallback if there is a problem parsing the `java.policy` file. I doubt this will cause any issues as I don't suspect many/any applications will suddenly start reading this property and running with an SM but again it is mainly for consistency as all the other default permissions in this file are also granted in that method.
>
> Will do; thanks. Just to double-check, under the current proposal, this property will be undefined most of the time. I assume it is fine for the permissions to grant the ability to read a property that is not actually there.

Yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From bpb at openjdk.java.net  Thu Apr 28 20:33:41 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 28 Apr 2022 20:33:41 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <oUK20vbDwxivpYv2Wbf45jedC5g3BLnVAmDgcvSRAmY=.1026336c-b852-4b7e-a281-46957ccb7401@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>
 <oUK20vbDwxivpYv2Wbf45jedC5g3BLnVAmDgcvSRAmY=.1026336c-b852-4b7e-a281-46957ccb7401@github.com>
Message-ID: <F6vDmrbTxqSy_Y26eLWrVXer4AFEDCHMgiMyohg_1QY=.8a1e6fd0-1021-493c-b18e-60baa7f0801e@github.com>

On Thu, 28 Apr 2022 20:13:48 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> By the way: FileOutputStream has exactly the same problem with `write(byte[])`. I see no test for it, but I assume this is now also fixed. That's a longstanding issue in Lucene (this is why we use a ChunkedOutputStream when writing files.

Yes, `write(byte[])` is also fixed: [io_util.c#L164](https://github.com/bplb/jdk/blob/40d46f8f4463dbd7dbe10651910826e90ca4dbdd/src/java.base/share/native/libjava/io_util.c#L164).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From darcy at openjdk.java.net  Thu Apr 28 20:54:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:54:29 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v4]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback; make sequence of values explicit.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/fc7730d6..461407aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=02-03

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Thu Apr 28 20:56:20 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 28 Apr 2022 20:56:20 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v2]
In-Reply-To: <kUJ_F6yI9OQ2Rq0PY51sZNAdx0EcaGNfXq7ufkASfxk=.30c012dc-d0fc-4874-a55c-e46ca11c7282@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ITJ7VRWdnGZiJucVkyt2ifUlyEXck4g8w3auj0qorNM=.32340ef7-bf83-4d95-9a37-4f88a61a199a@github.com>
 <6rdkFRa6k3nWZhZPtNs1puMx4syIswCbboUeYs-F-TQ=.cf2497c8-0d48-4bef-bc3b-e89f50c3c57f@github.com>
 <kUJ_F6yI9OQ2Rq0PY51sZNAdx0EcaGNfXq7ufkASfxk=.30c012dc-d0fc-4874-a55c-e46ca11c7282@github.com>
Message-ID: <Du3902TgYHK83gaL-FMOlqWTpEwi7D36n3nk2okVamI=.bc8b3a29-9e14-48d0-811e-bd8bd3de8067@github.com>

On Thu, 28 Apr 2022 20:15:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Also, don't forget to update the CSR with the new specification text, for the record. Otherwise, looks good!
> 
> Will do; I'll update the CSR to reflect that change as well as to be more explicit about the sequence of values, once that is determined.

CSR now updated accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From mullan at openjdk.java.net  Thu Apr 28 21:25:53 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 28 Apr 2022 21:25:53 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v4]
In-Reply-To: <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>
Message-ID: <bZdS8dxgcGhpRXjHzPHaEhbnH8C4MUvwI1KLzoYNtXM=.192fc0d2-dc26-49b4-8e9f-7921a80d17ce@github.com>

On Thu, 28 Apr 2022 20:54:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; make sequence of values explicit.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From serb at openjdk.java.net  Thu Apr 28 22:31:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 22:31:40 GMT
Subject: RFR: 8285523: Improve test java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <2rA1uuiuqH3n_U_AOUTQUvqaJZulFEGOGbciN-roli8=.95662066-7855-4730-b4af-6d5cf29de123@github.com>
References: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
 <2rA1uuiuqH3n_U_AOUTQUvqaJZulFEGOGbciN-roli8=.95662066-7855-4730-b4af-6d5cf29de123@github.com>
Message-ID: <SglA8fcNR9adOFR3sKLocPq8OqIeJLsJGzg76Ej6SxY=.d4908aca-2f5e-4fc6-8c09-d8ff459aba21@github.com>

On Thu, 28 Apr 2022 15:43:09 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix.
>> 
>> An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be [accepted](https://github.com/openjdk/jdk/blob/9d9f4e502f6ddc3116ed9b80f7168a1edfce839e/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L59).
>
> test/jdk/java/io/FileOutputStream/OpenNUL.java line 31:
> 
>> 29:  * @run main/othervm OpenNUL
>> 30:  * @run main/othervm -Djdk.io.File.enableADS OpenNUL
>> 31:  * @run main/othervm -Djdk.io.File.enableADS=FalsE OpenNUL
> 
> Is there a reason for the mixed case? Just to check equalsIgnoreCase is being used?

Yes only for equalsIgnoreCase

-------------

PR: https://git.openjdk.java.net/jdk/pull/8379

From lfarkas at lfarkas.org  Thu Apr 28 22:40:36 2022
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Fri, 29 Apr 2022 00:40:36 +0200
Subject: java.net.http.HttpClient do NOT support Digest authentication while
 HttpURLConnection do
Message-ID: <CAMMFzKa583KmWNepJHmjSS_fQ0dvrq2q5qBXffG28ZtvMbm3-A@mail.gmail.com>

Hi,

Even though many tutorial said that the new java.net.http.HttpClient
support Digest authentication it's not true:
https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L278
But at the same time HttpURLConnection support it through the simple:
-------------------------------
Authenticator.setDefault(new Authenticator() {
    @Override
    protected PasswordAuthentication getPasswordAuthentication() {

        return new PasswordAuthentication (
            "username",
            "password".toCharArray()
        );
    }
});
-------------------------------
Is it a bug or you don't even plan to support it with HttpClient?
Regards.

-- 
  Levente                               "Si vis pacem para bellum!"

From jiefu at openjdk.java.net  Thu Apr 28 22:54:41 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 28 Apr 2022 22:54:41 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
 <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
Message-ID: <EPMgax2D-w4nMObv2K_YPdhFnk2GEhgKq689yFlEblM=.8aecd536-0406-4106-8d1f-5938e66c7a07@github.com>

On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> It should be possible for you finalize now.

Done.
Thanks @PaulSandoz .

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From mr at openjdk.java.net  Thu Apr 28 23:59:42 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 28 Apr 2022 23:59:42 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v4]
In-Reply-To: <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>
Message-ID: <wE90Kfmm3Id4MYc4YzxhmZN3C_QhjqlojBp1I41__X4=.f34e1d86-6988-481e-ab03-62ec7ed4110a@github.com>

On Thu, 28 Apr 2022 20:54:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; make sequence of values explicit.

src/java.base/share/classes/java/lang/System.java line 740:

> 738:      *         <a href="https://jcp.org/en/procedures/jcp2#3.6.4">maintenance
> 739:      *         release</a> <em>(optional)</em>.
> 740:      *         After a first maintenance release, this property will

Separate independent clauses with a semicolon: `After a first maintenance release this property will have the value {@code "1"}; after a second maintenance release it will have the value {@code "2"}, and so on.`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From smarks at openjdk.java.net  Fri Apr 29 00:01:44 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Apr 2022 00:01:44 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <b3JzD_0udODqToaoGgHX3u7lriMBvzMxeYKNEelJMOo=.1745f0fb-a737-4ca6-ad22-751893e3aa32@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <b3JzD_0udODqToaoGgHX3u7lriMBvzMxeYKNEelJMOo=.1745f0fb-a737-4ca6-ad22-751893e3aa32@github.com>
Message-ID: <RPGlMjzAK5d8ps4SM1MDmwvrGcPVNNOByKKmUc7E4NI=.0bb4f4c6-955f-4c21-bc2d-3ecb8e0d325b@github.com>

On Thu, 28 Apr 2022 13:22:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 337:
> 
>> 335:     public void testPutOverwrite() {
>> 336:         Box newVal = new Box(v1a);
>> 337:         map.put(k1a, newVal);
> 
> Should we capture the return value and assert that it's not null and is identity equal to `v1a`?
> 
> Perhaps, similarly at a few other places where we do put and putIfAbsent?

Yes, good point, I'll add checks of the return values in the appropriate places. There are several, including `remove`, `computeX`, `put`, etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Fri Apr 29 00:09:46 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Apr 2022 00:09:46 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <QpNLntXsiKovND5NI-RBkP6UdLyiql8aWHrlGxBBfsw=.6c82b934-7b90-4fba-a88e-38e7d7ba42f1@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <QpNLntXsiKovND5NI-RBkP6UdLyiql8aWHrlGxBBfsw=.6c82b934-7b90-4fba-a88e-38e7d7ba42f1@github.com>
Message-ID: <29N41gS3ujxWmslgRuBHT4BicApz-2wILSntZWXAyqM=.93f1869b-1436-4057-a7e8-30b4049ed28a@github.com>

On Thu, 28 Apr 2022 13:17:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 257:
> 
>> 255:         checkEntries(map.entrySet(), entry(k1b, v1b),
>> 256:                                      entry(k2, v2));
>> 257:     }
> 
> Would an additional check `assertFalse(map.equals(map2));` be useful here (and other similar tests where we do "remove").

I don't know if you noticed that previous versions checked the map's contents with `map.equals(map2)` and either asserted true or false depending on the situation. I pulled most of those out when I added `checkEntries`. The reason is that `checkEntries` and `checkElements` are supposed to check the exact contents of the map or the collection, and they fail if there is a missing, different, or extra entry or element. If that's true we don't need to test `map.equals`. I don't think it calling `map.equals` adds any value or does any checking that the `checkX` methods don't already do.

Of course this relies on `checkEntries` and `checkElements` to do their jobs properly, so we should make sure they do!

And also we need to test that the `equals` method is doing its job as well. There are a couple tests for it already, and they test at least the basic cases. But it's possible I might have missed something.

In any case, if we believe the `checkX` methods are sufficient, and if we believe that the tests for `equals` are also sufficient, then I don't think we need to add assertions about `equals` in any tests other than for `equals` itself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From gli at openjdk.java.net  Fri Apr 29 00:46:18 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 29 Apr 2022 00:46:18 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
Message-ID: <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>

On Thu, 28 Apr 2022 18:10:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Downcall and upcall tests use wrong layout which is missing some trailing padding

Remind: please use the command `/jep JEP-424` [1] to mark this PR.

[1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From gli at openjdk.java.net  Fri Apr 29 00:48:08 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 29 Apr 2022 00:48:08 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <W16813zLn8eHXaTpC5b_GjcfHag_AciOExLu-pRbQ88=.6a94aa28-63e4-4d42-b9e2-5eaaf294eee6@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Remind: please use the command `/jep JEP-425` [1] to mark this PR.

[1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Fri Apr 29 01:20:17 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 01:20:17 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Change punctuation from review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/461407aa..2048aaac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Fri Apr 29 01:20:18 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 01:20:18 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v4]
In-Reply-To: <wE90Kfmm3Id4MYc4YzxhmZN3C_QhjqlojBp1I41__X4=.f34e1d86-6988-481e-ab03-62ec7ed4110a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <ID7N46Z6IXRMdsQV3sy-gc3TEFgjEq6g6meiPMU7w2E=.1c926240-4f04-46c5-913b-7b8aadd2b664@github.com>
 <wE90Kfmm3Id4MYc4YzxhmZN3C_QhjqlojBp1I41__X4=.f34e1d86-6988-481e-ab03-62ec7ed4110a@github.com>
Message-ID: <LUpdrFAJMnMnvxEeeMDEeBcPR8Yh_O3Dp8tiYDL8RtI=.56a5822f-b495-4e95-a93a-5d01b57ea9b9@github.com>

On Thu, 28 Apr 2022 23:56:27 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback; make sequence of values explicit.
>
> src/java.base/share/classes/java/lang/System.java line 740:
> 
>> 738:      *         <a href="https://jcp.org/en/procedures/jcp2#3.6.4">maintenance
>> 739:      *         release</a> <em>(optional)</em>.
>> 740:      *         After a first maintenance release, this property will
> 
> Separate independent clauses with a semicolon: `After a first maintenance release this property will have the value {@code "1"}; after a second maintenance release it will have the value {@code "2"}, and so on.`

PR and CSR updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From jpai at openjdk.java.net  Fri Apr 29 01:42:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 29 Apr 2022 01:42:41 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
Message-ID: <wnY2yGPfoBrGJm0VXJ1EM9PC1mjzRldSyizFGJBUH4c=.adf566ae-5926-4091-b995-e2a5d6c2c922@github.com>

On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change punctuation from review feedback.

Thank you for the updates, Joe. Looks good to me.

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8437

From jpai at openjdk.java.net  Fri Apr 29 01:44:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 29 Apr 2022 01:44:46 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <29N41gS3ujxWmslgRuBHT4BicApz-2wILSntZWXAyqM=.93f1869b-1436-4057-a7e8-30b4049ed28a@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <QpNLntXsiKovND5NI-RBkP6UdLyiql8aWHrlGxBBfsw=.6c82b934-7b90-4fba-a88e-38e7d7ba42f1@github.com>
 <29N41gS3ujxWmslgRuBHT4BicApz-2wILSntZWXAyqM=.93f1869b-1436-4057-a7e8-30b4049ed28a@github.com>
Message-ID: <QyWy2UVHPD5I5lsZqEZdtlWoJasHnvuLtZWx6DDYQLI=.c8ac05fb-08cd-47fb-ae70-f26a9f2aa40c@github.com>

On Fri, 29 Apr 2022 00:06:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/IdentityHashMap/Basic.java line 257:
>> 
>>> 255:         checkEntries(map.entrySet(), entry(k1b, v1b),
>>> 256:                                      entry(k2, v2));
>>> 257:     }
>> 
>> Would an additional check `assertFalse(map.equals(map2));` be useful here (and other similar tests where we do "remove").
>
> I don't know if you noticed that previous versions checked the map's contents with `map.equals(map2)` and either asserted true or false depending on the situation. I pulled most of those out when I added `checkEntries`. The reason is that `checkEntries` and `checkElements` are supposed to check the exact contents of the map or the collection, and they fail if there is a missing, different, or extra entry or element. If that's true we don't need to test `map.equals`. I don't think it calling `map.equals` adds any value or does any checking that the `checkX` methods don't already do.
> 
> Of course this relies on `checkEntries` and `checkElements` to do their jobs properly, so we should make sure they do!
> 
> And also we need to test that the `equals` method is doing its job as well. There are a couple tests for it already, and they test at least the basic cases. But it's possible I might have missed something.
> 
> In any case, if we believe the `checkX` methods are sufficient, and if we believe that the tests for `equals` are also sufficient, then I don't think we need to add assertions about `equals` in any tests other than for `equals` itself.

Hello Stuart,

Thank you for the explanation.

> In any case, if we believe the checkX methods are sufficient, and if we believe that the tests for equals are also sufficient, then I don't think we need to add assertions about equals in any tests other than for equals itself.

That makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From david.holmes at oracle.com  Fri Apr 29 01:49:08 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Apr 2022 11:49:08 +1000
Subject: Improve `finally` block exception handling
In-Reply-To: <4c1e4a7f65ec4051b40215c826b7cd3f@vodafonemail.de>
References: <4c1e4a7f65ec4051b40215c826b7cd3f@vodafonemail.de>
Message-ID: <d45f1e62-4081-b591-07a3-0754bf1de6d4@oracle.com>

On 21/04/2022 7:30 am, 
some-java-user-99206970363698485155 at vodafonemail.de wrote:
> Thanks a lot for your feedback! My original message was a bit vague in parts, sorry for that.
> 
> The proposal consists of the following:
> 1. Forbidding usage of `break`, `continue`, `yield` and `return` in `finally` blocks
> 2. Adding exceptions as suppressed exceptions:
>     If exception E1 led to execution of the `finally` block and the block is left due to
>     another exception E2, then either E1 or E2 should be thrown with the other one added
>     as suppressed exception. For consistency with try-with-resources and because E1 is
>     most likely more relevant ideally E1 would be thrown and E2 should be suppressed. But
>     if you think the impact on backward compatibility would be too large, then E2 should
>     be thrown (the current behavior), but E1 should at least be added as suppressed exception.
> 
> The following replies to your comments hopefully make the rationale for these proposed
> changes clearer.
> 
> 
>> The behaviour of try/catch/finally is not "obvious at all", you have to read what it means
>> and when you do that you clearly see what happens regarding exceptions.
> 
> For try-catch you see that the code catches some specific exception and then handles it in a
> certain way, whether that is by rethrowing, logging or itentionally ignoring it.
> The issue with `finally` is that in its current form, exceptions which occurred in the `try`
> block might just silently disappear. Consider this simple example:
> ```
> try {
>      throw new RuntimeException();
> } finally {
>      return true;
> }
> ```
> Here it is not clear at all, unless you have read the JLS in detail, that the thrown exception
> just vanishes. There is no explicit indication that the `finally` has any effect on the
> thrown exception. Of course this is a contrived example, but consider the same situation where
> the `try` block calls a method which might throw an exception (or the general case that a
> VirtualMachineError occurs), and that the `return` (or any of the other affected statements)
> is not the only statement in the `finally` block.
> 
> Similar confusing code can be written where the `try` or `catch` block returns a value
> (or continues or breaks loop iteration), but the `finally` block overwrites that action:
> ```
> try {
>      return 1;
> } finally {
>      return 2;
> }
> ```
> Again, contrived, but consider the same code with additional statements in the `try` and
> `finally` blocks. This breaks fundamental assumptions one has about the behavior of the
> statements, such as `return`.

I still maintain this is simply a matter of user education. You have no 
business using a finally block if you have never bothered to even learn 
how it works. Sorry no sympathy from me on that one.

>>> Are there any plans to forbid usage of `break`, `continue`, `yield` and `return` in
>>> `finally` blocks?
>>
>> Why would we do that? What would that gain?
> 
> It would prevent code such as the one shown above, where code, most likely unintentionally,
> discards exceptions. Now also consider that inside the `try` block a VirtualMachineError
> (or a subclass of it) may occur which you really should not catch. Yet the code in the
> `finally` block silently discards it without you ever noticing the error, before it occurs
> later in another part of the application again and has possibly already corrupted the state
> of the application.

Again this is primarily user education. And there are times when you 
definitely do want to use those statements and you would have to jump 
through hoops to get the same effect if they were banned.

But in terms of "are there any plans ..." the answer is a clear no as 
the compatibility issues would make this a non-starter.

> 
>>> Similarly for `throw` and any implicitly thrown exceptions, is there a plan to at least
>>> add the original exception as suppressed one to the newly thrown?
>>
>> That suggestion is not completely without merit, but nor is it a "slam-dunk" obvious thing to do. The semantic implications of the exceptions matter, and semantics come from the programmers intent. There's no reasonable way to automagically determine that when an exception is created that another exception (that led to the finally block) should be inserted as a "suppressed exception". That would actually be completely wrong to do in many circumstances you would instead need to act when the exception would terminate the finally block and then add the original exception as the "suppressed" exception.
> 
> To clarify my suggestion: If a `finally` block is entered due to an exception E1, and is
> exited due to an exception E2 (regardless of whether explicitly thrown by a `throw` statement),
> and E1 != E2, then both exceptions should be preserved, with one being added as suppressed
> exception to the other one.

That is not unreasonable: E2 suppresses E1.

> 
>> But really the programmer is in the best position to decide how exceptions need to be handled.
> 
> Except that in a `finally` block they don't have access to the exception which led to execution
> of the `finally` block, unless they write verbose hacky code to first have a `catch (Throwable)`
> which stores the caught exception in a local variable. To me it appears for many `finally`
> blocks in existing code it was not actively decided how exception handling should be done,
> but rather it was forgotten that the original exception might get discarded when the `finally`
> throws a new exception; or that behavior was considered acceptable because currently Java does
> not allow you to handle it in a better way (which is one of the main points of this proposal).

The programmer writing the finally block also wrote, or has access to 
the try block that allows the original exception, so they are still in 
the best position to determine how any given chunk of code should react 
to exceptions IMO.

>>> Of course one could argue that the same applies to `catch` clauses whose body accidentally
>>> causes an exception which discards the caught one. However the main difference is that
>>
>> Yes exactly the same.
> 
> This point was mainly a safeguard in my proposal to avoid someone extending the scope of
> this proposal to `catch` clauses as well, which then could cause this proposal as a whole
> to be turned down. Therefore I am explicitly not arguing for any changes to `catch` clauses
> exception handling / suppression here, because there it is at least somewhat more obvious
> what is going on with the exceptions.
> 
>>> there, only a specific exception type is caught (and discarded), whereas for `finally`
>>> exceptions of _any_ type are discarded. It could also be argued that adding suppressed
>>
>> We have multi-catch now so that argument is somewhat weaker.
> 
> The point here was that you explicitly write the exception type, whether that is a single type
> or a union type in case of a multi-catch, in constrast to how `finally` discards any exception
> type without you explicitly naming the type.
> 
>>> exceptions decreases performance or causes memory leaks, but one the other hand
>>> this behavior was explicitly included try-with-resources statements, most likely because the
>>> value this adds was considered more important than any performance issues this
>>> might cause.
>>
>> try-with-resources added support for suppressed exceptions because the automatic closing of the resource could throw an exception, and that had to be factored in to the whole mechanism.
> 
> Yes, but I think the scenarios are exactly identical:
> try-with-resources:
>    1. Original exception E1 occurs
>    2. Resource cleanup is done, here through implicit `close()`
>    3. `close()` throws an exception E2
>    4. E2 is added as suppressed to E1
> 
> Current `finally` block behavior:
>    1. Original exception E1 occurs
>    2. Resource cleanup is done, here manually in `finally` block
>    3. `finally` block throws an exception E2
>    4. !! E1 is silently lost !!
> 
> Why is it here acceptable to lose the original exception E1, even though the use
> cases are exactly the same?

try-with-resources (twr) had to introduce suppressed exceptions to deal 
with the fact that the majority of close() operations throw a checked 
IOException, so twr had to deal with that. If trw had been implemented 
as a simple try/finally then the close() exception is the one that would 
be thrown. The designers of twr didn't want that because they decided 
that the exception from the try block was probably much more important 
to be seen in this context, than the IOException from the close(). So 
they introduced suppressed exceptions and defined twr such that the 
exception from the try block always gets rethrown by suppressing any 
exception from the finally/close(), and that exception from the close() 
is available through suppressed exception API.

So in the specific context of twr the original exception E1 was 
considered too important relative to the IOException (E2) from close() 
to allow it to be lost. So they worked around the behaviour of try/finally.

Given that we now have suppressed exceptions I agree there is merit in 
reusing it outside twr to allow E1 to not be lost when E2 occurs. But it 
would be suppression in the opposite sense to twr: the finally 
exception, E2, suppresses the try exception, E1.

> I assume the reason why they behave differently is historic, because `finally` blocks
> exist way longer than suppressed exceptions. However, that does in my opinion not
> preclude updating it retroactively, especially when it is unlikely that the difference
> will have a visible negative effect at runtime, but instead makes understanding
> application failures easier.

As I said I agree there is merit to this aspect, but it is not a 
core-libs issue. This requires a language change, and supporting javac 
changes. I suggest taking up this one aspect on the amber-dev mailing list:

https://openjdk.java.net/projects/amber/

I don't know if extending the use of suppressed exceptions came up when 
twr (automatic resource management) was developed under Project Coin:

https://openjdk.java.net/projects/coin/

Cheers,
David

> 
> Kind regards
> 
> 

From iris at openjdk.java.net  Fri Apr 29 02:19:41 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 29 Apr 2022 02:19:41 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
Message-ID: <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>

On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change punctuation from review feedback.

Is there intent to backport this to the RI for JSR 337 MR 4?

src/java.base/share/classes/java/lang/System.java line 743:

> 741:      *         have the value {@code "1"}; after a second maintenance
> 742:      *         release, this property will have the value {@code "2"},
> 743:      *         and so on.

There should be no requirement that values be allocated sequentially.  In other words, if JCP MR <x> does not require an RI, then it should not be surprising if there is no JDK build with maintenance version <x>.  As an example, JSR 337 MR 1 and MR 2 both used the same RI.  If this system property had existed during development of MR 1, it would return "1".  Since no RI was submitted for MR 2, a build returning "2" should never exist.  MR 3 did update the RI, so it would return "3".

src/java.base/share/classes/java/lang/VersionProps.java.template line 113:

> 111:         props.put("java.specification.version", VERSION_SPECIFICATION);
> 112: 
> 113:         // Uncomment next props.put call after the first maintenance release for a

Is "after" correct?  I think this value should be set to the target MR at the beginning of RI development for the release, similar to what is done for other version identification system properties.

-------------

Changes requested by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Fri Apr 29 02:49:36 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 02:49:36 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
Message-ID: <ZYkZ_zeRbGfWsulVEtjmCo2TJKEzBzsYIYqlNN00UeM=.d3967f91-bb23-4dbd-a1c1-fce9ac8b5a14@github.com>

On Fri, 29 Apr 2022 02:00:08 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/VersionProps.java.template line 113:
> 
>> 111:         props.put("java.specification.version", VERSION_SPECIFICATION);
>> 112: 
>> 113:         // Uncomment next props.put call after the first maintenance release for a
> 
> Is "after" correct?  I think this value should be set to the target MR at the beginning of RI development for the release, similar to what is done for other version identification system properties.

Well, sure -- this versioning info should be updated in the same way we update versions for all the early access builds of a release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Fri Apr 29 02:57:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 02:57:44 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
Message-ID: <-g8lbr2uvH6VC2t7Xga0rTmNevEU51QF_pXgvdfYiLY=.9b11990f-2d7f-459c-9e7e-792d8ded2a01@github.com>

On Fri, 29 Apr 2022 02:12:19 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/System.java line 743:
> 
>> 741:      *         have the value {@code "1"}; after a second maintenance
>> 742:      *         release, this property will have the value {@code "2"},
>> 743:      *         and so on.
> 
> There should be no requirement that values be allocated sequentially.  In other words, if JCP MR <x> does not require an RI, then it should not be surprising if there is no JDK build with maintenance version <x>.  As an example, JSR 337 MR 1 and MR 2 both used the same RI.  If this system property had existed during development of MR 1, it would return "1".  Since no RI was submitted for MR 2, a build returning "2" should never exist.  MR 3 did update the RI, so it would return "3".

> Is there intent to backport this to the RI for JSR 337 MR 4?

I think that would be helpful, if not strictly necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From smarks at openjdk.java.net  Fri Apr 29 03:00:40 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Apr 2022 03:00:40 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - Assertions over return values. Some refinement of equals() testing.
 - Add comment about Map.Entry identity not guaranteed.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8354/files
  - new: https://git.openjdk.java.net/jdk/pull/8354/files/5857fe6f..d66ad0b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8354&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8354&range=00-01

  Stats: 117 lines in 1 file changed: 84 ins; 2 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Fri Apr 29 03:05:42 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 29 Apr 2022 03:05:42 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
Message-ID: <VpTrziAlXlIvLfSP20cIfPC4gOWUboCM1mzGfiskVrE=.83630242-2c3e-4437-be00-aa280ca7a8d6@github.com>

On Fri, 29 Apr 2022 03:00:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Assertions over return values. Some refinement of equals() testing.
>  - Add comment about Map.Entry identity not guaranteed.

I've added checking of return values for I think everything that has a significant return value. I've elected to store the return value in a local variable and add a separate assert line. For example, instead of

    assertNull(map.put(newKey, newVal));

I've done

    Box r = map.put(newKey, newVal);
    assertNull(r);

The reason is that I think it separates the test setup/action from the test assertions. I tried it the first way, but it felt like the lack of this separation made things messy.

I've also added a couple more tests over `equals` and added more asserts over `equals` to the `keySet` and `entrySet` view sets. (Note, the `values` collection is just a `Collection` and thus doesn't have a defined notion of `equals`.) The testing of the view collections could probably be made more comprehensive, but I think what's here is a good start.

Please take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8354

From darcy at openjdk.java.net  Fri Apr 29 03:06:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 03:06:44 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <-g8lbr2uvH6VC2t7Xga0rTmNevEU51QF_pXgvdfYiLY=.9b11990f-2d7f-459c-9e7e-792d8ded2a01@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
 <-g8lbr2uvH6VC2t7Xga0rTmNevEU51QF_pXgvdfYiLY=.9b11990f-2d7f-459c-9e7e-792d8ded2a01@github.com>
Message-ID: <R-7TG-CkepaSnr-fI3CGVaz5bt8j3d2pf_2YOIPJR4w=.f4673934-90f2-4b4d-8126-a39b7af24e41@github.com>

On Fri, 29 Apr 2022 02:54:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Is there intent to backport this to the RI for JSR 337 MR 4?
> 
> I think that would be helpful, if not strictly necessary.

PS And if backported, the spec could be updated for earlier release trains to start at a different value like "4".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From duke at openjdk.java.net  Fri Apr 29 03:19:05 2022
From: duke at openjdk.java.net (Will)
Date: Fri, 29 Apr 2022 03:19:05 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <RIQ1uB4tq_yVpG3dlrMmzrVFOSO9N6-NXliAH9L4K6k=.69c3e21e-fc05-474a-b4c4-bbd20eff90ce@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

Marked as reviewed by will-molloy at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sminervini.prism at protonmail.com  Fri Apr 29 04:48:51 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Fri, 29 Apr 2022 04:48:51 +0000
Subject: Java Floating Point Arithmetic and StrictMath Method denormal and
 pronormal errors?
Message-ID: <TCf5e8ppF1JFwwgzbHsAQYQHvnDcEUncCFH8Frb3qbU8_cw6qeahgBe97utP4on_aPWgs_O3cwoq28JyEdCd-6XhPrA0JlrDPNxY5bdCaIo=@protonmail.com>

To Jochen Theodorou, OpenJDK, and the JCP,

The subject of our inquiry isn't the introduction of new types with compatible data writing
to float and double. Rather, we are trying to justify that float and double themselves need
to be repaired, or rendered dual mode, in source code and for code that cannot be recompiled.

/*
//The Java Language. Arithmetic only, no comparisons.

import static java.lang.System.*;
public class Start
{
public static void main(String ... args)
{
out.println();
out.println("Program has started...");
float a = 0.1F;
float b = 0.1F;
float c = a*b;
out.println();
out.println(c);
double d = 0.1D;
double e = 0.1D;
double f = d*e;
out.println();
out.println(f);
out.println();
out.println("Program has Finished.");
}}
*/
/* Program has started...

0.010000000000000002

0.010000001

[0.01]

Program has Finished.*/

IEE 754 doesn't specifically say anything about the base 10 digit degradation that can happen
at the right hand side of float and double like the included example. However all examples
like these are logic errors, that need to be repaired in either a default or certainly a mutual way,
simply because denary accuracy is required out of compiled, running, Java programs, in a fast,
efficient, and easiest-to-use way

The workarounds used, being BigInteger, BigDecimal, and big-math and the like are too
slow and too large in RAM memory, and don't allow for the use of arithmetic operators.
Things that we need!

What seems to be required is having two range limits for float and double; values range
limits, and right hand side consideration range limits for decimals and their relationship
to binary. If the existing range fields of float and double are not to be changed, but
if representation and inclusion problems are to go away, providing range accurate and
contiguous properties.

This applies to the float, float primitives, double, Double Objects, java.lang.StrictMath,
and any classes or interfaces closely bound with Float and Double, typically with
those terms in their names.

Extra SSE registers, and their descendents, exist in all relevant Java compatible
CPU hardware today. Those registers can be leveraged to solve these values and
calculations problems.

Another modern language that uses SSE, either by compiler switch or default, is GNU C++.
Its success, within ranges, certainly that are less than Java, yet nonetheless, are more
than an example, they are a source to draw from. Its implementation is freely available,
to copy, examine, include or refactor:

/*
//The C++ language. Arithmetic only, no comparisons.

#include <iostream>
//#include <iomanip>

using namespace std;

int main()
{
//cout << setprecision(20);
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}

Program has started...

0.01

0.01

Program has Finished.
*/

Compatability, if more desirable than default adjusting, can be leveraged at nearly any level.
If language precompilation cannot be altered, there are all sorts of approaches that would
work. Runtime and compiler switches would work. Manifest file entries are some option
Maybe annotations could be wrought to work, as applied to variables, data, objects,
classes and interfaces and static blocks. Just as float and double have the f,Fd,D,
data qualifiers, there could be subsequent data qualifiers and key words to go along
with float, Float, double, Double.

Since the OpenJDK does produce floating point errors, may those involved either repair the root
of the problem by default, or in a mutually compatible mode option way, in your version
of the OpenJDK and JRE?

We would be thrilled to hear about a positive response!

Sergio Minervini.

S.M.

Sent with [ProtonMail](https://protonmail.com/) secure email.

From dholmes at openjdk.java.net  Fri Apr 29 05:12:30 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 29 Apr 2022 05:12:30 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

That only seems to be half of the issue though. If we are defining _WIN32_WINNT=0x0601 because the minimum required OS API support level is Windows 7, then don't we need a check that the build platform is also at least Windows 7?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From sspitsyn at openjdk.java.net  Fri Apr 29 05:52:00 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 05:52:00 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66:

> 64:   for (i = 0; i < METH_NUM; i++)
> 65:     bpEvents[i] = 0;
> 66: }

As I understand all new tests are C++ based.
So, I'd suggest to always use C++ style of loops:
  for (int i = 0; i < METH_NUM; i++)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sspitsyn at openjdk.java.net  Fri Apr 29 06:17:16 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 06:17:16 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:

> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
> 139:   }

I'd suggest to add locals (their names are up to you):
   const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
   const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";

It is better to place togeter lines: 129+130.
Line 137 is not aligned, and there are many unneeded spaces.
The '()' around conditions are not needed. At least, I do not see them increasing readability.

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 167:

> 165:     result = checkStatus = STATUS_FAILED;
> 166:     LOG(
> 167:         "TEST FAILED: Breakpoint event with unexpected class signature:\n"

Combine lines 166+167.

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 187:

> 185:       jboolean isVirtual = jni->IsVirtualThread(thread);
> 186:       if (isVirtual != METHODS_ATTRS[i]) {
> 187:         LOG("TEST FAILED: IsVirtualThread check failed with unexpected result %d  when expected is %d\n", isVirtual, METHODS_ATTRS[i]);

Line 187 is too long and can be splitted.

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 231:

> 229:       result = STATUS_FAILED;
> 230:       LOG(
> 231:           "TEST FAILED: wrong number of Breakpoint events\n"

Combine 230+231.

test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 307:

> 305:   if (agent_lock == NULL) {
> 306:     return JNI_ERR;
> 307:   }

Better to also use same style with curly brackets in fragments: 293, 296, 299.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sspitsyn at openjdk.java.net  Fri Apr 29 06:23:14 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 06:23:14 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <Z5o2syiLeXbduZTzno9xBfKIr1w8thWrC3aij72q4q8=.01a20214-9fd7-4231-9c51-e11828c99d2c@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 139:

> 137:       primClsEvents[i]++;
> 138:       LOG(
> 139:           "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received for\n"

Combine 138+138.
I won't comment this more in hope the same will be fixed in all tests.

test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 177:

> 175:     return JNI_VERSION_1_8;
> 176: }
> 177: #endif

One empty line would be nice to add after 177.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From jiefu at openjdk.java.net  Fri Apr 29 06:35:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 29 Apr 2022 06:35:44 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v4]
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <VNRniZYH8sQAv_KF4fu22iA4UPfuSwKDXe_IYOvFGUQ=.117422e7-a797-4326-a4c6-38608cbaaeb4@github.com>

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Address CSR review comments
 - Merge branch 'master' into JDK-8284992
 - Address review comments
 - Merge branch 'master' into JDK-8284992
 - Merge branch 'master' into JDK-8284992
 - Address review comments
 - Merge branch 'master' into JDK-8284992
 - 8284992: Fix misleading Vector API doc for LSHR operator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8291/files
  - new: https://git.openjdk.java.net/jdk/pull/8291/files/7e82e721..0161571b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8291&range=02-03

  Stats: 6657 lines in 233 files changed: 5591 ins; 490 del; 576 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8291/head:pull/8291

PR: https://git.openjdk.java.net/jdk/pull/8291

From jiefu at openjdk.java.net  Fri Apr 29 06:35:46 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 29 Apr 2022 06:35:46 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
 <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
Message-ID: <_6U31AcxcdcIyCj_rQrAf1Lcgk0fcmNF3mrhNSjRkds=.0c91ddca-030f-4834-a227-d8bd1beb7325@github.com>

On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8284992
>>  - Merge branch 'master' into JDK-8284992
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8284992
>>  - 8284992: Fix misleading Vector API doc for LSHR operator
>
> It should be possible for you finalize now.

Hi @PaulSandoz , the CSR had been approved and I pushed one more commit to address the CSR review comments.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From sspitsyn at openjdk.java.net  Fri Apr 29 06:39:57 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 06:39:57 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59:

> 57: static jvmtiEventCallbacks callbacks;
> 58: static jint result = PASSED;
> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO???

I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters.
You can remove this comment then.

test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 201:

> 199:   LOG("\n");
> 200: 
> 201: 

Too many empty lines. It might make sense to do a common cleanup with all edits like this.

test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 258:

> 256:     return JNI_VERSION_1_8;
> 257: }
> 258: #endif

Empty line is missed => common cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sspitsyn at openjdk.java.net  Fri Apr 29 06:46:46 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 06:46:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 178:

> 176:            ex.c_cls, ex.c_name, ex.c_sig,
> 177:            (jint)(ex.c_loc >> 32), (jint)ex.c_loc);
> 178:     result = STATUS_FAILED;

Unaligned lines in the range: 172-177.
There are some non-uinified unneeded spaces at lines 172,175.

test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287:

> 285:   }
> 286: 
> 287:   eventsCount = 0;

Counters are not protected with locks.
I'm not sure it is a real problem here but would be better to double-check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From sspitsyn at openjdk.java.net  Fri Apr 29 06:50:40 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 29 Apr 2022 06:50:40 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <o76_CNmqll912wneB69YEogaplT9B_iWuqPMXituRUk=.9578dd40-0be1-427a-8d1f-1282b7eba56b@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target.
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I'm sorry for the noise with my comments.
I'll continue to discuss it privately unless there is something really important.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mbaesken at openjdk.java.net  Fri Apr 29 07:05:40 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 29 Apr 2022 07:05:40 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <m9XwYrHV2pay3AEiq9vXKwSjyuZ0HaMbTDm7gMiJVPY=.5478a430-512d-423f-b68f-704733f46013@github.com>
Message-ID: <SbRAx5xiFk5Z0guL5ZOOlz4ulLz4K6PTiQkgXb1myyg=.10fd53be-cd26-4318-9d9a-e3cbb49c77cb@github.com>

On Fri, 29 Apr 2022 05:09:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That only seems to be half of the issue though. If we are defining _WIN32_WINNT=0x0601 because the minimum required OS API support level is Windows 7, then don't we need a check that the build platform is also at least Windows 7?

Hi David,  on older OS than Windows 7 we wouldn't be able to build OJDK anyway currently. Our oldest VS we still support (see toolchain_microsoft.m4) is VS2017.  
VS2017 has the following system requirements 
https://docs.microsoft.com/en-us/visualstudio/releases/2017/vs2017-system-requirements-vs
see supported OS ,  there the oldest supported OS is Windows Server 2012 R2 and Windows 7 SP1. So on older than Win7 we would not even have a compiler anymore that passes configure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From serb at openjdk.java.net  Fri Apr 29 07:37:39 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 07:37:39 GMT
Subject: Integrated: 8285523: Improve test
 java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
References: <-bt5oGXqquoYViY10YSEyJu2llmEY7vGHBKFecUrqVY=.e0505dbd-7425-4e6f-a2d6-a13b272615b1@github.com>
Message-ID: <iACCfhPeTH4IS7g6MxBTJI_jq7yCgZ_Ns4Lf7SuWLYc=.d9d0b63d-d773-49da-9554-fc315467f181@github.com>

On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The new test added as part of the [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger that bug and pass w/ and w/o fix.
> 
> An updated test validates the "default" case when the `jdk.io.File.enableADS` property is not set, in this case the ADS should be [accepted](https://github.com/openjdk/jdk/blob/9d9f4e502f6ddc3116ed9b80f7168a1edfce839e/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L59).

This pull request has now been integrated.

Changeset: f42631e3
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f42631e354d4abf7994abd92aa5def6b2ceeab3a
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8285523: Improve test java/io/FileOutputStream/OpenNUL.java

Reviewed-by: andrew, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8379

From mcimadamore at openjdk.java.net  Fri Apr 29 08:09:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 29 Apr 2022 08:09:46 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
 <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>
Message-ID: <ev2fhY31U-E7cbjQ1P6z8ZpvNwM3u6gA0QtxsxtLSfI=.aec946ee-f52e-463e-af90-5d9778fd8492@github.com>

On Fri, 29 Apr 2022 00:44:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Remind: please use the command `/jep JEP-424` [1] to mark this PR.
> 
> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep

Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Fri Apr 29 08:15:32 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 29 Apr 2022 08:15:32 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v35]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak Addressable javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/945317ec..d1fcf012

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=33-34

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From gli at openjdk.java.net  Fri Apr 29 08:33:44 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 29 Apr 2022 08:33:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <ev2fhY31U-E7cbjQ1P6z8ZpvNwM3u6gA0QtxsxtLSfI=.aec946ee-f52e-463e-af90-5d9778fd8492@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
 <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>
 <ev2fhY31U-E7cbjQ1P6z8ZpvNwM3u6gA0QtxsxtLSfI=.aec946ee-f52e-463e-af90-5d9778fd8492@github.com>
Message-ID: <HVsG_LCCzlUo1f-0ZMKlCGM047qK2h9Klo3NGEPhfaM=.5717ef82-7868-43e7-bb12-9f64c434455c@github.com>

On Fri, 29 Apr 2022 08:06:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> would a jep unneeded be enough to "unstuck" this PR?

Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From prappo at openjdk.java.net  Fri Apr 29 08:48:52 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 29 Apr 2022 08:48:52 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
 <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
Message-ID: <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>

On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
>> 
>>> 46:  * The {@link #refersTo(Object) refersTo} method can be used to test
>>> 47:  * whether some object is the referent of a phantom reference.
>>> 48:  * @param<T> the type of the referent
>> 
>> Shouldn't there be a space after `@param` ?
>
> Good catch.  Sorry I missed it. This occurs in all `java/lang/ref` files.

> Shouldn't there be a space after `@param` ?

> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.

I built the API documentation after this PR has been integrated and the result was okay. I saw this output in every such case:

Type Parameters:
T - the type of the referent

javadoc is quite robust. However, for some IDEs such missing whitespace seems significant. Not only do they highlight the `@param` tag, but the type parameter information is missing from the rendered output.

Although it's not critical, we should fix it; I have filed JDK-8285890.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From prappo at openjdk.java.net  Fri Apr 29 09:09:50 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 29 Apr 2022 09:09:50 GMT
Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on
 classes and interfaces [v5]
In-Reply-To: <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>
References: <TqiWvROAmR4FeCI_EeKHbMNm4tS6i3GcmeO_RbutCT8=.21c7ba2c-51fb-4308-ba17-520999d7123f@github.com>
 <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com>
 <ly0yNqCx3P8EkbF_nagUNFG9fxo_DID-Q80BxAx9OZA=.93b1a3f1-00f7-4237-a36f-2268c7cedcb4@github.com>
 <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com>
 <pGkmGP6Kv4-jzotC0k99b4kWdLBEyNf0swKLRTaF0n8=.00b80a95-55b4-404c-84f4-5b205e988692@github.com>
Message-ID: <s7jcRxpCdX__MjSee5C2uABNv4DJwAw1t8Vz-PScIB4=.ad944e3a-6f20-4b9e-97e7-e463a6766405@github.com>

On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.

I've created a PR; feel free to review it at your convenience.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8410

From prappo at openjdk.java.net  Fri Apr 29 09:12:24 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 29 Apr 2022 09:12:24 GMT
Subject: RFR: 8285890: Fix some @param tags
Message-ID: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>

* Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
* Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

-------------

Commit messages:
 - Fix misspelled `@param`
 - Clarify with whitespace tags from 8285676

Changes: https://git.openjdk.java.net/jdk/pull/8465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8465&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285890
  Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8465/head:pull/8465

PR: https://git.openjdk.java.net/jdk/pull/8465

From daniel.fuchs at oracle.com  Fri Apr 29 09:34:34 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 29 Apr 2022 10:34:34 +0100
Subject: java.net.http.HttpClient do NOT support Digest authentication
 while HttpURLConnection do
In-Reply-To: <CAMMFzKa583KmWNepJHmjSS_fQ0dvrq2q5qBXffG28ZtvMbm3-A@mail.gmail.com>
References: <CAMMFzKa583KmWNepJHmjSS_fQ0dvrq2q5qBXffG28ZtvMbm3-A@mail.gmail.com>
Message-ID: <0d113294-86cc-fb72-f87e-19695bfe881f@oracle.com>

Hi,

java.net.http.HttpClient only supports Basic authentication out
of the box.

Which tutorials are claiming that Digest authentication is supported?
Can you send some links?

At the moment there is no plan to support digest authentication out of
the box. It can be easily implemented at the application level on top
of the existing APIs, by *not* registering an authenticator with
the client and dealing with 401/407 response from the application code.

best regards,

-- daniel

On 28/04/2022 23:40, Farkas Levente wrote:
> Hi,
> 
> Even though many tutorial said that the new java.net.http.HttpClient
> support Digest authentication it's not true:
> https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L278
> But at the same time HttpURLConnection support it through the simple:
> -------------------------------
> Authenticator.setDefault(new Authenticator() {
>      @Override
>      protected PasswordAuthentication getPasswordAuthentication() {
> 
>          return new PasswordAuthentication (
>              "username",
>              "password".toCharArray()
>          );
>      }
> });
> -------------------------------
> Is it a bug or you don't even plan to support it with HttpClient?
> Regards.
> 


From lfarkas at lfarkas.org  Fri Apr 29 09:49:38 2022
From: lfarkas at lfarkas.org (Farkas Levente)
Date: Fri, 29 Apr 2022 11:49:38 +0200
Subject: java.net.http.HttpClient do NOT support Digest authentication
 while HttpURLConnection do
In-Reply-To: <0d113294-86cc-fb72-f87e-19695bfe881f@oracle.com>
References: <CAMMFzKa583KmWNepJHmjSS_fQ0dvrq2q5qBXffG28ZtvMbm3-A@mail.gmail.com>
 <0d113294-86cc-fb72-f87e-19695bfe881f@oracle.com>
Message-ID: <d406fa2c-35d4-03ac-e58a-568b7084d3cc@lfarkas.org>

Hi,

Just to mention a few:
https://www.baeldung.com/java-9-http-client
https://developer.ibm.com/tutorials/java-theory-and-practice-3/

Also from this issue also assume it's support:
https://bugs.openjdk.java.net/browse/JDK-8138990
and this issue also contains a reference to:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/4204dbf90380/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
which makes assume it IS already implemented and as I wrote 
HttpURLConnection also support it.

That's why I suppose just should have to in add it to HttpClient.

IMHO it's still a big barrier to use HttpClient instead of the other 3th 
party http client implementations:
https://www.mocklab.io/blog/which-java-http-client-should-i-use-in-2020/

as a quote from:
https://medium.com/@kir.maxim/lesson-i-have-learned-from-using-jdk11-http-client-2cf990daba03
"JDK11 HTTP client supports only basic authentication scheme. From my 
point of view, this will block users from migrating their code to use 
the new library."

What's more even you wrote
"It can be easily implemented at the application level"
there is not ANY such public implementation...
Probably it has reasons...

Regards.


Levente                               "Si vis pacem para bellum!"

On 2022. 04. 29. 11:34, Daniel Fuchs wrote:
> Hi,
> 
> java.net.http.HttpClient only supports Basic authentication out
> of the box.
> 
> Which tutorials are claiming that Digest authentication is supported?
> Can you send some links?
> 
> At the moment there is no plan to support digest authentication out of
> the box. It can be easily implemented at the application level on top
> of the existing APIs, by *not* registering an authenticator with
> the client and dealing with 401/407 response from the application code.
> 
> best regards,
> 
> -- daniel
> 
> On 28/04/2022 23:40, Farkas Levente wrote:
>> Hi,
>>
>> Even though many tutorial said that the new java.net.http.HttpClient
>> support Digest authentication it's not true:
>> https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L278 
>>
>> But at the same time HttpURLConnection support it through the simple:
>> -------------------------------
>> Authenticator.setDefault(new Authenticator() {
>> ???? @Override
>> ???? protected PasswordAuthentication getPasswordAuthentication() {
>>
>> ???????? return new PasswordAuthentication (
>> ???????????? "username",
>> ???????????? "password".toCharArray()
>> ???????? );
>> ???? }
>> });
>> -------------------------------
>> Is it a bug or you don't even plan to support it with HttpClient?
>> Regards.
>>
> 

From daniel.fuchs at oracle.com  Fri Apr 29 10:22:11 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 29 Apr 2022 11:22:11 +0100
Subject: [External] : Re: java.net.http.HttpClient do NOT support Digest
 authentication while HttpURLConnection do
In-Reply-To: <d406fa2c-35d4-03ac-e58a-568b7084d3cc@lfarkas.org>
References: <CAMMFzKa583KmWNepJHmjSS_fQ0dvrq2q5qBXffG28ZtvMbm3-A@mail.gmail.com>
 <0d113294-86cc-fb72-f87e-19695bfe881f@oracle.com>
 <d406fa2c-35d4-03ac-e58a-568b7084d3cc@lfarkas.org>
Message-ID: <aff8582d-3b2f-0d10-147a-850e903dd2a2@oracle.com>

Hi,

Thanks for the pointers.

 > Just to mention a few:
 > 
https://urldefense.com/v3/__https://www.baeldung.com/java-9-http-client__;!!ACWV5N9M2RV99hQ!MbomkSmr-rXolK88z_JdINs3IEG8MTH_B7DHDq6wYgUeJQvZNGT7Iwb3yFswd57S1l85R53Yo_zq8zIvWdw$ 

 > 
https://urldefense.com/v3/__https://developer.ibm.com/tutorials/java-theory-and-practice-3/__;!!ACWV5N9M2RV99hQ!MbomkSmr-rXolK88z_JdINs3IEG8MTH_B7DHDq6wYgUeJQvZNGT7Iwb3yFswd57S1l85R53Yo_zqgE8E3ik$ 


"An Authenticator is an object that negotiates credentials
  (HTTP authentication) for a connection.
  It provides different authentication schemes (such as basic or
  digest authentication)."

I believe that's a misunderstanding: you will notice that the text
talks about the Authenticator - not the HttpClient. But I do agree
that this text is misleading (even WRT Authenticator).

HttpURLConnection does support digest authentication out of the box.
It was a choice we made to not support any authentication scheme out
of the box, except Basic, in the new API.

As I said Digest can be easily implemented at the application level
if you need it, by handling the 401/407 responses at the application
level.


best regards,

-- daniel

From ssahoo at openjdk.java.net  Fri Apr 29 10:36:50 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 29 Apr 2022 10:36:50 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v4]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <C7jod5oN3bi3poU_XgIEpGqvhysdYOD2rRzELaGO7j8=.4029ca54-5ce6-4e41-b3d7-6f53a7f81c28@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  8285452: Add a new test library API to replace a file content using FileUtils.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/ef5dc31a..14125936

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=02-03

  Stats: 143 lines in 2 files changed: 140 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From ssahoo at openjdk.java.net  Fri Apr 29 10:46:31 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 29 Apr 2022 10:46:31 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  updated to add space character in begining of multiline string

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/14125936..e18cd8cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From ssahoo at openjdk.java.net  Fri Apr 29 10:50:43 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 29 Apr 2022 10:50:43 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
Message-ID: <nRFCTOyab_oahIcaSt4T_XX6uaHfOEuOfrkMbD6JW14=.c0a92b48-3c1b-4011-b9fd-c74612428f34@github.com>

On Fri, 29 Apr 2022 10:46:31 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated to add space character in begining of multiline string

test/jdk/java/nio/file/Files/FileUtilsTest.java line 51:

> 49: c""";
> 50:         // 1st line has a space character
> 51:         String sabc = " " + System.lineSeparator() + abc;

It's strange that jcheck fails, if there is space character in beginning of line in a multiline string. So i have to follow this way add a space character in the beginning of multiline string.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From jlaskey at openjdk.java.net  Fri Apr 29 11:09:46 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 29 Apr 2022 11:09:46 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <nRFCTOyab_oahIcaSt4T_XX6uaHfOEuOfrkMbD6JW14=.c0a92b48-3c1b-4011-b9fd-c74612428f34@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
 <nRFCTOyab_oahIcaSt4T_XX6uaHfOEuOfrkMbD6JW14=.c0a92b48-3c1b-4011-b9fd-c74612428f34@github.com>
Message-ID: <UsenLpiJKBkhfM6Lp0KqGRM0uo9Caaq2iLcqJN3TokE=.93ef446a-4356-47e0-a2fd-242ed381cc85@github.com>

On Fri, 29 Apr 2022 10:46:58 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated to add space character in begining of multiline string
>
> test/jdk/java/nio/file/Files/FileUtilsTest.java line 51:
> 
>> 49: c""";
>> 50:         // 1st line has a space character
>> 51:         String sabc = " " + System.lineSeparator() + abc;
> 
> It's strange that jcheck fails, if there is space character in beginning of line in a multiline string. So i have to follow this way add a space character in the beginning of multiline string.

You can use \s instead of space. Then you will have no complaints.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From dfuchs at openjdk.java.net  Fri Apr 29 11:19:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 11:19:46 GMT
Subject: RFR: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <Tx79BYVGFWbmplr1GIS3GKFdajegzbx8VSDZfo1LnZ8=.897e278a-aa62-4d4d-9cd8-9c497804239e@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8465

From jpai at openjdk.java.net  Fri Apr 29 11:36:01 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 29 Apr 2022 11:36:01 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts file
Message-ID: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>

Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?

With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.

Testing done (on macOS):


cd test/failure_handler 
make test

Then verified that the generated environment.html had the `/etc/hosts` file content

-------------

Commit messages:
 - 8285915: failure_handler: gather the contents of /etc/hosts file

Changes: https://git.openjdk.java.net/jdk/pull/8466/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8466&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285915
  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8466/head:pull/8466

PR: https://git.openjdk.java.net/jdk/pull/8466

From weijun at openjdk.java.net  Fri Apr 29 11:56:42 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Apr 2022 11:56:42 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v4]
In-Reply-To: <C7jod5oN3bi3poU_XgIEpGqvhysdYOD2rRzELaGO7j8=.4029ca54-5ce6-4e41-b3d7-6f53a7f81c28@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <C7jod5oN3bi3poU_XgIEpGqvhysdYOD2rRzELaGO7j8=.4029ca54-5ce6-4e41-b3d7-6f53a7f81c28@github.com>
Message-ID: <Dv727ROW9Yrv7v9T-Z6dY23a1ytPvEwgTRkT0QK8pJQ=.7476ade7-df11-465a-a100-2ff0612f46c4@github.com>

On Fri, 29 Apr 2022 10:36:50 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285452: Add a new test library API to replace a file content using FileUtils.java

test/lib/jdk/test/lib/util/FileUtils.java line 396:

> 394:                 removed += lines.remove(fromLine - 1).trim();
> 395:             }
> 396:             var froms = Arrays.asList(from.split(System.lineSeparator())).stream()

How about just using `from.lines()`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From jpai at openjdk.java.net  Fri Apr 29 12:06:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 29 Apr 2022 12:06:45 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
Message-ID: <7RAAJPEdgNo3PoeQh8bQiXvr7Hdckya1cjLDt5oweHI=.a6d309e2-7307-4d91-a708-8f70658849ca@github.com>

On Fri, 29 Apr 2022 10:46:31 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated to add space character in begining of multiline string

test/lib/jdk/test/lib/util/FileUtils.java line 383:

> 381:      * Patches a part of a file.
> 382:      * @param path of file
> 383:      * @param fromLine the first line to patch. This is the number you see in an editor, 1-based.

Perhaps this should mention whether the `fromLine` is inclusive, like it's noted for the `toLine`?

test/lib/jdk/test/lib/util/FileUtils.java line 389:

> 387:      * @throws IOException
> 388:      */
> 389:     public static void patch(Path path, int fromLine, int toLine, String from, String to) throws IOException {

Should this method check whether the `fromLine` and `toLine` are valid values? Things like, negative value or 0 or `toLine` being less than `fromLine`. I'm not familiar with the expectations of test library code - maybe those checks aren't necessary since this is a test util?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From dfuchs at openjdk.java.net  Fri Apr 29 12:18:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 12:18:41 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <07aVdqoJ4nqwQdAt1HlkvR9Bu4xOPfQNZU14yHkKVWg=.5a319aab-9177-4180-a43c-924047104ec8@github.com>

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

Thanks for doing this Jaikiran! That should be helpful. Please get approval from someone from build-dev before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8466

From ssahoo at openjdk.java.net  Fri Apr 29 12:23:20 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 29 Apr 2022 12:23:20 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v6]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <0b-lckJ1rtWFl0keoJRGz8mWO6dvinXmpJsc4WnOQag=.2aa78ad7-230a-48c3-9f11-d6f889ad2157@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  8285452: updated to from.lines()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/e18cd8cc..da6a214a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From ssahoo at openjdk.java.net  Fri Apr 29 12:29:35 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 29 Apr 2022 12:29:35 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>

> A new API to support replacing selective lines with desired content.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  8285452: updated to use lines()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/da6a214a..0b7dc2f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From dfuchs at openjdk.java.net  Fri Apr 29 12:39:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 12:39:49 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
Message-ID: <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>

On Fri, 29 Apr 2022 12:29:35 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285452: updated to use lines()

test/lib/jdk/test/lib/util/FileUtils.java line 394:

> 392:             var removed = "";
> 393:             for (int i = fromLine; i <= toLine; i++) {
> 394:                 removed += lines.remove(fromLine - 1).trim();

shouldn't you insert a "\n" ? otherwise concatenating lines "ab" and "c" will be the same as concatenating lines "a" and "bc".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From erikj at openjdk.java.net  Fri Apr 29 12:47:45 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Apr 2022 12:47:45 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <_R62u4Q3Rmod2H3s7YjCke_S-RovV2GoPxekg17EIts=.b92d0441-9b78-4b6e-9c9a-84e7772120d6@github.com>

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

Marked as reviewed by erikj (Reviewer).

Not sure if it's relevant, but did you consider doing this for Windows as well? The file is located at `"$WINDIR/System32/drivers/etc/hosts"`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8466

From dfuchs at openjdk.java.net  Fri Apr 29 12:47:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 12:47:51 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
 <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
Message-ID: <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>

On Fri, 29 Apr 2022 12:35:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285452: updated to use lines()
>
> test/lib/jdk/test/lib/util/FileUtils.java line 394:
> 
>> 392:             var removed = "";
>> 393:             for (int i = fromLine; i <= toLine; i++) {
>> 394:                 removed += lines.remove(fromLine - 1).trim();
> 
> shouldn't you insert a "\n" ? otherwise concatenating lines "ab" and "c" will be the same as concatenating lines "a" and "bc".

Also calling trim() assumes that white spaces are not significant. This might not be the case in the general case (for instance - think of markdown files were leading spaces are significant).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From mullan at openjdk.java.net  Fri Apr 29 12:48:45 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 29 Apr 2022 12:48:45 GMT
Subject: RFR: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <fWFzThfhl1koxEltAWmHV9-mqFQLSZhCkM7GlrTICSs=.a47f0990-c694-4011-8441-dae9f9425139@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

GSSHeader looks fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8465

From jpai at openjdk.java.net  Fri Apr 29 12:54:42 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 29 Apr 2022 12:54:42 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <zP-zXmalbkyCYv42OHQeSOFhxghBIr1f5WKF50bVBBg=.25e13b29-d9de-4d9a-8513-cf417c1b3bfd@github.com>

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

Hello Erik,

> Not sure if it's relevant, but did you consider doing this for Windows as well? The file is located at `"$WINDIR/System32/drivers/etc/hosts"`.

I hadn't investigated what the corresponding command would be for Windows, so had left it out. Quick question - the path you note, is that even applicable for x64? I see that it has a "System32" so just curious. I'll experiment a bit shortly against some CI setups to see how this goes on Windows.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8466

From weijun at openjdk.java.net  Fri Apr 29 13:05:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Apr 2022 13:05:49 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
 <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
 <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>
Message-ID: <01evhTorNGOUIkDzktNUhSU1_G_WBZ80h1MYvwtesj4=.a5ce2e09-54c9-4eb4-9eb5-727f74f384a6@github.com>

On Fri, 29 Apr 2022 12:44:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/FileUtils.java line 394:
>> 
>>> 392:             var removed = "";
>>> 393:             for (int i = fromLine; i <= toLine; i++) {
>>> 394:                 removed += lines.remove(fromLine - 1).trim();
>> 
>> shouldn't you insert a "\n" ? otherwise concatenating lines "ab" and "c" will be the same as concatenating lines "a" and "bc".
>
> Also calling trim() assumes that white spaces are not significant. This might not be the case in the general case (for instance - think of markdown files were leading spaces are significant).

The comparison is intentionally made lax so the caller does not need to provide the exact indentation or even new line characters. We think along with `fromLine` and `toLine` this is enough to make sure we are not modifying the wrong lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From erikj at openjdk.java.net  Fri Apr 29 13:11:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Apr 2022 13:11:35 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file
In-Reply-To: <zP-zXmalbkyCYv42OHQeSOFhxghBIr1f5WKF50bVBBg=.25e13b29-d9de-4d9a-8513-cf417c1b3bfd@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
 <zP-zXmalbkyCYv42OHQeSOFhxghBIr1f5WKF50bVBBg=.25e13b29-d9de-4d9a-8513-cf417c1b3bfd@github.com>
Message-ID: <SSTqg5k3tsi__zeYGibPmyrM9_G6ilhoWT9RyHC0QB0=.19a72f3c-7fe8-4352-96a6-fc16519bb804@github.com>

On Fri, 29 Apr 2022 12:51:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Quick question - the path you note, is that even applicable for x64? I see that it has a "System32" so just curious. 

Yes, System32 is not related to 32 vs 64 bit. As I understand it, that name was introduced when moving from 16 to 32 bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8466

From duke at openjdk.java.net  Fri Apr 29 13:31:30 2022
From: duke at openjdk.java.net (Shruthi)
Date: Fri, 29 Apr 2022 13:31:30 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

Shruthi has updated the pull request incrementally with one additional commit since the last revision:

  Updating last modified tag and XRTreeFragSelectWrapper.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/8c93a25b..d53ca37e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

PR: https://git.openjdk.java.net/jdk/pull/8318

From dfuchs at openjdk.java.net  Fri Apr 29 14:22:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 14:22:43 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <01evhTorNGOUIkDzktNUhSU1_G_WBZ80h1MYvwtesj4=.a5ce2e09-54c9-4eb4-9eb5-727f74f384a6@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
 <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
 <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>
 <01evhTorNGOUIkDzktNUhSU1_G_WBZ80h1MYvwtesj4=.a5ce2e09-54c9-4eb4-9eb5-727f74f384a6@github.com>
Message-ID: <pTWpiAYv6ed_BwN_7aaBZJ0_a5Rm5yjnYKV4XwnO_WA=.f9c814d7-6c34-42e8-bf6a-e704b6a1effe@github.com>

On Fri, 29 Apr 2022 13:02:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Also calling trim() assumes that white spaces are not significant. This might not be the case in the general case (for instance - think of markdown files were leading spaces are significant).
>
> The comparison is intentionally made lax so the caller does not need to provide the exact indentation or even new line characters. We think along with `fromLine` and `toLine` this is enough to make sure we are not modifying the wrong lines.

Shouldn't the comparison be better implemented by the caller then, who will know whether spaces are important or not? That's why I had suggested taking a `Predicate<String>` that could be called with each line removed, and the caller could interrupt the parsing by returning false when it detects a mismatch with what they expect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From weijun at openjdk.java.net  Fri Apr 29 15:54:45 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Apr 2022 15:54:45 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <7RAAJPEdgNo3PoeQh8bQiXvr7Hdckya1cjLDt5oweHI=.a6d309e2-7307-4d91-a708-8f70658849ca@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
 <7RAAJPEdgNo3PoeQh8bQiXvr7Hdckya1cjLDt5oweHI=.a6d309e2-7307-4d91-a708-8f70658849ca@github.com>
Message-ID: <1l_DgR2KfeB1qDNJTeIzCEdEhy1wGTGnxpMUrChRvHo=.fe3bcba6-e120-40ab-b4b3-5db0fa316f48@github.com>

On Fri, 29 Apr 2022 12:02:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated to add space character in begining of multiline string
>
> test/lib/jdk/test/lib/util/FileUtils.java line 389:
> 
>> 387:      * @throws IOException
>> 388:      */
>> 389:     public static void patch(Path path, int fromLine, int toLine, String from, String to) throws IOException {
> 
> Should this method check whether the `fromLine` and `toLine` are valid values? Things like, negative value or 0 or `toLine` being less than `fromLine`. I'm not familiar with the expectations of test library code - maybe those checks aren't necessary since this is a test util?

`lines.remove()` and `lines.subList()` will throw the correct exception. Since you asked, we can add it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From psandoz at openjdk.java.net  Fri Apr 29 15:56:49 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 29 Apr 2022 15:56:49 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v4]
In-Reply-To: <VNRniZYH8sQAv_KF4fu22iA4UPfuSwKDXe_IYOvFGUQ=.117422e7-a797-4326-a4c6-38608cbaaeb4@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <VNRniZYH8sQAv_KF4fu22iA4UPfuSwKDXe_IYOvFGUQ=.117422e7-a797-4326-a4c6-38608cbaaeb4@github.com>
Message-ID: <Jii9WKFAU9hRSPH6C8ksP1KQMRcq_XyFdpclxHyFOnY=.2b4f9fba-a62c-4055-89ca-3d4965abc71a@github.com>

On Fri, 29 Apr 2022 06:35:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> The Current Vector API doc for `LSHR` is
>> 
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>> 
>> 
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
>> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>> 
>> After the patch, the doc for `LSHR` is
>> 
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Address CSR review comments
>  - Merge branch 'master' into JDK-8284992
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - Merge branch 'master' into JDK-8284992
>  - Address review comments
>  - Merge branch 'master' into JDK-8284992
>  - 8284992: Fix misleading Vector API doc for LSHR operator

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From darcy at openjdk.java.net  Fri Apr 29 16:13:43 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 29 Apr 2022 16:13:43 GMT
Subject: RFR: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <bpLa2qC7Drb2RwH160GXod9yBvDQTPKzt9BXH0ReCtk=.15d7a29d-7dff-4272-a3c2-53a941476eb2@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

Thanks for fixing these Pavel.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8465

From mchung at openjdk.java.net  Fri Apr 29 16:44:55 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 29 Apr 2022 16:44:55 GMT
Subject: RFR: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <3lTTXDQCB7Eo73e__RGK6CYITxDq1O3YjBQ6wuDxU7E=.2abb2368-9869-4fe2-a372-3d6ba95a486b@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8465

From iklam at openjdk.java.net  Fri Apr 29 16:47:39 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 29 Apr 2022 16:47:39 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
Message-ID: <ou-Am6j5ptetpKVcJN1K4_dnEiV0jvKsSTNMmFUJGMc=.67a0811f-2122-43e9-a77e-829737e294de@github.com>

On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that adds dedicated filler objects to the VM?
>> 
>> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
>> 
>> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
>> 
>> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
>> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
>> 
>> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
>> 
>> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
>> 
>> This has the following benefits:
>> 
>> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
>> 
>> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
>> 
>> This causes some minor changes to external behavior:
>> 
>> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
>> 
>> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
>> 
>> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
>> 
>> 
>> Testing: tier1-8
>> 
>> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
>> 
>> Thanks go to @iklam for helping out with the change.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

The latest version looks good to me.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8156

From lancea at openjdk.java.net  Fri Apr 29 17:07:50 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 29 Apr 2022 17:07:50 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
Message-ID: <CZsIUgF1xakUAE4FxAFmForGSLgBcXlirvgGqd-6Bd0=.edb6fb9e-48cb-40e2-8ab6-72c7f08d9eba@github.com>

On Fri, 29 Apr 2022 12:29:35 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285452: updated to use lines()

test/jdk/java/nio/file/Files/FileUtilsTest.java line 111:

> 109:         test(abcList, 1, 3, "ab", xyz, "xyz");
> 110:     }
> 111: 

Any thought of using TestNG with a DataProvider?  Seems more efficient

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From rriggs at openjdk.java.net  Fri Apr 29 17:11:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 29 Apr 2022 17:11:43 GMT
Subject: RFR: 8282227: Locale information for nb is not working properly
In-Reply-To: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
References: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
Message-ID: <B9scsTF_boYfhcfd-uDQ_xIGb3TRwTyGFHyTDydDAr4=.6a922d76-035b-4ece-8129-df0628cbcf38@github.com>

On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8394

From mr at openjdk.java.net  Fri Apr 29 17:15:57 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Fri, 29 Apr 2022 17:15:57 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
Message-ID: <ComDy6I5wL37EpHF_giwqof4VNkvZzCvexm3SGukzMc=.e476bdd6-12a6-4ae0-9f8d-8dd79a20aaa4@github.com>

On Fri, 29 Apr 2022 02:12:19 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/System.java line 743:
> 
>> 741:      *         have the value {@code "1"}; after a second maintenance
>> 742:      *         release, this property will have the value {@code "2"},
>> 743:      *         and so on.
> 
> There should be no requirement that values be allocated sequentially.  In other words, if JCP MR <x> does not require an RI, then it should not be surprising if there is no JDK build with maintenance version <x>.  As an example, JSR 337 MR 1 and MR 2 both used the same RI.  If this system property had existed during development of MR 1, it would return "1".  Since no RI was submitted for MR 2, a build returning "2" should never exist.  MR 3 did update the RI, so it would return "3".

@irisclark does raise an interesting point: If, say, MR 2 doesn?t require a change to the RI then the MR 1 RI is also the MR 2 RI, but its `java.specification.maintenance.version` property will report that it?s the MR 1 RI.

One way to fix this would be to require an RI update with every MR just to update this property, even if no other code in the RI changes ? but we prefer to avoid doing RI builds unnecessarily.

Another way to fix it would be to finesse the specification of this property, perhaps:


     * <tr><th scope="row">{@systemProperty java.specification.maintenance.version}</th>
     *     <td>Java Runtime Environment specification maintenance version, which may
     *         be interpreted as a non-zero integer. If defined, the value of this
     *         property is the identifying number of the most recent <a
     *         href="https://jcp.org/en/procedures/jcp2#3.6.4">specification
     *         maintenance release</a> that required a change to the runtime</a>
     *         <em>(optional)</em>.
     *         </td></tr>

-------------

PR: https://git.openjdk.java.net/jdk/pull/8437

From wetmore at openjdk.java.net  Fri Apr 29 17:20:42 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 29 Apr 2022 17:20:42 GMT
Subject: RFR: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <RVZP459XGmY6rFrAayKkBv18CXAN_C75bmAlQ8pEYUc=.8c2b43c5-741a-4a1c-8417-2c3dca020a40@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

LGTM also.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8465

From naoto at openjdk.java.net  Fri Apr 29 17:24:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 29 Apr 2022 17:24:41 GMT
Subject: Integrated: 8282227: Locale information for nb is not working properly
In-Reply-To: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
References: <nc9aTrJt7qhdTHUyVtXcMdGmObgLs7-s-57ehuVWxlo=.30ec889f-ea60-4343-b756-862542ed9630@github.com>
Message-ID: <BSxhJtj_uvJuCg1I8PurJubLYA6MnGkuEM5ygW6agRw=.1c62ea68-cfbb-498d-a742-688e19a35e18@github.com>

On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue.

This pull request has now been integrated.

Changeset: 3d07b3c7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d07b3c7f01b60ff4dc38f62407c212b48883dbf
Stats:     79 lines in 2 files changed: 74 ins; 1 del; 4 mod

8282227: Locale information for nb is not working properly

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8394

From mseledtsov at openjdk.java.net  Fri Apr 29 18:14:01 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 29 Apr 2022 18:14:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <liZtGOo8abai8AD4cl7fZOGa5HiQMiG_821NwNZKeL4=.317cd575-b6c7-4642-9997-9dfb1661bf61@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/hotspot/jtreg/runtime/vthread/StackChunkClassLoaderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Please update copyright year.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mseledtsov at openjdk.java.net  Fri Apr 29 18:30:25 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 29 Apr 2022 18:30:25 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57:

> 55:         int classLoaderCount = Integer.parseInt(args[0]);
> 56:         int classCount = Integer.parseInt(args[1]);
> 57:         for (int i = 0; i <classCount; i++) {

Minor: Style: please insert space between < and classCount

test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 64:

> 62:                 theClass.newInstance();
> 63:                 TestEvent event = new TestEvent();
> 64:                 event.theClass = event;

Did you mean event.theClass = theClass instead ?

test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57:

> 55:         int classLoaderCount = Integer.parseInt(args[0]);
> 56:         int classCount = Integer.parseInt(args[1]);
> 57:         for (int i = 0; i <classCount; i++) {

Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mseledtsov at openjdk.java.net  Fri Apr 29 18:30:26 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 29 Apr 2022 18:30:26 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
Message-ID: <PriQRNsi8xRpmwjeidDgIU5B0I366pfuPwMrBM7SGT0=.8720b666-0c75-4477-ba0c-62c2b4afdfe9@github.com>

On Fri, 29 Apr 2022 18:23:35 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57:
> 
>> 55:         int classLoaderCount = Integer.parseInt(args[0]);
>> 56:         int classCount = Integer.parseInt(args[1]);
>> 57:         for (int i = 0; i <classCount; i++) {
> 
> Minor: Style: please insert space between < and classCount

Also, should this be i < classLoaderCount ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From weijun at openjdk.java.net  Fri Apr 29 18:32:40 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 29 Apr 2022 18:32:40 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <pTWpiAYv6ed_BwN_7aaBZJ0_a5Rm5yjnYKV4XwnO_WA=.f9c814d7-6c34-42e8-bf6a-e704b6a1effe@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
 <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
 <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>
 <01evhTorNGOUIkDzktNUhSU1_G_WBZ80h1MYvwtesj4=.a5ce2e09-54c9-4eb4-9eb5-727f74f384a6@github.com>
 <pTWpiAYv6ed_BwN_7aaBZJ0_a5Rm5yjnYKV4XwnO_WA=.f9c814d7-6c34-42e8-bf6a-e704b6a1effe@github.com>
Message-ID: <n1i_r3x9ojRNmr_PLgEuQRk5xcblmob54NA22R-NeMk=.9cce110d-661a-4832-8b54-9d82efdaebbc@github.com>

On Fri, 29 Apr 2022 14:19:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The comparison is intentionally made lax so the caller does not need to provide the exact indentation or even new line characters. We think along with `fromLine` and `toLine` this is enough to make sure we are not modifying the wrong lines.
>
> Shouldn't the comparison be better implemented by the caller then, who will know whether spaces are important or not? That's why I had suggested taking a `Predicate<String>` that could be called with each line removed, and the caller could interrupt the parsing by returning false when they detect a mismatch with what they expect.

We can provide a more sophisticated `Function<String,String>` replacer if we want to let user to customize all the details. This time we still only want them to be string literals. I agree we can keep the new lines inside, but trimming on each line and the final block is still useful so caller does not need to care about indentation and empty lines at both ends.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From jbhateja at openjdk.java.net  Fri Apr 29 18:33:25 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 29 Apr 2022 18:33:25 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator)
Message-ID: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>

Hi All,

Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)

Following is the brief summary of changes:-

1)  Extends the scope of existing lanewise API for following new vector operations.
   -  VectorOperations.BIT_COUNT: counts the number of one-bits
   - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
   - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
   - VectorOperations.REVERSE: reversing the order of bits
   - VectorOperations.REVERSE_BYTES: reversing the order of bytes
   - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.

2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
   - Vector.compress
   - Vector.expand 
   - VectorMask.compress

3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
  - Vector.fromMemorySegment
  - Vector.intoMemorySegment

4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.


 Patch has been regressed over AARCH64 and X86 targets different AVX levels. 

 Kindly review and share your feedback.

 Best Regards,
 Jatin

-------------

Commit messages:
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: AARCH64 backend changes.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Integration of JEP 426: Vector API (Fourth Incubator)

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284960
  Stats: 37837 lines in 214 files changed: 16462 ins; 16923 del; 4452 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From gli at openjdk.java.net  Fri Apr 29 18:33:25 2022
From: gli at openjdk.java.net (Guoxiong Li)
Date: Fri, 29 Apr 2022 18:33:25 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator)
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <G8uBtW7Qf30N1OQFdngZWMwYsBttq5eJ90HqiqThJ9g=.159cec07-b1b3-41a6-a0b7-477512aa0ba2@github.com>

On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Remind: please use the command `/jep JEP-426` [1] to mark this PR.

[1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From dfuchs at openjdk.java.net  Fri Apr 29 18:49:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Apr 2022 18:49:44 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v7]
In-Reply-To: <n1i_r3x9ojRNmr_PLgEuQRk5xcblmob54NA22R-NeMk=.9cce110d-661a-4832-8b54-9d82efdaebbc@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <rOupAm5Q56fITvVgsuvXDbRVW2MYdSBb5iwCWNnEM0w=.ae31e133-79f1-4283-8099-3c0af6a7e2f3@github.com>
 <G-EOVBPUfjTdIa0gbQ5SVsRdX4SLBBqD1fJKpNJwLQ8=.73389f2f-6803-4a32-b28c-217c32541496@github.com>
 <8HBH78nB583yhxK52CJUtIf0E_wrrlLbV8yGP_5ckA0=.8164c401-cbbb-4ef6-8706-b9ddcb6dbe76@github.com>
 <01evhTorNGOUIkDzktNUhSU1_G_WBZ80h1MYvwtesj4=.a5ce2e09-54c9-4eb4-9eb5-727f74f384a6@github.com>
 <pTWpiAYv6ed_BwN_7aaBZJ0_a5Rm5yjnYKV4XwnO_WA=.f9c814d7-6c34-42e8-bf6a-e704b6a1effe@github.com>
 <n1i_r3x9ojRNmr_PLgEuQRk5xcblmob54NA22R-NeMk=.9cce110d-661a-4832-8b54-9d82efdaebbc@github.com>
Message-ID: <WCwzprjnrPLeGpU3eCWT7Xx3qPZlLk5aRme9XlRZx30=.905fb7a6-9b2d-49d3-8b46-3801320be060@github.com>

On Fri, 29 Apr 2022 18:28:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Shouldn't the comparison be better implemented by the caller then, who will know whether spaces are important or not? That's why I had suggested taking a `Predicate<String>` that could be called with each line removed, and the caller could interrupt the parsing by returning false when they detect a mismatch with what they expect.
>
> We can provide a more sophisticated `Function<String,String>` replacer if we want to let user to customize all the details. This time we still only want them to be string literals. I agree we can keep the new lines inside, but trimming on each line and the final block is still useful so caller does not need to care about indentation and empty lines at both ends.

OK - if you keep the internal new  lines I have no objection. The API doc should however say that lines will be trimmed before comparing them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8360

From aturbanov at openjdk.java.net  Fri Apr 29 20:16:14 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 29 Apr 2022 20:16:14 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName
Message-ID: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>

`Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
Instead we can just use Map.get and compare result with `null`.
I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
it gives a bit of performance for `toZid`.


Benchmark                             Mode  Cnt   Score   Error  Units
ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op


<details>
<summary>Benchmark</summary>


@BenchmarkMode(value = Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Benchmark)
public class ZoneNamesBench {

    @Benchmark
    public String useExistingCountry() {
        return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
    }

    @Benchmark
    public String useExistingCountryOld() {
        return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
    }
}



    public static String toZid(String zid, Locale locale) {
        String mzone = zidToMzone.get(zid);
        if (mzone == null) {
            String alias = aliases.get(zid);
            if (alias != null) {
                zid = alias;
                mzone = zidToMzone.get(zid);
            }
        }
        if (mzone != null) {
            Map<String, String> map = mzoneToZidL.get(mzone);
            if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
                zid = mzoneToZid.get(mzone);
            }
        }
        return toZid(zid);
    }

    public static String toZid(String zid) {
        return aliases.getOrDefault(zid, zid);
    }

    public static String toZidOld(String zid, Locale locale) {
        String mzone = zidToMzone.get(zid);
        if (mzone == null && aliases.containsKey(zid)) {
            zid = aliases.get(zid);
            mzone = zidToMzone.get(zid);
        }
        if (mzone != null) {
            Map<String, String> map = mzoneToZidL.get(mzone);
            if (map != null && map.containsKey(locale.getCountry())) {
                zid = map.get(locale.getCountry());
            } else {
                zid = mzoneToZid.get(mzone);
            }
        }
        return toZidOld(zid);
    }

    public static String toZidOld(String zid) {
        if (aliases.containsKey(zid)) {
            return aliases.get(zid);
        }
        return zid;
    }

</details>

-------------

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey calls in ZoneName
 - [PATCH] Avoid redundant HashMap.containsKey calls in ZoneName

Changes: https://git.openjdk.java.net/jdk/pull/8463/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8463&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285947
  Stats: 14 lines in 1 file changed: 3 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8463/head:pull/8463

PR: https://git.openjdk.java.net/jdk/pull/8463

From mchung at openjdk.java.net  Fri Apr 29 20:37:58 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 29 Apr 2022 20:37:58 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
Message-ID: <e-Cn_VlPZaymi0QEGmcBN2pRLOuOTopxpKbuBQ1W4UI=.5c48f7f1-bdb6-4616-827e-d1a05960e5c3@github.com>

On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Typo fix; add implSpec to Executable.
>  - Appease jcheck.
>  - Fix some bugs found by inspection, docs cleanup.
>  - Merge branch 'master' into JDK-8266670
>  - Initial support for accessFlags methods
>  - Add mask to access flag functionality.
>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/7ac698ba...14980605

I took a closer look at the proposed APIs.   I think it's in a good state to target for 19.   I skimmed on the existing JDK usage of `getModifiers` other than a trivial test e.g. is public, final, etc and the proposed API works well (btw no plan to convert them and just use those cases for validation). 

The value of `ACC_SUPER` and `ACC_STRICT` could possibly be reused for new access flags.   It may be useful to document when the flag becomes obsolete.

Nit: the enum constants are listed in the order of the mask value, which I like.   Some enum constants reference the `Modifer` constants but I think it'd help to see the mask value here consistently for all entries.   One go-to place in the source if I want to find the value of different flags.

src/java.base/share/classes/java/lang/Class.java line 1328:

> 1326:      * @since 19
> 1327:      */
> 1328:     public Set<AccessFlag> accessFlags() {

The access flags of a hidden class has no difference than that of a normal class.  A hidden class is created with normal `ClassFile` except that it's created via `Lookup::defineHiddenClass` API. 

I think the `Class::accessFlags` method should specify the access flags for primitive type, void, and array classes as `Class::getModifiers` specified.

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 216:

> 214: 
> 215:         /**
> 216:          * {@return an unmodifiable set of the module {@linkplain AccessFlag

Suggestion:

         * {@return a possibly-empty unmodifiable set of the module {@linkplain AccessFlag


as specified in the `@return` of the `modifiers()` method.   Same comment applies to the `accessFlags` method in `ModuleDescriptor.Opens` and other classes.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 44:

> 42:  * <em>not</em> have an access flag, such as {@code sealed} (JVMS
> 43:  * {@jvms 4.7.31}) and some access flags have no corresponding
> 44:  * modifier, such as {@linkplain SYNTHETIC synthetic}.

Suggestion:

 * modifier, such as {@linkplain #SYNTHETIC synthetic}.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 186:

> 184:     /**
> 185:      * The access flag {@code ACC_ABSTRACT}, corresponding to the
> 186:      * source modifier {@code link Modifier#ABSTRACT abstract}.

Suggestion:

     * source modifier {@link Modifier#ABSTRACT abstract}.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 306:

> 304:      * Note that since these locations represent class file structures
> 305:      * rather than language structures many language structures, such
> 306:      * as constructors and interfaces, are <em>not</em> present.

missing `@since 19`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From rriggs at openjdk.java.net  Fri Apr 29 20:40:44 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 29 Apr 2022 20:40:44 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <Y-cU9liOGBTdqvWcomeQvort3igyODlO_0pTPcsaJx4=.51c6d49c-acac-4b38-9b10-c886ed9d1e85@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

src/java.base/share/classes/java/time/format/ZoneName.java.template line 60:

> 58: 
> 59:     public static String toZid(String zid) {
> 60:         return aliases.getOrDefault(zid, zid);

Is the behavior if zid == null the same?  aliases.getOrDefault will throw NPE on null.
neither Hashmap.containsKey or .get throw on null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8463

From aturbanov at openjdk.java.net  Fri Apr 29 20:48:44 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 29 Apr 2022 20:48:44 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <Y-cU9liOGBTdqvWcomeQvort3igyODlO_0pTPcsaJx4=.51c6d49c-acac-4b38-9b10-c886ed9d1e85@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
 <Y-cU9liOGBTdqvWcomeQvort3igyODlO_0pTPcsaJx4=.51c6d49c-acac-4b38-9b10-c886ed9d1e85@github.com>
Message-ID: <WRa2qegvpf9kV_c4oxucRv0GTsin9yRK4WKGlc9duL4=.301f9f6c-d5e2-4a91-ae75-a6e9e4449e40@github.com>

On Fri, 29 Apr 2022 20:36:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>aliases.getOrDefault will throw NPE on null

No, It will not. `aliases` is a HashMap. And HashMap supports null values and keys.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8463

From aturbanov at openjdk.java.net  Fri Apr 29 20:58:53 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 29 Apr 2022 20:58:53 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <WRa2qegvpf9kV_c4oxucRv0GTsin9yRK4WKGlc9duL4=.301f9f6c-d5e2-4a91-ae75-a6e9e4449e40@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
 <Y-cU9liOGBTdqvWcomeQvort3igyODlO_0pTPcsaJx4=.51c6d49c-acac-4b38-9b10-c886ed9d1e85@github.com>
 <WRa2qegvpf9kV_c4oxucRv0GTsin9yRK4WKGlc9duL4=.301f9f6c-d5e2-4a91-ae75-a6e9e4449e40@github.com>
Message-ID: <z1c2gF6ZXPjaamvm8ArZA-A9Vf4HiXK8iXA9oz69vGw=.a1e9441b-bf98-4aae-a1a1-8a27c4621c5d@github.com>

On Fri, 29 Apr 2022 20:45:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/ZoneName.java.template line 60:
>> 
>>> 58: 
>>> 59:     public static String toZid(String zid) {
>>> 60:         return aliases.getOrDefault(zid, zid);
>> 
>> Is the behavior if zid == null the same?  aliases.getOrDefault will throw NPE on null.
>> neither Hashmap.containsKey or .get throw on null.
>
>>aliases.getOrDefault will throw NPE on null
> 
> No, It will not. `aliases` is a HashMap. And HashMap supports null values and keys.

Anyway, this method is used only in `DateTimeFormatterBuilder` and it doesn't pass `null` value there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8463

From egahlin at openjdk.java.net  Fri Apr 29 21:00:27 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 29 Apr 2022 21:00:27 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
Message-ID: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>

On Fri, 29 Apr 2022 18:27:27 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57:
> 
>> 55:         int classLoaderCount = Integer.parseInt(args[0]);
>> 56:         int classCount = Integer.parseInt(args[1]);
>> 57:         for (int i = 0; i <classCount; i++) {
> 
> Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount.

The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not created a lot of classes, similar to TestManyClasses. How is this related to Loom?  Could this be a merge gone bad?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From aturbanov at openjdk.java.net  Fri Apr 29 21:25:43 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 29 Apr 2022 21:25:43 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <XBl2BP0ukJ9RC_JCWWnLmVTDKkS39cJ5n-P78B_ghZU=.0d677768-b7cc-4383-81ae-c0c6f2c8e315@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

Hm, build of this branch fails with Crash on `Optimizing the exploded image` on one of my machines. ?? 

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=57300, tid=10552


[hs_err_pid49380.log](https://github.com/openjdk/jdk/files/8594756/hs_err_pid49380.log)
[hs_err_pid57300.log](https://github.com/openjdk/jdk/files/8594758/hs_err_pid57300.log)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8463

From psandoz at openjdk.java.net  Fri Apr 29 21:37:44 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 29 Apr 2022 21:37:44 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
Message-ID: <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>

On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename the "usePred" to "offsetInRange"

IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented.

Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking `offsetInRange`.

Might be better to hold off until the JEP is integrated and then update, since this will conflict (`byte[]` and `ByteBuffer` load methods are removed and `MemorySegment` load methods are added). You could prepare for that now by branching off `vectorIntrinsics`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From duke at openjdk.java.net  Fri Apr 29 21:50:34 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 29 Apr 2022 21:50:34 GMT
Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <CCPPF__OnM7aNDGMCZc2H1SuV7WdgsLBRlXXRL5q8og=.e1447160-722d-4484-b3a9-0a4182f99d1a@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

So, after reading the updated valhalla documentation, namely after the expert group decides to represent identity vs value with flags without touching inheritance (so saves serialization breakage when there's no spurious `IdentityObject`) and that `LambdaMetafactory` will reject identity or value interfaces per [Value Objects JEP](https://openjdk.java.net/jeps/8277163), I wonder about the future of dynamic proxies as well. I expect proxies to reject identity or value interfaces like `LambdaMetafactory`, and we most likely need a new API, like Remi's, if we wish to support identity/value interfaces.

Also for deserialization, since we have `Unsafe.allocateInstance`, we might alternatively replace the `anew` bytecode with such a call for the native serialization constructor if we do serialize and deserialize any hidden class like proxies, without touching the security part.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From jiefu at openjdk.java.net  Fri Apr 29 23:02:38 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 29 Apr 2022 23:02:38 GMT
Subject: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v3]
In-Reply-To: <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
 <XpWljtiivTbccUjEv9rjM7ycJKco2Akiz7MrCRZ8S_w=.f09eddd6-5d3f-4c27-b07a-75e6504f0c13@github.com>
 <7yQXnFCMzFCBFvLOfPv8X2paOHOfKgS8GFOjlxgHC64=.c6d955be-9888-48f2-ad06-76741eb28e9b@github.com>
Message-ID: <EA8HPWTeZBLflORxqtecDMjYFkAGeNn5nnDZJlFMnJI=.5a4aaafd-d231-4c14-ac60-f47592148fc8@github.com>

On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8284992
>>  - Merge branch 'master' into JDK-8284992
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8284992
>>  - 8284992: Fix misleading Vector API doc for LSHR operator
>
> It should be possible for you finalize now.

Thanks @PaulSandoz for the review and help.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From jiefu at openjdk.java.net  Fri Apr 29 23:05:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 29 Apr 2022 23:05:44 GMT
Subject: Integrated: 8284992: Fix misleading Vector API doc for LSHR operator
In-Reply-To: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
References: <Rtwyp7zXo1Ut4eomAw_RYW-D1uLZX7RnAkUDg3suP5Q=.32b2a26c-55b3-4049-af8d-fb6c6343d7f7@github.com>
Message-ID: <WCYJgBrFRvTy-LNRobyxKAp9gZbg3x2hs2mtII31qVA=.8b6ababd-fa53-4f8d-a370-ea6f918ddc8f@github.com>

On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The Current Vector API doc for `LSHR` is
> 
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
> 
> 
> This is misleading which may lead to bugs for Java developers.
> This is because for negative byte/short elements, the results computed by `LSHR` will be different from that of `>>>`.
> For more details, please see https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
> 
> After the patch, the doc for `LSHR` is
> 
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
> 
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: e54f26aa
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e54f26aa3d5d44264e052bc51d3d819a8da5d1e7
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8284992: Fix misleading Vector API doc for LSHR operator

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/8291

From duke at openjdk.java.net  Fri Apr 29 23:13:28 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 29 Apr 2022 23:13:28 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v3]
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <daDth03KrRjFcamZuinVexr_ikEWJhWRw5YGgtP5d3k=.53161db6-2267-4ccc-b969-de7560ac84f9@github.com>

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Fix assertions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8259/files
  - new: https://git.openjdk.java.net/jdk/pull/8259/files/dd416079..fe91721d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8259&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8259&range=01-02

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.java.net/jdk/pull/8259

From mseledtsov at openjdk.java.net  Fri Apr 29 23:21:12 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 29 Apr 2022 23:21:12 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

test/lib/jdk/test/lib/thread/VThreadRunner.java line 61:

> 59:     /**
> 60:      * Run a task in a virtual thread and wait for it to terminate.
> 61:      * If the task completse with an exception then it is thrown by this method.

typo: completse --> completes

test/lib/jdk/test/lib/thread/VThreadRunner.java line 121:

> 119:     /**
> 120:      * Run a task in a virtual thread and wait for it to terminate.
> 121:      * If the task completse with an exception then it is thrown by this method.

completse --> completes

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From mseledtsov at openjdk.java.net  Fri Apr 29 23:57:02 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 29 Apr 2022 23:57:02 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
Message-ID: <V51QhaDxelX9LxzjrK0rEvSvJDmrc3VLhdb-xvj7dR0=.9183416a-5cd9-47bb-825b-287cc699c636@github.com>

On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e

I have reviewed the following portions of this change: 
  test/common, test/gtest, test/hotspot/runtime, test/jdk/jfr, test library

Feedback:
  - see several minor comments inline
  - under runtime/cds/appcds/test-classes there is an empty "TEST.properties" file; was it added by mistake?

With only a few minor comments, I approve of the code reviewed by me provided that my comments will be addressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat Apr 30 09:30:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 30 Apr 2022 09:30:36 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
In-Reply-To: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
Message-ID: <ELNuKUl7_9XY4qMHkBrG8f5SCg5wKvuTGYjVOOA2lew=.1df7828d-36e1-450c-96d8-79c308e3ab45@github.com>

On Sat, 23 Apr 2022 21:02:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
> <details>
> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
> 
> 
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
> 
>     static final int SIZE = TimeUnit.values().length * 10;
> 
>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>     int bias;
> 
>     TimeUnit[] mod;
> 
>     @Setup
>     public void setup() {
>         mod = new TimeUnit[SIZE];
> 
>         TimeUnit[] vals = TimeUnit.values();
>         for (int c = 0; c < SIZE; c++) {
>             if (bias == -1) {
>                 // megamorphic
>                 mod[c] = vals[c % vals.length];
>             } else {
>                 mod[c] = vals[bias];
>             }
>         }
> 
>         Random r = new Random();
>         for (int c = 0; c < 10000; c++) {
>             int i = r.nextInt();
>             for (int o = 0; o < vals.length; o++) {
>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>                     throw new IllegalStateException("switch " + o);
>             }
>         }
>     }
> 
>     @Benchmark
>     public void const_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu, 1L));
>         }
>     }
> 
>     @Benchmark
>     public void const_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu, 1L));
>         }
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu) {
>         return tu.toNanos(1L);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu, long value) {
>         return tu.toNanos(value);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu) {
>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu, long value) {
>         return TimeUnit.NANOSECONDS.convert(value, tu);
>     }
> }
> 
> Results:
> 
> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
> 
> 
> </details>

The changes to the Selector implementations to use toXXX look okay. Note that it's not performance critical as it is only executed when a thread blocked in epoll_wait/equivalent is interrupted by a signal, it's not a normal code path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8376

From scolebourne at openjdk.java.net  Sat Apr 30 11:47:40 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Sat, 30 Apr 2022 11:47:40 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <DxoftshaZkiHaP_L3r9K5j5SV6Fp5eeETBAvQ6UjyrU=.2bf41899-36d8-4558-a389-70f37f0050d5@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

Logically, this LGTM

-------------

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/8463

From duke at openjdk.java.net  Sat Apr 30 14:11:41 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Sat, 30 Apr 2022 14:11:41 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v35]
In-Reply-To: <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
Message-ID: <noIUE1CqZ-o4dpg9YNRrNV9D1bk1wVZAyuD8Gu4wJyU=.1dc16a5e-303d-4caf-a3fb-6bd03a37680a@github.com>

On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak Addressable javadoc

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 101:

> 99:     }
> 100: 
> 101:     public final static class ScopedAccessError extends Error {

This?should probably?use the?canonical modifier?order as?specified in?[JDK?8276348] ([GH?6213]):
Suggestion:

    public static final class ScopedAccessError extends Error {


[JDK?8276348]: https://bugs.openjdk.java.net/browse/JDK-8276348 "[JDK?8276348] Use?blessed modifier?order in?java.base"
[GH?6213]: https://github.com/openjdk/jdk/pull/6213

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From turbanoff at gmail.com  Sat Apr 30 14:48:58 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Sat, 30 Apr 2022 17:48:58 +0300
Subject: Unused method sun.reflect.misc.MethodUtil.getPublicMethods
Message-ID: <CAF+DQ5fduaH1pwur2Ph=LSVD7fHDTruz9CBc-wOmnkz5nNeHcw@mail.gmail.com>

Hello.
I found a few methods in MethodUtil class which seem unused to me:
getPublicMethods, getInterfaceMethods, getInternalPublicMethods ,addMethod.

Are they somehow used by VM, or is it just leftovers from some refactorings?
I wonder if we can drop them.


Andrey Turbanov

From prappo at openjdk.java.net  Sat Apr 30 21:24:44 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 30 Apr 2022 21:24:44 GMT
Subject: Integrated: 8285890: Fix some @param tags
In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com>
Message-ID: <fCfcMBUlrVMnM9P1x4sJaPFU3wzgvyRYEk76PpfY8bM=.b7ca4f1d-d2fb-4f9e-96d0-c1b6d6182b4e@github.com>

On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs

This pull request has now been integrated.

Changeset: 3eb661bb
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3eb661bbe7151f3a7e949b6518f57896c2bd4136
Stats:     16 lines in 8 files changed: 0 ins; 0 del; 16 mod

8285890: Fix some @param tags

Reviewed-by: dfuchs, mullan, darcy, mchung, wetmore

-------------

PR: https://git.openjdk.java.net/jdk/pull/8465