From plevart at openjdk.org  Sun Jan  1 10:31:48 2023
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 1 Jan 2023 10:31:48 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <R8C1Up1FIEmWKXe_oUiOO4eVZ1XV6ro0EGZtYBfzFak=.63fb774b-ff30-4938-92c7-95ca72a5dc3d@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

Hello Markus,

Happy 2023!

I checked out your JMH code and I'm a little uncomfortable with two things:
- at least on Linux, the benchmark does not actually involve any input from the device (HD, SSD) at all.
- at least on Linux, the benchmark involves output to the device (HD, SSD) in a way that might interfere with the banchmark.

Let me explain. In the per-invocation @Setup method you create new file with random bytes and close it. At least on Linux this actually just writes the content to the write-back buffer cache. The disk is not touched yet. Writing happens asynchronously in the background while the benchmark is running. The benchmark reads from that file but this does not involve reading from the device at all, since the whole content is already present in buffer cache. So what this benchmark does is it measures overhead of JNI invocations from Java to native code and the overhead of system calls from native code to kernel which are served from buffer cache. All this happens while asynchronous writes to disk are taking place which might interfere with benchmark as they compete with benchmark for system resources.
While running your unchanged benchmark, I checked the output of `iostat 2` which proves above claims:


Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1          22.50         0.00       438.75         0.00          0        877          0


So I modified your benchmark a bit:
- I copied the InputStream.transferTo method to the benchmark itself so that buffer size can be passed as argument. I think this should not present any noticable difference since we are not measuring the quality of JIT-ed code but overheads of JNI and system calls which are of entirely different magnitude.
- I moved the creation of a temporary file from per-invocation to per-trial @Setup method and added a "sync" command at the end which flushes the data to the actual device and waits for flushing to complete.
- I added a "drop_caches" command just before opening the file for reading in the per-invocation @Setup method. This drops cached data of the file so that reads in the benchmark method are made from the actual device. Since the use of buffer cache is an important use case I added a boolean `dropCaches` parameter to measure both cases.

Both commands work on Linux and I don't have equivalent commands for Windows. `sync` works on Mac OS too, but `drop_caches` is Linux specific. Mac OS has a `purge` command for droping caches which must be executed as root.

Here are the results with dropCaches=true on a Linux PC with SSD:
https://jmh.morethan.io/?gist=abcba62638a1fa652fd597fa141a1a10

Here are the results with dropCaches=false:
https://jmh.morethan.io/?gist=ac8af4d8232b6f3a758491381d2fae31

And here's the modified benchmark:


public class TransferToPerformance {

    @State(Scope.Benchmark)
    public static class Config {

        @Param({"8388608"}) // 8 MiB
        public int streamSize;

        @Param({"1024", "2048", "4096", "8192", "16384", "32768", "65536", "131072"})
        public int bufferSize;

        @Param({"false", "true"}) // just before opening file for reading
        public boolean dropCaches;

        public InputStream source;
        public OutputStream target;
        private Path path;

        @Setup(Level.Trial)
        public void setUpTrial() throws IOException, InterruptedException {
            path = Files.createTempFile("a-", ".bin");
            var bytes = createRandomBytes(streamSize);
            Files.deleteIfExists(this.path);
            Files.write(this.path, bytes, CREATE, TRUNCATE_EXISTING, WRITE);
            sync();
        }

        @TearDown(Level.Trial)
        public void tearDownTrial() throws IOException {
            Files.deleteIfExists(this.path);
        }

        @Setup(Level.Invocation)
        public void setUpInvocation() throws IOException, InterruptedException {
            if (dropCaches) {
                dropCaches();
            }
            source = new FileInputStream(this.path.toFile());
            target = new ByteArrayOutputStream();
        }

        @TearDown(Level.Invocation)
        public void tearDownInvocation() throws IOException {
            source.close();
            target.close();
            source = null;
            target = null;
        }
    }

    private static byte[] createRandomBytes(int size) {
        var bytes = new byte[size];
        ThreadLocalRandom.current().nextBytes(bytes);
        return bytes;
    }

    @Benchmark
    @Fork(warmups = 0, value = 1)
    @BenchmarkMode(Mode.AverageTime)
    @Warmup(iterations = 3, time = 2)
    @Measurement(iterations = 5, time = 4)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public final void transferTo(Config config, Blackhole blackhole) throws IOException {
        blackhole.consume(transferTo(config.bufferSize, config.source, config.target));
    }

    private static long transferTo(int bufferSize, InputStream in, OutputStream out) throws IOException {
        long transferred = 0;
        byte[] buffer = new byte[bufferSize];
        int read;
        while ((read = in.read(buffer, 0, bufferSize)) >= 0) {
            out.write(buffer, 0, read);
            transferred += read;
        }
        return transferred;
    }

    private static void sync() throws IOException, InterruptedException {
        var proc = new ProcessBuilder("sync").start();
        proc.waitFor();
    }

    private static void dropCaches() throws IOException, InterruptedException {
        var proc = new ProcessBuilder(
            "sudo",
            "bash", "-c",
            "echo 1 > /proc/sys/vm/drop_caches"
        ).start();
        proc.waitFor();
    }
}


When reading involves actual device, at least on my computer, the increase of buffer size from 8k to 16k does not give any benefit. When reading involves cached data only, the benefit is marginal. I wonder what results would you get with this modified benchmark...

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

PR: https://git.openjdk.org/jdk/pull/11783

From jpai at openjdk.org  Mon Jan  2 10:03:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Jan 2023 10:03:29 GMT
Subject: RFR: 8299441: Fix typos in some test files under core-libs component
Message-ID: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>

Can I please get a review of this change which fixes the final few typos in test files in the core-libs area? This addresses the remaining core-libs related typos from the original PR https://github.com/openjdk/jdk/pull/10029.

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

Commit messages:
 - 8299441: Fix typos in some test files under core-libs component

Changes: https://git.openjdk.org/jdk/pull/11810/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299441
  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11810/head:pull/11810

PR: https://git.openjdk.org/jdk/pull/11810

From plevart at openjdk.org  Mon Jan  2 10:05:48 2023
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 2 Jan 2023 10:05:48 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <1WvnmdM85JB2nM0tWFeVGls1sAzdkKOdhp6L5TSBj84=.64c7b756-5f30-4849-a9a8-af9d135c9b6b@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

Here's also results for "modern" architecture - I executed the benchmark in a k8s container on an Oracle cloud ARM64 virtual machine.

With dropCaches=true:
https://jmh.morethan.io/?gist=2db4c3b51073e90c1a84d7eed8e1a988

With dropCaches=false:
https://jmh.morethan.io/?gist=d7dfb5def5899af41722b2768a827006

Here, the benefit of increasing buffer from 8k to 16k gets from about 10% (doing IO) up to 20% (reading from cache) increase in performance.

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

PR: https://git.openjdk.org/jdk/pull/11783

From lancea at openjdk.org  Mon Jan  2 11:45:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 2 Jan 2023 11:45:48 GMT
Subject: RFR: 8299441: Fix typos in some test files under core-libs
 component
In-Reply-To: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
References: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
Message-ID: <90_F_xJDx2A8xOkcVIZtA-3BtKWjXfa68CgNkEX2gWQ=.b4140b9f-3143-4b24-b935-7b8092959e5a@github.com>

On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the final few typos in test files in the core-libs area? This addresses the remaining core-libs related typos from the original PR https://github.com/openjdk/jdk/pull/10029.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11810

From jvernee at openjdk.org  Mon Jan  2 12:10:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 2 Jan 2023 12:10:55 GMT
Subject: Integrated: 8298590: Refactor LambdaForm constructors
In-Reply-To: <EVqdVtK45xq8NkbBSjQcpqi6hin9BXtcZplPDh7pjvI=.ab7c50b7-95e6-4263-8c2a-97be8890de63@github.com>
References: <EVqdVtK45xq8NkbBSjQcpqi6hin9BXtcZplPDh7pjvI=.ab7c50b7-95e6-4263-8c2a-97be8890de63@github.com>
Message-ID: <OioBBNusLcPkfwnysyqol8aRU6jJ3KRHPWt4fi3jTH0=.7e860647-f6a8-46ff-80c0-f458d73fd921@github.com>

On Fri, 9 Dec 2022 18:02:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Refactor LambdaForm constructors into static factories.
> 
> In the new code, there's only 1 constructor, which simply initializes all fields. Multiple factory methods are built on top of this, which add various argument validation/pre-processing and post processing of the constructed lambda forms.
> 
> In the LambdaFrom class itself, it is easier to see which LF creation goes through which checks due to names of factory, or if all checks are bypassed by calling the constructor.
> 
> New factories can easily be added that bypass all the checks in the existing factories and just call the root constructor if they so wish to (we likely want to add several for lazy lambda form resolution https://bugs.openjdk.org/browse/JDK-8288041).
> 
> Additionally: replaced some default values literals with named constants so it's easy to see that it's just the default value for that arg at the call site.

This pull request has now been integrated.

Changeset: 0532045e
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0532045edb709a995a42c07d95cb1cbabe886bed
Stats:     97 lines in 8 files changed: 32 ins; 13 del; 52 mod

8298590: Refactor LambdaForm constructors

Reviewed-by: redestad

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

PR: https://git.openjdk.org/jdk/pull/11612

From duke at openjdk.org  Mon Jan  2 21:09:46 2023
From: duke at openjdk.org (Markus KARG)
Date: Mon, 2 Jan 2023 21:09:46 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <1WvnmdM85JB2nM0tWFeVGls1sAzdkKOdhp6L5TSBj84=.64c7b756-5f30-4849-a9a8-af9d135c9b6b@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
 <1WvnmdM85JB2nM0tWFeVGls1sAzdkKOdhp6L5TSBj84=.64c7b756-5f30-4849-a9a8-af9d135c9b6b@github.com>
Message-ID: <pBWbGV8rb0OXtGDRDYyRZrLMUMQSpmjnE6QDZVn6vm8=.8f7e3864-388f-49f8-a27e-1454d62a0021@github.com>

On Mon, 2 Jan 2023 10:03:02 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Here, the benefit of increasing buffer from 8k to 16k gets from about 10% (doing IO) up to 20% (reading from cache) increase in performance.

I think 10% to 20% is good enough as an argument to go with 16k instead of 8k.

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

PR: https://git.openjdk.org/jdk/pull/11783

From duke at openjdk.org  Mon Jan  2 22:51:14 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 2 Jan 2023 22:51:14 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v9]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <nGgMtwDzD-uBjqUyp3m3zXSHWbrrCl0ycI7RUhhaTVI=.1fc4db5a-3425-4baa-8a46-ae5e4f7e0368@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp 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 13 additional commits since the last revision:

 - More recursion
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
 - Merge remote-tracking branch 'origin/master' into fix-8240567
 - Refine tests
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>
 - Revert to original SystemModulesPlugin
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>
 - Merge remote-tracking branch 'origin/master' into fix-8240567
 - Refine test
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
 - Adapt number to have javac working (and refine test)
 - Remove obsolete comment
 - Begin to craft test
 - Reduce comment text
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4c9038c4...ede0e87f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/96362d54..ede0e87f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=07-08

  Stats: 5946 lines in 539 files changed: 3276 ins; 1260 del; 1410 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From jpai at openjdk.org  Tue Jan  3 02:01:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Jan 2023 02:01:52 GMT
Subject: RFR: 8299441: Fix typos in some test files under core-libs
 component
In-Reply-To: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
References: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
Message-ID: <8TPl4uQllbD7mYMnv_p1hONsNthH4iMKLDEMrAH5888=.e32a0c02-6e4e-4e67-8b4b-97ba2ef3e6a0@github.com>

On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the final few typos in test files in the core-libs area? This addresses the remaining core-libs related typos from the original PR https://github.com/openjdk/jdk/pull/10029.

Thank you Lance for the review.

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

PR: https://git.openjdk.org/jdk/pull/11810

From jpai at openjdk.org  Tue Jan  3 02:01:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Jan 2023 02:01:53 GMT
Subject: Integrated: 8299441: Fix typos in some test files under core-libs
 component
In-Reply-To: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
References: <kbzZIKTmGEb6Q9zHGo7HPqj_5hbB7Ynkada5isJM_1Y=.9a306b43-445f-4512-bb25-3b364b1bad2a@github.com>
Message-ID: <kstXr4E_l399Gr5-tJVUWpcBZX1HCBMtze4yYRY07V4=.28a61865-16c2-46c5-acd4-80d2e5554332@github.com>

On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the final few typos in test files in the core-libs area? This addresses the remaining core-libs related typos from the original PR https://github.com/openjdk/jdk/pull/10029.

This pull request has now been integrated.

Changeset: 417d01ea
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/417d01ea63261afb4fb29b4d11de799f2c0846d7
Stats:     5 lines in 4 files changed: 0 ins; 0 del; 5 mod

8299441: Fix typos in some test files under core-libs component

Co-authored-by: Michael Ernst <mernst at openjdk.org>
Reviewed-by: lancea

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

PR: https://git.openjdk.org/jdk/pull/11810

From djelinski at openjdk.org  Tue Jan  3 14:05:33 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 3 Jan 2023 14:05:33 GMT
Subject: RFR: 8189338: JMX RMI Remote Mbean server connection hangs if the
 server stops responding during a SSL Handshake
Message-ID: <lvbRFcpv6IQXtjPCtR6qdIFeCCIbinaY3dBfWx_MrXM=.643b5a49-1767-4fdc-91e2-5b6eee79a4be@github.com>

This patch introduces a time limit for establishing a secure connection to a RMI server.

The existing implementation uses the configured `sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; there's no time limit for SSL handshake.
With this patch, the configuration option `sun.rmi.transport.tcp.handshakeTimeout` is also used as a socket read timeout during the SSL handshake.

I modified the existing `HandshakeTimeout` test to verify both non-SSL and SSL connections; the test passes with my changes, fails without them.

Existing tier1-3 tests continue to pass.

While working on the patch I noticed that `conn.isReusable()` always returns true. I can remove all references to `isReusable` here or in another PR; it would simplify the code a bit.

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

Commit messages:
 - Copyright
 - RMI SSL timeout

Changes: https://git.openjdk.org/jdk/pull/11829/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8189338
  Stats: 41 lines in 2 files changed: 23 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11829.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11829/head:pull/11829

PR: https://git.openjdk.org/jdk/pull/11829

From alanb at openjdk.org  Tue Jan  3 16:18:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jan 2023 16:18:49 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <pSNfDZcECqBUqTY5wsQmkz8MPDsy-OU4qSLRFBqe8rA=.6e08c932-ea34-4c44-9035-52dff16d4a02@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

The source input stream and target output stream can be connected to anything and reading/writing may involve compressed or encrypted streams. 8k has always been a default that is expected to be a good compromise for a wide range of sources and targets. It's good to have data for the file -> BAOS case for both cold and cached cases. No objection to bumping it to 16k as it's a temporary buffer so can be GC'ed when there isn't a thread blocked in transferTo (or readNBytes).

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

PR: https://git.openjdk.org/jdk/pull/11783

From alanb at openjdk.org  Tue Jan  3 16:20:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jan 2023 16:20:51 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
 <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
 <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
Message-ID: <f8lBv2grA_mHK-pLXtIYEKih-eOJL44r0gMuUd3LhdM=.5c60c4b0-ede9-4f3a-b808-6c0a72e1ba03@github.com>

On Thu, 8 Dec 2022 07:41:22 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Would it be possible to paste in a summary on the VerifyError with the previous iteration? If I read the latest update then the limit per helper method has been bump to avoid it, is that right?
>
>> Would it be possible to paste in a summary on the VerifyError with the previous iteration?
> 
> Isn't this https://github.com/openjdk/jdk/pull/10704#issuecomment-1286106503?
> 
>     Type top (current frame, locals[15]) is not assignable to reference type
> 
>>  If I read the latest update then the limit per helper method has been bump to avoid it, is that right?
> 
> Yes. Then, the compiler still works - and we can try to debug using the test case (yet to be finalized).

@koppor Should we continue to just ignore this PR for now? The current patch is test only, I don't know if that is deliberate or not.

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

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Tue Jan  3 16:30:48 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 3 Jan 2023 16:30:48 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
 <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
 <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
Message-ID: <pWlh7DlmBhToyfdFoPQae70R6yQ-6khif0ZbwXWSWko=.558a10c0-5173-4260-8b5e-c17c7673b656@github.com>

On Thu, 8 Dec 2022 07:41:22 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Would it be possible to paste in a summary on the VerifyError with the previous iteration? If I read the latest update then the limit per helper method has been bump to avoid it, is that right?
>
>> Would it be possible to paste in a summary on the VerifyError with the previous iteration?
> 
> Isn't this https://github.com/openjdk/jdk/pull/10704#issuecomment-1286106503?
> 
>     Type top (current frame, locals[15]) is not assignable to reference type
> 
>>  If I read the latest update then the limit per helper method has been bump to avoid it, is that right?
> 
> Yes. Then, the compiler still works - and we can try to debug using the test case (yet to be finalized).

Yes, we are currently trying to set up the test, so it results in the original method too large error.  Then we will re add the module splitting. (Working on this together with @koppor )

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

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Tue Jan  3 17:48:35 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 3 Jan 2023 17:48:35 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails
 for hr_HR
Message-ID: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>

Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 

_java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.

Swapping the outdated to **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

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

Commit messages:
 - Switch symbol to EUR for hr_HR

Changes: https://git.openjdk.org/jdk/pull/11833/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11833&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299439
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11833.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11833/head:pull/11833

PR: https://git.openjdk.org/jdk/pull/11833

From zjx001202 at gmail.com  Tue Jan  3 17:50:11 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 4 Jan 2023 01:50:11 +0800
Subject: The javadocs of some methods in NIO Buffer are missing @since
In-Reply-To: <46d254cd-4f0d-f81c-8e2b-20579e4379ac@oracle.com>
References: <CAJL5A3=e=r-3g9A+9ELwB8qnpMrC2NBKUxdwN+abx3-0pvZXeg@mail.gmail.com>
 <7aa9059c-7e0e-6c61-a87c-b9a537f2a8df@oracle.com>
 <CAJL5A3=LtA9DBQn_byuSeTOx4gJaDmg6nKesFCYiFdibcU=DfA@mail.gmail.com>
 <46d254cd-4f0d-f81c-8e2b-20579e4379ac@oracle.com>
Message-ID: <CAJL5A3m6HzOhJbtPJAFvAcENTP5rPwFq3oomDUEUQ6kYV_kRrA@mail.gmail.com>

You are talking about an idealistic situation that is divorced from reality.

When using the -target option, I need to set the bootclasspath at the same
time -- at least in theory.
But in the real world, I have never seen this option set in the build
script of any project.
If I open an issue in a project for this problem, the most likely thing is
that the project maintainer
will ask me what is the significance of doing this.

All the project maintainers I met are happy to let the project compile on
more JDKs.
Even if this may cause some problems at some time, they always regard the
incompatibility
of some JDK versions as a problem, rather than requiring that compatible
JDK must be used for building.
So far, there are no exceptions.

The same is true for the --add-exports option. Of course, I know that the
internal classes may be modified at any time,
but is it meaningful to require that a certain version of JDK must be used
for construction?
This is not only meaningless, but also covers up problems that should have
been found during compilation.

As for multi-release jar...Don't you know its problems in the real world?
Build tools, IDEs, static analysis tools... We solved a problem with
multi-release jars,
and then we had a lot of problems with multi-release jars.

Let's stop discussing the conflict between the ideal situation and the
workarounds in the real world, OK?
Let's go back to the issue -- Java 9 has added some new API methods. The
javadoc of these methods does not have @ since tags.
Is this an oversight?

On Sat, Dec 31, 2022 at 4:38 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 30/12/2022 19:11, Glavo wrote:
> > I agree that it is a good choice to use -release or set bootclasspath.
> > However, this is not always realistic.
> >
> > Using -release means that we will encounter many JPMS problems.
> > For example, using --add-exports for system modules is not allowed
> > when using -release.
>
> This combination of options doesn't make sense. If you are going off
> piste and compiling against JDK internal classes then you'll need to
> have that JDK present on your file system. A release number maps to the
> language and APIs in that release, it can't be expected to know about
> JDK internal classes that happen to be a JDK build as they can vary and
> shimmer by vendor or update. Maybe if you could expand a bit on what you
> are doing so it can help you avoid the configuration issue in your build.
>
>
> >
> > In addition, sometimes we may want to deliberately bypass the
> > restriction of -release:
> > We may use some new APIs of higher Java versions in our code.
> > As long as we check the Java version at runtime and ensure that the
> > code path is not executed
> > when running on a lower version of Java, this is also reasonable.
> >
> This reads like you want to compile to --release 8 but have static
> references in version 52 class files to APIs that were added in Java 9+,
> is that right? This may be a setup for a world of hurt and maybe you
> should explore Multi-Release JAR files for this.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230104/b0f79f98/attachment-0001.htm>

From alanb at openjdk.org  Tue Jan  3 17:53:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jan 2023 17:53:54 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR
In-Reply-To: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
Message-ID: <a4K8xNw7iJH8MXwUmE7Qf4kfZMcLxMkfoXClXPeQvmY=.aeb1a9cc-809b-4623-a54c-e9be8c6aedf7@github.com>

On Tue, 3 Jan 2023 17:40:42 GMT, Justin Lu <duke at openjdk.org> wrote:

> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
> 
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
> 
> Swapping the outdated to **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

You will need to remove the test from test/jdk/ProblemList.txt to get it to run again.

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

PR: https://git.openjdk.org/jdk/pull/11833

From naoto at openjdk.org  Tue Jan  3 17:56:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jan 2023 17:56:53 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR
In-Reply-To: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
Message-ID: <ymDnQPXFxLcYKYrL481H1o6Aub4NMoH9N8L53c-yhV4=.48d17bd5-7c13-4fe6-b546-73838589e90d@github.com>

On Tue, 3 Jan 2023 17:40:42 GMT, Justin Lu <duke at openjdk.org> wrote:

> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
> 
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
> 
> Swapping the outdated to **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

You could also clean-up older entries that use transition format, i.e., `lt_LT` and `lv_LV`.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 82:

> 80: hi_IN=\u0930\u0942
> 81: hr=\u00A4
> 82: hr_HR=EUR

Since this is a table for currency symbols, it has to be EURO SIGN ('\u20AC')

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

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11833

From erikj at openjdk.org  Tue Jan  3 18:21:48 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 3 Jan 2023 18:21:48 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests
In-Reply-To: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
Message-ID: <AO4K00V_r-yB6Gr7cfxZGo3C1T0c0ZafaUHSft66gus=.c933b46a-3dbd-4a91-8d0a-b42a91280645@github.com>

On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
> 
> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
> 
> Motivational improvements:
> 
> 
> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
> 
> # Default JDK tree
> 
> # Baseline
> real	0m9.086s
> user	0m22.857s
> sys	0m4.202s
> 
> # Patched
> real	0m6.406s   ; +40% faster
> user	0m17.156s
> sys	0m3.193s
> 
> # +100K fuzzer tests in tree
> 
> # Baseline
> real	3m1.997s
> user	3m16.643s
> sys	0m10.490s
> 
> # Patched
> real	0m8.919s   ; 20x faster
> user	0m17.904s
> sys	0m4.860s
> 
> 
> Additional testing:
>  - [x] Ad-hoc timing tests (see above)
>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1

Looks good from a build point of view.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11824

From sspitsyn at openjdk.org  Tue Jan  3 18:51:08 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Jan 2023 18:51:08 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
Message-ID: <L8bj_wSEjkPsEVxsP3BA-rTrlx7oTxetTV_2pC68ICU=.e6c64614-0070-480d-8869-863e8206627a@github.com>

On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge ../jdk-openjdk into typos-typos
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10029

From sspitsyn at openjdk.org  Tue Jan  3 19:12:01 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Jan 2023 19:12:01 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
Message-ID: <yq1CnPtdWe39EHluasKMPxTxWHAvG1d_ZAgTEoANfYo=.2f2e55e0-4d26-4c9c-b1ce-75ac154cf23b@github.com>

On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge ../jdk-openjdk into typos-typos
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Michael, I've reviewed the changes but the [JDK-8294321](https://bugs.openjdk.org/browse/JDK-8294321) seems to be already resolved. So, what JBS issue are you actually trying to fix?

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

PR: https://git.openjdk.org/jdk/pull/10029

From smarks at openjdk.org  Tue Jan  3 19:35:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 3 Jan 2023 19:35:50 GMT
Subject: RFR: 8189338: JMX RMI Remote Mbean server connection hangs if the
 server stops responding during a SSL Handshake
In-Reply-To: <lvbRFcpv6IQXtjPCtR6qdIFeCCIbinaY3dBfWx_MrXM=.643b5a49-1767-4fdc-91e2-5b6eee79a4be@github.com>
References: <lvbRFcpv6IQXtjPCtR6qdIFeCCIbinaY3dBfWx_MrXM=.643b5a49-1767-4fdc-91e2-5b6eee79a4be@github.com>
Message-ID: <n7MT5W43w3NaR5MX2rLwUra0lroJsPGu3ik8LEGwYsI=.db7b2682-4fb5-4209-8d4e-c7ac17c66b50@github.com>

On Tue, 3 Jan 2023 13:35:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch introduces a time limit for establishing a secure connection to a RMI server.
> 
> The existing implementation uses the configured `sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; there's no time limit for SSL handshake.
> With this patch, the configuration option `sun.rmi.transport.tcp.handshakeTimeout` is also used as a socket read timeout during the SSL handshake.
> 
> I modified the existing `HandshakeTimeout` test to verify both non-SSL and SSL connections; the test passes with my changes, fails without them.
> 
> Existing tier1-3 tests continue to pass.
> 
> While working on the patch I noticed that `conn.isReusable()` always returns true. I can remove all references to `isReusable` here or in another PR; it would simplify the code a bit.

Thanks for taking this long-standing bug. Changes look good.

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

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11829

From duke at openjdk.org  Tue Jan  3 20:14:30 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 3 Jan 2023 20:14:30 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v2]
In-Reply-To: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
Message-ID: <BmQoH6Jbfp9foIEbbPmXJ4wR_Pg54exuBb4J-zy56wk=.df36cafc-a3da-4a20-bcfd-fb8757e63721@github.com>

> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
> 
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
> 
> Swapping the outdated to **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

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

  Remove from list, fix symbol

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11833/files
  - new: https://git.openjdk.org/jdk/pull/11833/files/0ada2060..0934f837

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11833&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11833&range=00-01

  Stats: 6 lines in 3 files changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11833.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11833/head:pull/11833

PR: https://git.openjdk.org/jdk/pull/11833

From duke at openjdk.org  Tue Jan  3 20:14:30 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 3 Jan 2023 20:14:30 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v2]
In-Reply-To: <ymDnQPXFxLcYKYrL481H1o6Aub4NMoH9N8L53c-yhV4=.48d17bd5-7c13-4fe6-b546-73838589e90d@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
 <ymDnQPXFxLcYKYrL481H1o6Aub4NMoH9N8L53c-yhV4=.48d17bd5-7c13-4fe6-b546-73838589e90d@github.com>
Message-ID: <X2yekoT8sM9FCtU-xiNCiOwQAbSHalxfJmAUEWz-ekw=.57e056b0-1730-4210-92d7-94afdfebffad@github.com>

On Tue, 3 Jan 2023 17:51:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove from list, fix symbol
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 82:
> 
>> 80: hi_IN=\u0930\u0942
>> 81: hr=\u00A4
>> 82: hr_HR=EUR
> 
> Since this is a table for currency symbols, it has to be EURO SIGN ('\u20AC')

Made those changes, thank you

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

PR: https://git.openjdk.org/jdk/pull/11833

From lancea at openjdk.org  Tue Jan  3 20:25:52 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 3 Jan 2023 20:25:52 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v2]
In-Reply-To: <BmQoH6Jbfp9foIEbbPmXJ4wR_Pg54exuBb4J-zy56wk=.df36cafc-a3da-4a20-bcfd-fb8757e63721@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
 <BmQoH6Jbfp9foIEbbPmXJ4wR_Pg54exuBb4J-zy56wk=.df36cafc-a3da-4a20-bcfd-fb8757e63721@github.com>
Message-ID: <8rqhJZeH3p7loHqz4C1XZEo1luuxPgdm0AIa4fuMljE=.a4ad6253-091b-4c5e-b1fa-d5df52398229@github.com>

On Tue, 3 Jan 2023 20:14:30 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
>> 
>> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
>> 
>> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove from list, fix symbol

Looks OK to me

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11833

From naoto at openjdk.org  Tue Jan  3 20:47:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jan 2023 20:47:50 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v2]
In-Reply-To: <BmQoH6Jbfp9foIEbbPmXJ4wR_Pg54exuBb4J-zy56wk=.df36cafc-a3da-4a20-bcfd-fb8757e63721@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
 <BmQoH6Jbfp9foIEbbPmXJ4wR_Pg54exuBb4J-zy56wk=.df36cafc-a3da-4a20-bcfd-fb8757e63721@github.com>
Message-ID: <AbA98b6uRhnwlJVdeMlaHP7WrmCjp8QqdxvHKHrzLks=.ab52ffb9-85f6-433f-9c74-4180f47b8077@github.com>

On Tue, 3 Jan 2023 20:14:30 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
>> 
>> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
>> 
>> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove from list, fix symbol

Marked as reviewed by naoto (Reviewer).

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties line 38:

> 36: # Taligent is a registered trademark of Taligent, Inc.
> 37: 
> 38: EUR=\u20AC

Good catch!

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

PR: https://git.openjdk.org/jdk/pull/11833

From dholmes at openjdk.org  Tue Jan  3 21:25:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jan 2023 21:25:28 GMT
Subject: [jdk20] Integrated: 8299483: ProblemList
 java/text/Format/NumberFormat/CurrencyFormat.java
Message-ID: <cg7lGK4ga_mecf79b6vVeFaSmgkmHHDFokNLF7ikz3M=.565c8ec9-e0e6-4257-a99d-70307926e4cf@github.com>

Hi all,

This pull request contains a backport of commit [5b5552ff](https://github.com/openjdk/jdk/commit/5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by David Holmes on 2 Jan 2023 and was reviewed by Lance Andersen.

Thanks!

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

Commit messages:
 - Backport 5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8

Changes: https://git.openjdk.org/jdk20/pull/81/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299483
  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/81/head:pull/81

PR: https://git.openjdk.org/jdk20/pull/81

From dholmes at openjdk.org  Tue Jan  3 21:25:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jan 2023 21:25:28 GMT
Subject: [jdk20] Integrated: 8299483: ProblemList
 java/text/Format/NumberFormat/CurrencyFormat.java
In-Reply-To: <cg7lGK4ga_mecf79b6vVeFaSmgkmHHDFokNLF7ikz3M=.565c8ec9-e0e6-4257-a99d-70307926e4cf@github.com>
References: <cg7lGK4ga_mecf79b6vVeFaSmgkmHHDFokNLF7ikz3M=.565c8ec9-e0e6-4257-a99d-70307926e4cf@github.com>
Message-ID: <_xcVrmnnEueItdda0AEIbHlflXZVwvqcnvo4bDa6uUY=.bb7994ef-1920-4d63-84f0-0ce51d58f7e5@github.com>

On Tue, 3 Jan 2023 21:12:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [5b5552ff](https://github.com/openjdk/jdk/commit/5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 2 Jan 2023 and was reviewed by Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 8254cbb2
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/8254cbb21d164f39aa12020bfbd555d7535a428e
Stats:     3 lines in 1 file changed: 2 ins; 1 del; 0 mod

8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java

Backport-of: 5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8

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

PR: https://git.openjdk.org/jdk20/pull/81

From cjplummer at openjdk.org  Tue Jan  3 21:58:49 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Jan 2023 21:58:49 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <yq1CnPtdWe39EHluasKMPxTxWHAvG1d_ZAgTEoANfYo=.2f2e55e0-4d26-4c9c-b1ce-75ac154cf23b@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
 <yq1CnPtdWe39EHluasKMPxTxWHAvG1d_ZAgTEoANfYo=.2f2e55e0-4d26-4c9c-b1ce-75ac154cf23b@github.com>
Message-ID: <s4pO56HbE3QN97zXqMOABnqWU6pIseK8xRxnNsX_Ekk=.2590315f-d6fd-4da3-a98c-e2b43e04762d@github.com>

On Tue, 3 Jan 2023 19:08:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Michael, I've reviewed the changes but the [JDK-8294321](https://bugs.openjdk.org/browse/JDK-8294321) seems to be already resolved. So, what JBS issue are you actually trying to fix?

It's closed because #11385 used it to fix some of the typos. #11385 should have used a new issue, but now instead a new issue is needed for the remaining typos.

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

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Tue Jan  3 23:11:28 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 3 Jan 2023 23:11:28 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v3]
In-Reply-To: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
Message-ID: <__H0WPRhVNyv3FKRre4T07IDvun3W9tMCPsr9lCobSU=.7811ee8f-393f-43ee-9ef4-456456a6b26f@github.com>

> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
> 
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
> 
> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

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

  Update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11833/files
  - new: https://git.openjdk.org/jdk/pull/11833/files/0934f837..d0d075c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11833&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11833&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/11833

From naoto at openjdk.org  Tue Jan  3 23:11:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jan 2023 23:11:29 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v3]
In-Reply-To: <__H0WPRhVNyv3FKRre4T07IDvun3W9tMCPsr9lCobSU=.7811ee8f-393f-43ee-9ef4-456456a6b26f@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
 <__H0WPRhVNyv3FKRre4T07IDvun3W9tMCPsr9lCobSU=.7811ee8f-393f-43ee-9ef4-456456a6b26f@github.com>
Message-ID: <LXtHxtq1aRUtP8AU8NGXYZnF6McF_nddpbEGTpskHdw=.590d0dff-bc3b-4912-b93e-02ab0c5c1e50@github.com>

On Tue, 3 Jan 2023 23:06:35 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
>> 
>> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
>> 
>> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11833

From jpai at openjdk.org  Wed Jan  4 01:22:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 01:22:57 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
Message-ID: <L4tOcragEbgUkIEf-vIwfijCW4Tzf9erpuY3hcDqhQE=.e0bf33b3-3202-4d98-8f5a-01113cd35d1e@github.com>

On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge ../jdk-openjdk into typos-typos
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Hell Michael, I've created https://bugs.openjdk.org/browse/JDK-8299563 to track this final few typos. Could you please update the title of this PR to `8299563: Fix typos`? That should then allow you to proceed using this PR. Please also merge with latest master branch once more since some typo fixes from this PR have been merged recently. Thank you for your patience.

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

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Wed Jan  4 01:23:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 01:23:01 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>
Message-ID: <sEw6ghbN_4a35eHtmR8cYDP6G6FcmS4wuxfpQd6uOZc=.673eed6f-082e-45f0-8b6f-8d13b7ecfb1c@github.com>

On Wed, 5 Oct 2022 13:22:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:
> 
>> 179:         if [ $? -eq 0 ]
>> 180:         then
>> 181:             # it's still lingering, now it is hard
> 
> Suggestion:
> 
>             # it's still lingering, now hit it hard

@mernst, this suggestion appears relevant. Could you update the PR to address this?

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

PR: https://git.openjdk.org/jdk/pull/10029

From jpai at openjdk.org  Wed Jan  4 01:26:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 01:26:57 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>
Message-ID: <QTfS_-VusakHtKnLSG1D-wm9_pXC26diTtbu9D5t_oY=.a7bc9bf3-47bd-4005-a555-dd42b296f448@github.com>

On Wed, 5 Oct 2022 13:06:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> src/java.xml/share/classes/org/w3c/dom/Document.java line 293:
> 
>> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
>> 292:      * copied. If a <code>deep</code> import is requested, the descendants
>> 293:      * of the source <code>Entity</code> are recursively imported and
> 
> This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

@mernst, could you undo this change to this file from this PR? It does indeed seem to come from a 3rd party source. @JoeWang-Java can correct us if that's not the case.

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

PR: https://git.openjdk.org/jdk/pull/10029

From dholmes at openjdk.org  Wed Jan  4 01:27:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jan 2023 01:27:49 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests
In-Reply-To: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
Message-ID: <a-fzCYUMTCQoHQrvWttyn5A0QDKZ4rnQ--Bjn40XDh8=.5f1bcaea-05de-477b-a3fe-a2503eddf085@github.com>

On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
> 
> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
> 
> Motivational improvements:
> 
> 
> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
> 
> # Default JDK tree
> 
> # Baseline
> real	0m9.086s
> user	0m22.857s
> sys	0m4.202s
> 
> # Patched
> real	0m6.406s   ; +40% faster
> user	0m17.156s
> sys	0m3.193s
> 
> # +100K fuzzer tests in tree
> 
> # Baseline
> real	3m1.997s
> user	3m16.643s
> sys	0m10.490s
> 
> # Patched
> real	0m8.919s   ; 20x faster
> user	0m17.904s
> sys	0m4.860s
> 
> 
> Additional testing:
>  - [x] Ad-hoc timing tests (see above)
>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1

This seems fine to me. Thanks.

I personally always run with `-noreport`. :)

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11824

From jpai at openjdk.org  Wed Jan  4 01:31:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 01:31:49 GMT
Subject: RFR: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR [v3]
In-Reply-To: <__H0WPRhVNyv3FKRre4T07IDvun3W9tMCPsr9lCobSU=.7811ee8f-393f-43ee-9ef4-456456a6b26f@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
 <__H0WPRhVNyv3FKRre4T07IDvun3W9tMCPsr9lCobSU=.7811ee8f-393f-43ee-9ef4-456456a6b26f@github.com>
Message-ID: <UFW-zUmDEW2XxKep8QTpknDQMFsVUUvNpZzhh7TZm6g=.63472593-5b17-49aa-a1f1-c98baf0c2a28@github.com>

On Tue, 3 Jan 2023 23:11:28 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
>> 
>> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
>> 
>> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11833

From jpai at openjdk.org  Wed Jan  4 01:43:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 01:43:48 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests
In-Reply-To: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
Message-ID: <RHvszxYZLAuyXPzTZooWAH8X8kjI91MRZX6nW9v5DnU=.edb70203-6ac8-4b96-a0ee-55dc8a3721c6@github.com>

On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
> 
> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
> 
> Motivational improvements:
> 
> 
> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
> 
> # Default JDK tree
> 
> # Baseline
> real	0m9.086s
> user	0m22.857s
> sys	0m4.202s
> 
> # Patched
> real	0m6.406s   ; +40% faster
> user	0m17.156s
> sys	0m3.193s
> 
> # +100K fuzzer tests in tree
> 
> # Baseline
> real	3m1.997s
> user	3m16.643s
> sys	0m10.490s
> 
> # Patched
> real	0m8.919s   ; 20x faster
> user	0m17.904s
> sys	0m4.860s
> 
> 
> Additional testing:
>  - [x] Ad-hoc timing tests (see above)
>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1

Hello Aleksey, this looks good to me. Good to see the timing improvements on `make test`.

Please update the copyright years on the files before integrating.

I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation?

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11824

From pminborg at openjdk.org  Wed Jan  4 08:56:40 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 08:56:40 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access
Message-ID: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>

Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 

Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 

Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.

Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

Commit messages:
 - Update copyright year to 2023
 - Update copyright year
 - Reimplement java.io.Bits using VarHandle access

Changes: https://git.openjdk.org/jdk/pull/11840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299576
  Stats: 463 lines in 2 files changed: 424 ins; 24 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 09:01:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 09:01:06 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

  Update copyright year in test class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/9b5af054..13af8b6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 09:01:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 09:01:08 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <ECrhDp1x4tUCyDkVnkCENNHOWO9BCkpwhxdXMisVZkY=.7eaa26ff-4ead-4671-a93e-c75ac42260b3@github.com>

On Wed, 4 Jan 2023 08:48:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

Is there a better way to test packet-private methods in Bits without resorting to reflection?

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

PR: https://git.openjdk.org/jdk/pull/11840

From alanb at openjdk.org  Wed Jan  4 09:10:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jan 2023 09:10:50 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access
In-Reply-To: <ECrhDp1x4tUCyDkVnkCENNHOWO9BCkpwhxdXMisVZkY=.7eaa26ff-4ead-4671-a93e-c75ac42260b3@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <ECrhDp1x4tUCyDkVnkCENNHOWO9BCkpwhxdXMisVZkY=.7eaa26ff-4ead-4671-a93e-c75ac42260b3@github.com>
Message-ID: <l90Q3lirI2oJZolLrnpuV4lgRyGiEiUPMbw5q68_000=.3b481312-c45b-4eee-8218-30e8bbcd5e80@github.com>

On Wed, 4 Jan 2023 08:57:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Is there a better way to test packet-private methods in Bits without resorting to reflection?

Yes, looking for directories named java.base in the test tree and you'll see test classes that are compiled into java.base/java.net, java.base/java.lang.invoke and other packages so they can be used to test package private methods. When you look at the tests you'll see there are a couple of approaches used. Some tests are in the same runtime package, others add a public class with public methods into the runtime package that the test can use.

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

PR: https://git.openjdk.org/jdk/pull/11840

From shade at openjdk.org  Wed Jan  4 09:15:18 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jan 2023 09:15:18 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
Message-ID: <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>

> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
> 
> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
> 
> Motivational improvements:
> 
> 
> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
> 
> # Default JDK tree
> 
> # Baseline
> real	0m9.086s
> user	0m22.857s
> sys	0m4.202s
> 
> # Patched
> real	0m6.406s   ; +40% faster
> user	0m17.156s
> sys	0m3.193s
> 
> # +100K fuzzer tests in tree
> 
> # Baseline
> real	3m1.997s
> user	3m16.643s
> sys	0m10.490s
> 
> # Patched
> real	0m8.919s   ; 20x faster
> user	0m17.904s
> sys	0m4.860s
> 
> 
> Additional testing:
>  - [x] Ad-hoc timing tests (see above)
>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1

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

  Copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11824/files
  - new: https://git.openjdk.org/jdk/pull/11824/files/a803958f..a82ac6cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11824&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11824&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11824

From shade at openjdk.org  Wed Jan  4 09:15:18 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jan 2023 09:15:18 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <RHvszxYZLAuyXPzTZooWAH8X8kjI91MRZX6nW9v5DnU=.edb70203-6ac8-4b96-a0ee-55dc8a3721c6@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
 <RHvszxYZLAuyXPzTZooWAH8X8kjI91MRZX6nW9v5DnU=.edb70203-6ac8-4b96-a0ee-55dc8a3721c6@github.com>
Message-ID: <m2lUdRPmfOYTRDX4uwf_xRTWJE8jxzOt2Sxt1_PVFZY=.5445949e-b0c9-4fcd-a282-8c3a5eb6f7cb@github.com>

On Wed, 4 Jan 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Please update the copyright years on the files before integrating.

Updated.

> I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation?

The logic for REPEAT/RETRY_COUNT merges the jtreg reports from "different" repeated runs. We have to check new reporting mode still produces sane results in that mode.

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

PR: https://git.openjdk.org/jdk/pull/11824

From jpai at openjdk.org  Wed Jan  4 09:25:55 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 09:25:55 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
 <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
Message-ID: <uliLtAL-eRAFiB6SstSDocjGPvm4AKM4jVHdAI9W0_k=.677a2388-6355-490e-a7e2-662508d234a0@github.com>

On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
>> 
>> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
>> 
>> Motivational improvements:
>> 
>> 
>> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
>> 
>> # Default JDK tree
>> 
>> # Baseline
>> real	0m9.086s
>> user	0m22.857s
>> sys	0m4.202s
>> 
>> # Patched
>> real	0m6.406s   ; +40% faster
>> user	0m17.156s
>> sys	0m3.193s
>> 
>> # +100K fuzzer tests in tree
>> 
>> # Baseline
>> real	3m1.997s
>> user	3m16.643s
>> sys	0m10.490s
>> 
>> # Patched
>> real	0m8.919s   ; 20x faster
>> user	0m17.904s
>> sys	0m4.860s
>> 
>> 
>> Additional testing:
>>  - [x] Ad-hoc timing tests (see above)
>>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11824

From jpai at openjdk.org  Wed Jan  4 09:25:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 09:25:56 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <m2lUdRPmfOYTRDX4uwf_xRTWJE8jxzOt2Sxt1_PVFZY=.5445949e-b0c9-4fcd-a282-8c3a5eb6f7cb@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
 <RHvszxYZLAuyXPzTZooWAH8X8kjI91MRZX6nW9v5DnU=.edb70203-6ac8-4b96-a0ee-55dc8a3721c6@github.com>
 <m2lUdRPmfOYTRDX4uwf_xRTWJE8jxzOt2Sxt1_PVFZY=.5445949e-b0c9-4fcd-a282-8c3a5eb6f7cb@github.com>
Message-ID: <Dm4YytcYyAiZFKf-jbAJNwVbZRDDuna7HfH-I5NRPu0=.5d5a0183-a84a-4c19-a8ee-f78b794f8c55@github.com>

On Wed, 4 Jan 2023 09:10:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation?
> 
> The logic for REPEAT/RETRY_COUNT merges the jtreg reports from "different" repeated runs. We have to check new reporting mode still produces sane results in that mode.

Thank you for that detail, I wasn't aware of that.

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

PR: https://git.openjdk.org/jdk/pull/11824

From uschindler at openjdk.org  Wed Jan  4 09:28:48 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 09:28:48 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
Message-ID: <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>

On Wed, 4 Jan 2023 09:01:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in test class

Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?

Otherwise: PR looks good.

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

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 09:31:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 09:31:51 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
Message-ID: <PIcIc6UvmjkXLMqrcczr7CXWw6toyLICr5-TfGmSOTw=.1e13c9a1-edfa-4e9b-9485-e73f55fa8bb4@github.com>

On Wed, 4 Jan 2023 09:01:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year in test class

Here is an update performance comparison for Linux x64:

![image](https://user-images.githubusercontent.com/7457876/210524557-cf9dbb6e-8885-484d-ae52-347b8388ef40.png)

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

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 10:51:50 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 10:51:50 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
Message-ID: <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>

On Wed, 4 Jan 2023 09:25:40 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?
> 
> Otherwise: PR looks good.

There are overlaps of the RAF and Bits tests but the latter tests additional aspects such as unaligned access and edge cases with exceptions. So, I think we should keep the proposed tests.

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

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 10:49:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 10:49:24 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v3]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <K3X9jIBf8IrWV8JCKVwzgLT4RHBTkLF8lcGqYJibkwA=.e55db7fd-db27-46ad-aa52-a37cb7529476@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

 - Improve test
 - Improve test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/13af8b6c..3a91f3e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=01-02

  Stats: 285 lines in 2 files changed: 113 ins; 127 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From mcimadamore at openjdk.org  Wed Jan  4 10:57:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Jan 2023 10:57:43 GMT
Subject: [jdk20] RFR: 8299561: VaList.empty() doesn't return a list associated
 with the global scope
Message-ID: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>

This patch fixes a long-standing conformance issue: `VaList.empty` is specified to return a `VaList` associated with the global scope, but in some platforms (Aarch64/Linux and x64/Linux) the empty list is associated with an implicit scope instead.

This doesn't make a lot of difference, given that the empty list is always stored in a static final in the underlying implementation - that said, it would be a good thing to rectify this conformance issue.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk20/pull/82/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299561
  Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/82/head:pull/82

PR: https://git.openjdk.org/jdk20/pull/82

From mcimadamore at openjdk.org  Wed Jan  4 10:57:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Jan 2023 10:57:44 GMT
Subject: [jdk20] RFR: 8299561: VaList.empty() doesn't return a list
 associated with the global scope
In-Reply-To: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
References: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
Message-ID: <13fnBOcypryKZfqAY1eJbtZRyph87K9Ai5gBNY0uPsU=.31ca2a6a-0511-491f-af60-a0939b765652@github.com>

On Wed, 4 Jan 2023 10:49:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a long-standing conformance issue: `VaList.empty` is specified to return a `VaList` associated with the global scope, but in some platforms (Aarch64/Linux and x64/Linux) the empty list is associated with an implicit scope instead.
> 
> This doesn't make a lot of difference, given that the empty list is always stored in a static final in the underlying implementation - that said, it would be a good thing to rectify this conformance issue.

Note: on Windows/x64 and MacOS/Aarch64 the empty VaList is just a wrapper around MemorySegment.NULL which is already associated with the global scope - so nothing to fix there.

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

PR: https://git.openjdk.org/jdk20/pull/82

From fjiang at openjdk.org  Wed Jan  4 11:17:51 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 4 Jan 2023 11:17:51 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API
 (Preview)
Message-ID: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>

Add experimental Foreign Function & Memory API support for RISC-V.

Details of FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)

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

Commit messages:
 - sync with JDK-8296477
 - sync with JDK-8295044
 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview)

Changes: https://git.openjdk.org/jdk/pull/11004/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293841
  Stats: 2861 lines in 64 files changed: 2736 ins; 2 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From jdk at fiolino.de  Wed Jan  4 11:19:15 2023
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Wed, 4 Jan 2023 12:19:15 +0100
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <2e29a269-ac13-240e-6fe9-b344ede6fa49@fiolino.de>

On 1/4/23 09:56, Per Minborg wrote:
> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code.

Hmh, Javadoc for MethodHandels::byteArrayViewVarHandle says the following:

  * read write access modes for all T, with the exception of access 
modes get and set for long and double on 32-bit platforms.

Are you sure that your change will work correctly on a 32-bit platform? 
 From what I read, it could throw an IllegalStateException when a long 
value is read/written.

-Michael

> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too.
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
> 
> -------------
> 
> Commit messages:
>   - Update copyright year to 2023
>   - Update copyright year
>   - Reimplement java.io.Bits using VarHandle access
> 
> Changes: https://git.openjdk.org/jdk/pull/11840/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8299576
>    Stats: 463 lines in 2 files changed: 424 ins; 24 del; 15 mod
>    Patch: https://git.openjdk.org/jdk/pull/11840.diff
>    Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840
> 
> PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Wed Jan  4 11:21:49 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Wed, 4 Jan 2023 11:21:49 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
Message-ID: <t902jg7pvMa7_Wz3QWb115jyezY1pEIPZiOvwqwnOXs=.62db7d3d-aebe-4592-b7a4-4046d4544d2d@github.com>

On Wed, 4 Jan 2023 10:49:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?
>> 
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?
>> 
>> Otherwise: PR looks good.
> 
> There are overlaps of the RAF and Bits tests but the latter tests additional aspects such as unaligned access and edge cases with exceptions. So, I think we should keep the proposed tests.

@minborg Amazing piece!

Will `java.lang.invoke.VarHandle` instances be shared in JDK to reuse in other places? 

The [jsoniter-scala-coreJVM](https://github.com/plokhotnyuk/jsoniter-scala/tree/master/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core) module of the [jsoniter-scala](https://github.com/plokhotnyuk/jsoniter-scala) project has a lot of SWAR tricks that use `java.lang.invoke.VarHandle` to speed up parsing/serialization of primitives, `java.math.BigDecimal`, and `java.time.*` classes from/to textual representation.

Are you interested to port some of them to JDK as it was done for `java.util.UUID` parsing [here](https://github.com/openjdk/jdk/commit/ebadfaeb2e1cc7b5ce5f101cd8a539bc5478cf5b)?

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Wed Jan  4 11:32:52 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 11:32:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v3]
In-Reply-To: <K3X9jIBf8IrWV8JCKVwzgLT4RHBTkLF8lcGqYJibkwA=.e55db7fd-db27-46ad-aa52-a37cb7529476@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <K3X9jIBf8IrWV8JCKVwzgLT4RHBTkLF8lcGqYJibkwA=.e55db7fd-db27-46ad-aa52-a37cb7529476@github.com>
Message-ID: <igiJawfbT1zhZFnMecyubSZ67TY_kBQR2LtblFnDUVU=.6d24d997-b0da-46ef-b9e4-582eb00c5dc1@github.com>

On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test
>  - Improve test

There *may* be one problem: For float and double the original code uses `Double#doubleToLongBits()` (same for float), which normalized NaN. I am not sure how the Varhandle behaves with that. Reading float/double is not a problem.

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Wed Jan  4 11:38:49 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 11:38:49 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v3]
In-Reply-To: <K3X9jIBf8IrWV8JCKVwzgLT4RHBTkLF8lcGqYJibkwA=.e55db7fd-db27-46ad-aa52-a37cb7529476@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <K3X9jIBf8IrWV8JCKVwzgLT4RHBTkLF8lcGqYJibkwA=.e55db7fd-db27-46ad-aa52-a37cb7529476@github.com>
Message-ID: <32ByhPnRMBFDG6zDS0rAt1-Jxd-VZUe-mRl2Dq1B5so=.3bd6e1ae-9752-48c4-a46d-e11e400f64df@github.com>

On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test
>  - Improve test

To be safe, we could go first with the int/long varhandles and convert as before.

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

PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Wed Jan  4 12:02:49 2023
From: duke at openjdk.org (Markus KARG)
Date: Wed, 4 Jan 2023 12:02:49 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <9CAPsBZe7mzrbtDkk8hlZBvEp9F4QjKYjZv0w19N7v8=.71a6174a-e9e5-4380-8455-ce9652fbb75f@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

Thank you for not rejecting my proposal. Indeed the starting point for this PR was the surprising experience with several existing applications that were using custom transfer loops with larger buffers being to be considerably faster than `transferTo` (Maven being one of them just to name some). Can I convince you to mark this PR as reviewed? Thanks! :-)

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

PR: https://git.openjdk.org/jdk/pull/11783

From pminborg at openjdk.org  Wed Jan  4 12:20:28 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 12:20:28 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v4]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <xWfrycTHvSf0o6wg3HgoxNaHifiotQuu4s4jSwIvMCg=.1bf1edc9-ec7f-438f-89d7-b6d1f8f39df6@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

  Add special test values for double and float

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/3a91f3e2..e1f95d83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=02-03

  Stats: 27 lines in 1 file changed: 22 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Wed Jan  4 12:43:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 12:43:48 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
Message-ID: <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>

On Wed, 4 Jan 2023 10:49:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?
>> 
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested to extense through RandomAccessFile? We had no test before, so why add a new one here?
>> 
>> Otherwise: PR looks good.
> 
> There are overlaps of the RAF and Bits tests but the latter tests additional aspects such as unaligned access and edge cases with exceptions. So, I think we should keep the proposed tests.

> @minborg Amazing piece!
> 
> Will `java.lang.invoke.VarHandle` instances be shared in JDK to reuse in other places?
> 
> The [jsoniter-scala-coreJVM](https://github.com/plokhotnyuk/jsoniter-scala/tree/master/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core) module of the [jsoniter-scala](https://github.com/plokhotnyuk/jsoniter-scala) project has a lot of SWAR tricks that use `java.lang.invoke.VarHandle` to speed up parsing/serialization of primitives, `java.math.BigDecimal`, and `java.time.*` classes from/to textual representation.
> 
> Are you interested to port some of them to JDK as it was done for `java.util.UUID` parsing [here](https://github.com/openjdk/jdk/commit/ebadfaeb2e1cc7b5ce5f101cd8a539bc5478cf5b)?

Thanks. I think instances will be private to this class and other have to be created elsewhere if needed. 

Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Wed Jan  4 12:55:52 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 12:55:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v4]
In-Reply-To: <xWfrycTHvSf0o6wg3HgoxNaHifiotQuu4s4jSwIvMCg=.1bf1edc9-ec7f-438f-89d7-b6d1f8f39df6@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <xWfrycTHvSf0o6wg3HgoxNaHifiotQuu4s4jSwIvMCg=.1bf1edc9-ec7f-438f-89d7-b6d1f8f39df6@github.com>
Message-ID: <0OsmU1qnzX2pd5GGAZtNzEuawV_74ocKzbWuMHTYvFE=.81834f2e-5515-4bee-965e-024f8aa2c0a7@github.com>

On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add special test values for double and float

Hi,
i checked you new test, but this one does not help with the problem of `Double#doubleToLongBits()` (as defined in the spec of `RandomAccessFile`!) vs the VarHandle, which just puts the raw bits without normalization (see javadocs). Your test only checks with the canonic NaN, which should already be "normalized" so it round trips. Basically it has to be made sure, that `Bits` save any variant of double NaN as `0x7ff8000000000000L` (similar for float).

My suggestion is the following. It is unsymmetric, but "correct" accoring to spec:
- the read methods are perfectly fine, so they directly read the double/float through its corres?ponding varhandle.
- the write method should be reverted to the original version before the patch (they used floatBitsToInt/doubleBitsToLong and delegated to the putLong/putInt - which now uses varhandle). This makes sure that we convert the double/float to its normalized form and then write it as a long.

We may add a test to check if the NaN produced by several division operations produce the normalized value in the byte array. Iam not sure what the best way to get de-normalized NaNs. Maybe theres a test around.

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Wed Jan  4 12:58:51 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 12:58:51 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v4]
In-Reply-To: <xWfrycTHvSf0o6wg3HgoxNaHifiotQuu4s4jSwIvMCg=.1bf1edc9-ec7f-438f-89d7-b6d1f8f39df6@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <xWfrycTHvSf0o6wg3HgoxNaHifiotQuu4s4jSwIvMCg=.1bf1edc9-ec7f-438f-89d7-b6d1f8f39df6@github.com>
Message-ID: <yxopcWnThbABZZKBv5igUMWe-z98KHZ-W-4Ij_JVv18=.480ec180-5edb-49eb-aabd-9285cf0a381f@github.com>

On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add special test values for double and float

Mybe ask somebody from the "double/float/IEEE specialists" around here!

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

PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Wed Jan  4 13:18:49 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Wed, 4 Jan 2023 13:18:49 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
Message-ID: <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>

On Wed, 4 Jan 2023 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > @minborg Amazing piece!
> > Will `java.lang.invoke.VarHandle` instances be shared in JDK to reuse in other places?
> > The [jsoniter-scala-coreJVM](https://github.com/plokhotnyuk/jsoniter-scala/tree/master/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core) module of the [jsoniter-scala](https://github.com/plokhotnyuk/jsoniter-scala) project has a lot of SWAR tricks that use `java.lang.invoke.VarHandle` to speed up parsing/serialization of primitives, `java.math.BigDecimal`, and `java.time.*` classes from/to textual representation.
> > Are you interested to port some of them to JDK as it was done for `java.util.UUID` parsing [here](https://github.com/openjdk/jdk/commit/ebadfaeb2e1cc7b5ce5f101cd8a539bc5478cf5b)?
> 
> Thanks. I think instances will be private to this class and other have to be created elsewhere if needed.
> 
> Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?

Basically, places for improvements are `parse(String s)` and `toString` methods of classes mentioned above.

When parsing from `String` we can access the internal array of bytes, and for serialization we can create `String` instances from byte arrays without copying using some a kind of `Unsafe` access for both.

Please open [`JsonReader`](https://github.com/plokhotnyuk/jsoniter-scala/blob/master/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala) and [`JsonWriter`](https://github.com/plokhotnyuk/jsoniter-scala/blob/master/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala) sources and skim through `ByteArrayAccess` usages there.

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

PR: https://git.openjdk.org/jdk/pull/11840

From djelinski at openjdk.org  Wed Jan  4 13:20:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 4 Jan 2023 13:20:55 GMT
Subject: Integrated: 8189338: JMX RMI Remote Mbean server connection hangs if
 the server stops responding during a SSL Handshake
In-Reply-To: <lvbRFcpv6IQXtjPCtR6qdIFeCCIbinaY3dBfWx_MrXM=.643b5a49-1767-4fdc-91e2-5b6eee79a4be@github.com>
References: <lvbRFcpv6IQXtjPCtR6qdIFeCCIbinaY3dBfWx_MrXM=.643b5a49-1767-4fdc-91e2-5b6eee79a4be@github.com>
Message-ID: <dVgzPp44Yefq1We7EgGaDTxmTxF1dDkuEITExBRWDmc=.fb291008-fb0e-4ffe-a412-1025515f3cc8@github.com>

On Tue, 3 Jan 2023 13:35:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch introduces a time limit for establishing a secure connection to a RMI server.
> 
> The existing implementation uses the configured `sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; there's no time limit for SSL handshake.
> With this patch, the configuration option `sun.rmi.transport.tcp.handshakeTimeout` is also used as a socket read timeout during the SSL handshake.
> 
> I modified the existing `HandshakeTimeout` test to verify both non-SSL and SSL connections; the test passes with my changes, fails without them.
> 
> Existing tier1-3 tests continue to pass.
> 
> While working on the patch I noticed that `conn.isReusable()` always returns true. I can remove all references to `isReusable` here or in another PR; it would simplify the code a bit.

This pull request has now been integrated.

Changeset: 41900b57
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41900b57af084e0cfc1453681b24fe5606e11ab2
Stats:     41 lines in 2 files changed: 23 ins; 13 del; 5 mod

8189338: JMX RMI Remote Mbean server connection hangs if the server stops responding during a SSL Handshake

Reviewed-by: smarks

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

PR: https://git.openjdk.org/jdk/pull/11829

From goetz at openjdk.org  Wed Jan  4 14:29:30 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 4 Jan 2023 14:29:30 GMT
Subject: RFR: 8299439: [testbug]
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR after
 1.1.2023 and 8296239
Message-ID: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>

?fails for hr_HR after 1.1.2023 and 8296239

Hi,

this fixes the issue with the currency test.

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

Commit messages:
 - 8299439: [testbug] java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR after 1.1.2023 and 8296239

Changes: https://git.openjdk.org/jdk/pull/11844/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299439
  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11844.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11844/head:pull/11844

PR: https://git.openjdk.org/jdk/pull/11844

From pminborg at openjdk.org  Wed Jan  4 14:37:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 14:37:34 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

  Use canonical NaN values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/e1f95d83..ec2e7c99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=03-04

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From alanb at openjdk.org  Wed Jan  4 14:41:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jan 2023 14:41:49 GMT
Subject: RFR: 8299439: [testbug]
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR after
 1.1.2023 and 8296239
In-Reply-To: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>
References: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>
Message-ID: <FmuMTlkGAzPlNZfQAw3kQobZtrbPaoAPXIQ0xct0ais=.f27bfa9a-eda2-40c9-a1f1-73be507acddb@github.com>

On Wed, 4 Jan 2023 14:21:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?fails for hr_HR after 1.1.2023 and 8296239
> 
> Hi,
> 
> this fixes the issue with the currency test.

Should this be closed as dup of JDK-8299439 ?

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

PR: https://git.openjdk.org/jdk/pull/11844

From jpai at openjdk.org  Wed Jan  4 14:46:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Jan 2023 14:46:54 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial()
Message-ID: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>

Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 

As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.

The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.

Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:

> If the current thread does not support thread locals then
> this method returns its {@link #initialValue} (or {@code null}
> if the {@code initialValue} method is not overridden).

which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:


public class Test {
  public static void main(final String[] args) throws Exception {
    Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
	var t = ThreadLocal.withInitial(() -> 2);
	System.out.println("Thread local value is " + t.get());
    });
  }
}

Running this with `java --enable-preview --source 21 Test.java` returns:

Thread local value is 2


The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.

Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?

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

Commit messages:
 - 8258776: ThreadLocal#initialValue() Javadoc is unaware of ThreadLocal#withInitial()

Changes: https://git.openjdk.org/jdk/pull/11846/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8258776
  Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11846.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11846/head:pull/11846

PR: https://git.openjdk.org/jdk/pull/11846

From duke at openjdk.org  Wed Jan  4 14:49:29 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 4 Jan 2023 14:49:29 GMT
Subject: RFR: 8299444  java.util.Set.copyOf allocates needlessly for empty
 input collections
Message-ID: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>

Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.

This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

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

Commit messages:
 - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections

Changes: https://git.openjdk.org/jdk/pull/11847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299444
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11847/head:pull/11847

PR: https://git.openjdk.org/jdk/pull/11847

From rriggs at openjdk.org  Wed Jan  4 15:00:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Jan 2023 15:00:51 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <_0EkHdLEYDUuweG8t8yQqZYOhMr002nhkN6hLjduEAE=.7a907322-2a07-45f1-b8d0-a0f22ede7832@github.com>

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11847

From uschindler at openjdk.org  Wed Jan  4 15:03:51 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 4 Jan 2023 15:03:51 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
Message-ID: <OHe9vN7BphO8vTZinwDtPys_rtHbTGp-IlL9OuqrwRI=.81cec4eb-e4e7-4189-9335-8ede8edbe888@github.com>

On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values

to me latest change looks fine.

I would simplify the test setup as Alan said, but this is out of scope of my review. I thought for testing you would use `--patch-module` and inject the test classes into the same package as Bits class?

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

Marked as reviewed by uschindler (Author).

PR: https://git.openjdk.org/jdk/pull/11840

From prappo at openjdk.org  Wed Jan  4 15:22:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 4 Jan 2023 15:22:53 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <RZnPhbxCiVJzVme_qfguIxOYioKVSszsFGowaNmTqRg=.5141e06a-1ce1-40f3-8418-a53294749fe1@github.com>

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

Curious: how bad was that "needless allocation" that it was required to be optimized away?

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

PR: https://git.openjdk.org/jdk/pull/11847

From pminborg at openjdk.org  Wed Jan  4 15:43:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jan 2023 15:43:46 GMT
Subject: RFR: 8299513: Cleanup java.io
Message-ID: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>

Code in java.io contains many legacy constructs and semantics not recommended including: 

* C-style array declaration 
* Unnecessary visibility 
* Redundant keywords in interfaces (e.g. public, static) 
* Non-standard naming for constants 
* Javadoc typos 
* Missing final declaration 

These should be fixed as a sanity effort.

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

Commit messages:
 - Cleanup ExpiringCache
 - Cleanup java.io

Changes: https://git.openjdk.org/jdk/pull/11848/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299513
  Stats: 236 lines in 25 files changed: 8 ins; 7 del; 221 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Wed Jan  4 15:51:49 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 4 Jan 2023 15:51:49 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <RZnPhbxCiVJzVme_qfguIxOYioKVSszsFGowaNmTqRg=.5141e06a-1ce1-40f3-8418-a53294749fe1@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <RZnPhbxCiVJzVme_qfguIxOYioKVSszsFGowaNmTqRg=.5141e06a-1ce1-40f3-8418-a53294749fe1@github.com>
Message-ID: <HdcdtXFqeV7OnN7faWdEtPxW1LzWfSfZpmX7nEbOGE4=.8f2e1da2-85e5-4cd5-be15-6146f89afc30@github.com>

On Wed, 4 Jan 2023 15:20:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Curious: how bad was that "needless allocation" that it was required to be optimized away?

@pavelrappo Fair question! I guess it depends on what dominates the benchmark: given that the copyOf methods goes to some length to try to avoid allocating new instances of the immutable sets the proposed patch seemed like rather low-hanging fruit. I found this as I was running some (to be fair, rather specific) benches which drew my attention to it.

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

PR: https://git.openjdk.org/jdk/pull/11847

From stsypanov at openjdk.org  Wed Jan  4 15:56:52 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 4 Jan 2023 15:56:52 GMT
Subject: RFR: 8299513: Cleanup java.io
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>

On Wed, 4 Jan 2023 15:37:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

src/java.base/share/classes/java/io/StringWriter.java line 244:

> 242: 
> 243:     private static int checkSize(int initialSize) {
> 244:         if (initialSize < 0) {

Similar checks exist e.g. in `ByteArrayOutputStream` and `CharWrite`, so could we reuse it somehow across java.io?

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

PR: https://git.openjdk.org/jdk/pull/11848

From stsypanov at openjdk.org  Wed Jan  4 15:57:25 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 4 Jan 2023 15:57:25 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
Message-ID: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>

Use the following methods instead of hand-written code:
- Objects.checkFromIndexSize()
- Objects.checkFromToIndex()

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

Commit messages:
 - 8299600: Use Objects.check*() where appropriate in java.io
 - Merge branch 'master' into index-io
 - Fix
 - Check from-to in java.io

Changes: https://git.openjdk.org/jdk/pull/11849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299600
  Stats: 37 lines in 6 files changed: 10 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11849.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11849/head:pull/11849

PR: https://git.openjdk.org/jdk/pull/11849

From djelinski at openjdk.org  Wed Jan  4 16:13:53 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 4 Jan 2023 16:13:53 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
 <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
Message-ID: <rVllY6SLt8tlyISyps6WxW0pYdAyducHnehUTzGRv98=.d088df55-7d29-4d67-9bb3-89146a05721a@github.com>

On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
>> 
>> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
>> 
>> Motivational improvements:
>> 
>> 
>> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
>> 
>> # Default JDK tree
>> 
>> # Baseline
>> real	0m9.086s
>> user	0m22.857s
>> sys	0m4.202s
>> 
>> # Patched
>> real	0m6.406s   ; +40% faster
>> user	0m17.156s
>> sys	0m3.193s
>> 
>> # +100K fuzzer tests in tree
>> 
>> # Baseline
>> real	3m1.997s
>> user	3m16.643s
>> sys	0m10.490s
>> 
>> # Patched
>> real	0m8.919s   ; 20x faster
>> user	0m17.904s
>> sys	0m4.860s
>> 
>> 
>> Additional testing:
>>  - [x] Ad-hoc timing tests (see above)
>>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

I like this!

$ time make run-test TEST=jdk/java/net/BindException/Test.java:

# baseline:
real    0m43.176s
user    0m12.453s
sys     1m13.797s
# patched:
real    0m22.558s
user    0m10.797s
sys     1m1.734s

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

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/11824

From shade at openjdk.org  Wed Jan  4 16:25:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jan 2023 16:25:50 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <FwxHdOiOpKhXCdcbAdSH2_5dKHYoXLUc0H9sTlCJ-jA=.aa750ba6-193e-4047-98fa-80b64b2ff4c4@github.com>

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

Looks okay. This relies a bit on `isEmpty()` to be actually fast, but it seems unlikely it would be worse than doing the `toArray()`.

`Map.copyOf` has the same opportunity.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11847

From goetz at openjdk.org  Wed Jan  4 16:29:59 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 4 Jan 2023 16:29:59 GMT
Subject: Withdrawn: 8299439: [testbug]
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR after
 1.1.2023 and 8296239
In-Reply-To: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>
References: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>
Message-ID: <2N0XGWndgxMA6VZ1Yk1wJIoQ4Vu1aRC4kYJunrN6iH8=.d5c3afd3-3e38-436b-9f1e-c3c48e7c94bf@github.com>

On Wed, 4 Jan 2023 14:21:53 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> ?fails for hr_HR after 1.1.2023 and 8296239
> 
> Hi,
> 
> this fixes the issue with the currency test.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11844

From goetz at openjdk.org  Wed Jan  4 16:29:58 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 4 Jan 2023 16:29:58 GMT
Subject: RFR: 8299439: [testbug]
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR after
 1.1.2023 and 8296239
In-Reply-To: <FmuMTlkGAzPlNZfQAw3kQobZtrbPaoAPXIQ0xct0ais=.f27bfa9a-eda2-40c9-a1f1-73be507acddb@github.com>
References: <Tb53_HacmsjAsua5evdTlgE1ow6w3mIjXu3gDFJfO3c=.fe2d323c-9fdb-47dd-8456-ebc313472efe@github.com>
 <FmuMTlkGAzPlNZfQAw3kQobZtrbPaoAPXIQ0xct0ais=.f27bfa9a-eda2-40c9-a1f1-73be507acddb@github.com>
Message-ID: <Cj9ym_aFJFz7lNj3BSGctKDYUlSJjIo51EkFWxZfzSM=.d4beb7b8-5f6d-493e-9868-a5bdf1d08018@github.com>

On Wed, 4 Jan 2023 14:38:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?fails for hr_HR after 1.1.2023 and 8296239
>> 
>> Hi,
>> 
>> this fixes the issue with the currency test.
>
> Should this be closed as dup of pull/11833 ?

@AlanBateman, sorry, I missed that other PR.

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

PR: https://git.openjdk.org/jdk/pull/11844

From mernst at openjdk.org  Wed Jan  4 16:35:41 2023
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 4 Jan 2023 16:35:41 GMT
Subject: RFR: 8299563: Fix typos [v4]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <XAnYDErHB7QjosCP-RyKXhkZWdkVZaR0UOsBdXNvbGs=.8ddf4d29-5624-4015-9149-8bfd1451c576@github.com>

> 8299563: Fix typos

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Address review feedback
 - Merge ../jdk-openjdk into typos-typos
 - Merge ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=03
  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From alanb at openjdk.org  Wed Jan  4 16:38:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jan 2023 16:38:50 GMT
Subject: RFR: 8299513: Cleanup java.io
In-Reply-To: <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
Message-ID: <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>

On Wed, 4 Jan 2023 15:54:29 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> src/java.base/share/classes/java/io/StringWriter.java line 244:
> 
>> 242: 
>> 243:     private static int checkSize(int initialSize) {
>> 244:         if (initialSize < 0) {
> 
> Similar checks exist e.g. in `ByteArrayOutputStream` and `CharWrite`, so could we reuse it somehow across java.io?

I assume this is done so that "lock" is only set once during construction (StringWriter is a bit unusual in that it uses the SB as the lock object). A downside of the change is that it introduces casts. Another is that the expression to super is a bi  complicated and forces the reader to locate checkSize at the end of the file to find the code specified by the constructor. So two minds on this part, maybe it should be left unchanged.

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

PR: https://git.openjdk.org/jdk/pull/11848

From lancea at openjdk.org  Wed Jan  4 16:41:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 4 Jan 2023 16:41:55 GMT
Subject: RFR: 8299563: Fix typos [v4]
In-Reply-To: <XAnYDErHB7QjosCP-RyKXhkZWdkVZaR0UOsBdXNvbGs=.8ddf4d29-5624-4015-9149-8bfd1451c576@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <XAnYDErHB7QjosCP-RyKXhkZWdkVZaR0UOsBdXNvbGs=.8ddf4d29-5624-4015-9149-8bfd1451c576@github.com>
Message-ID: <QSV52L2x_79x0ZBDTa-LXLOtaRuGm-TJip9EQ-ONwJk=.f13a56eb-45b1-44e1-9f0e-11f5a5ab6296@github.com>

On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8299563: Fix typos
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Address review feedback
>  - Merge ../jdk-openjdk into typos-typos
>  - Merge ../jdk-openjdk into typos-typos
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10029

From mandy.chung at oracle.com  Wed Jan  4 19:27:11 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 4 Jan 2023 11:27:11 -0800
Subject: jdeps - option to to analyze package-private API
In-Reply-To: <68ef4409-114d-b2d2-9f9f-fc3121c2f7ff@oracle.com>
References: <2dd880da-6ddc-302e-2e03-504b4171f484@oracle.com>
 <68ef4409-114d-b2d2-9f9f-fc3121c2f7ff@oracle.com>
Message-ID: <6d952ac5-41a6-4e4e-66df-9c8a564eaf10@oracle.com>


On 12/12/22 7:26 AM, Alan Bateman wrote:
> On 03/12/2022 18:15, Matej Turcel wrote:
>> :
>>
>> So far, jdeps with the --api-only flag seems like the perfect tool, 
>> except
>> there is a little problem -- we have packages (dozens of them) which
>> exist in multiple modules. For example, package `com.foo` exists in
>> three separate modules (meaning each of these modules has a class in 
>> that
>> package). That means package-private "stuff" (members + 
>> constructor/method
>> signatures) is a part of module's API. So to infer correct types of 
>> gradle
>> module dependencies using jdeps, we need jdeps to consider 
>> package-private
>> stuff a part of the API.
>
> The scenario seems a bit unusual in that API elements with package 
> access aren't usually considered to be part of the API. Does the 
> javadoc published for users of these components include the API 
> elements with package access?? I realize Gradle may define "module" to 
> mean something else but for the Java platform, a module is a set of 
> packages.
>
> I haven't seen any opinions from others but my initial reaction is 
> that it wouldn't be a good idea to change --api-only to consider API 
> elements with package access to be part of the API. If jdeps were 
> changed then it would need a new option.


I also agree that it's not a good idea to change --api-only as this 
option is meant to find dependencies from exported packages and the 
module's API.

I considered in the past to provide options similar to javadoc -package, 
-private, -protected, -public that specify if 
private/package/protected/public types and members are shown.

--api-only is like javadoc -protected and it analyzes protected/public 
types and members.?? I'm open to add jdeps options similar to javadoc 
-package, -private, -protected, -public but a different name since jdeps 
-package is used already.?? More consideration would be needed if this 
should restrict to exported packages and how to select other packages.

Mandy


From smarks at openjdk.org  Wed Jan  4 19:41:48 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jan 2023 19:41:48 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <z86qCjRRB19yM2C9FRoWdItdO1zhXpQR9AWcPMo7lOY=.a4d47469-e8fc-42cb-82d5-a8a3b0caed3d@github.com>

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

There's no regression test. However, with the current code (prior to this change) a call to `Set.of(zeroLengthArray)` returns the same instance as `Set.of()`, so it's difficult to write a simple functional test for this change. The test would have to assert that "no HashSet is allocated along this code path" which is much harder to test and frankly probably isn't worth it. So, please add one of the `noreg-*` labels to the bug to indicate the rationale for omitting a regression test.

https://openjdk.org/guide/#jbs-label-dictionary

I'd probably add the `Map.copyOf` change to this PR to avoid some bug/PR/review overhead. Thanks for mentioning this @shipilev.

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

PR: https://git.openjdk.org/jdk/pull/11847

From swpalmer at openjdk.org  Wed Jan  4 19:55:48 2023
From: swpalmer at openjdk.org (Scott Palmer)
Date: Wed, 4 Jan 2023 19:55:48 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
In-Reply-To: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
Message-ID: <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>

On Wed, 4 Jan 2023 15:50:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Use the following methods instead of hand-written code:
> - Objects.checkFromIndexSize()
> - Objects.checkFromToIndex()

src/java.base/share/classes/java/io/CharArrayWriter.java line 101:

> 99:      */
> 100:     public void write(char[] c, int off, int len) {
> 101:         Objects.checkFromToIndex(off, len, c.length);

shouldn't that be Objects.checkFromIndexSize(off, len, c.length);

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

PR: https://git.openjdk.org/jdk/pull/11849

From aivanov at openjdk.org  Wed Jan  4 19:56:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Jan 2023 19:56:59 GMT
Subject: RFR: 8299563: Fix typos [v4]
In-Reply-To: <XAnYDErHB7QjosCP-RyKXhkZWdkVZaR0UOsBdXNvbGs=.8ddf4d29-5624-4015-9149-8bfd1451c576@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <XAnYDErHB7QjosCP-RyKXhkZWdkVZaR0UOsBdXNvbGs=.8ddf4d29-5624-4015-9149-8bfd1451c576@github.com>
Message-ID: <NmKRmdtSk9LlT16Jia_QS5n5ZW3tT_Jkh6zVWto2R4k=.c9b91223-211a-44c8-b143-4cac82de4cac@github.com>

On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8299563: Fix typos
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Address review feedback
>  - Merge ../jdk-openjdk into typos-typos
>  - Merge ../jdk-openjdk into typos-typos
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Wed Jan  4 20:02:57 2023
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 4 Jan 2023 20:02:57 GMT
Subject: Integrated: 8299563: Fix typos
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <yHI67p3V0UwclsPq9xCR4W4-4nuKNrPs9hjJrlRK2L8=.1fee5e82-cdc3-4ac1-b4c0-4f44ce312f6e@github.com>

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> 8299563: Fix typos

This pull request has now been integrated.

Changeset: 7dcc6899
Author:    Michael Ernst <mernst at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7dcc689932ea276586282e0917f2efc10a598eb7
Stats:     5 lines in 5 files changed: 0 ins; 0 del; 5 mod

8299563: Fix typos

Reviewed-by: lancea, aivanov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/10029

From naoto at openjdk.org  Wed Jan  4 20:09:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Jan 2023 20:09:35 GMT
Subject: RFR: 8299292: Missing elements in aliased String array
Message-ID: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>

This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.

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

Commit messages:
 - copyright year
 - 8299292: Missing elements in aliased String array

Changes: https://git.openjdk.org/jdk/pull/11851/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11851&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299292
  Stats: 16 lines in 1 file changed: 6 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11851.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11851/head:pull/11851

PR: https://git.openjdk.org/jdk/pull/11851

From alanb at openjdk.org  Wed Jan  4 20:16:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jan 2023 20:16:50 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial()
In-Reply-To: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
Message-ID: <rQ7h002VN4_HKbwnxBTPFVy2dDX2b6UBSZjwGFGpedM=.457793b0-75ca-456d-8878-db1482d85c17@github.com>

On Wed, 4 Jan 2023 14:37:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
> 
> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
> 
> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
> 
> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
> 
>> If the current thread does not support thread locals then
>> this method returns its {@link #initialValue} (or {@code null}
>> if the {@code initialValue} method is not overridden).
> 
> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
> 
> 
> public class Test {
>   public static void main(final String[] args) throws Exception {
>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
> 	var t = ThreadLocal.withInitial(() -> 2);
> 	System.out.println("Thread local value is " + t.get());
>     });
>   }
> }
> 
> Running this with `java --enable-preview --source 21 Test.java` returns:
> 
> Thread local value is 2
> 
> 
> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
> 
> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?

src/java.base/share/classes/java/lang/ThreadLocal.java line 128:

> 126:      * value other than {@code null}, then either {@code ThreadLocal} can be
> 127:      * subclassed and this method overridden or {@link ThreadLocal#withInitial(Supplier)} method
> 128:      * can be used to construct a {@code ThreadLocal}.

This looks okay but maybe slightly better to say "or the method withInitial(Supplier) can be used ...". 

I think you can probably reflow this paragraph to avoid having a mix of short and long lines.

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

PR: https://git.openjdk.org/jdk/pull/11846

From iris at openjdk.org  Wed Jan  4 20:34:50 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jan 2023 20:34:50 GMT
Subject: RFR: 8299292: Missing elements in aliased String array
In-Reply-To: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
References: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
Message-ID: <HZ4RKx85AYMm-cB4XyjLaCZn5FuyBbPdbZlxf4NOy-I=.972772cb-611b-479b-9b3f-c307e6ab50b4@github.com>

On Wed, 4 Jan 2023 19:57:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11851

From naoto at openjdk.org  Wed Jan  4 21:04:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Jan 2023 21:04:08 GMT
Subject: RFR: 8299292: Missing elements in aliased String array [v2]
In-Reply-To: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
References: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
Message-ID: <i9KWDluCWlnNqyXK27R5HDudCa3mZ3eJ9a2qMmRfrXY=.90b9fea4-19b0-45b1-88c2-f1c68b21b5d1@github.com>

> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.

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

  Removed unnecessary variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11851/files
  - new: https://git.openjdk.org/jdk/pull/11851/files/92dff5df..e6ce0791

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11851&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11851&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11851

From smarks at openjdk.org  Wed Jan  4 21:06:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jan 2023 21:06:50 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
Message-ID: <8MneENxi9GalyMU7i_5nxNO5KwYe3XysjrxWC3CBYnU=.b8ff4d8c-11f0-4c50-aa29-fd7a96c17309@github.com>

On Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review
>   
>   1. Reduce duplication in tests
>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.

Sorry, this got derailed by the discussion of `SequencedCollection::replaceAll`. I think we should just set that issue aside. I don't think `SequencedCollection::replaceAll` makes sense, thus this PR shouldn't be held up on its account.

The change is fine in concept. A couple adjustments needs to be made: javadoc since-tags need to be updated to 21, and copyrights updated to 2023. (Well, maybe an argument could be made that they should stay at 2022. I don't particularly care.) Also, the CSR should be updated to reflect the changes to the specifications. Other than those items, this should be fine to move forward.

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

PR: https://git.openjdk.org/jdk/pull/10520

From jcking at openjdk.org  Wed Jan  4 21:26:53 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 4 Jan 2023 21:26:53 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]
In-Reply-To: <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
Message-ID: <nSrBQtMzYS-e2MuWNfrsARdjbbD8iNud_9OcPV_QUCc=.0597e32d-5dab-4dbf-8444-d556c2e7aad8@github.com>

On Sat, 17 Dec 2022 06:39:48 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete unintended addition of files from previous commit
>   
>   Signed-off-by: Justin King <jcking at google.com>

Friendly poke.

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

PR: https://git.openjdk.org/jdk/pull/11604

From jvernee at openjdk.org  Wed Jan  4 21:33:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 4 Jan 2023 21:33:56 GMT
Subject: [jdk20] RFR: 8299561: VaList.empty() doesn't return a list
 associated with the global scope
In-Reply-To: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
References: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
Message-ID: <0DoOfsNpZAGVRuNkDkug0SebF9A93C7jj6pesYUBO_0=.eb29e9e2-6e06-490b-8009-567e1a5a6f99@github.com>

On Wed, 4 Jan 2023 10:49:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a long-standing conformance issue: `VaList.empty` is specified to return a `VaList` associated with the global scope, but in some platforms (Aarch64/Linux and x64/Linux) the empty list is associated with an implicit scope instead.
> 
> This doesn't make a lot of difference, given that the empty list is always stored in a static final in the underlying implementation - that said, it would be a good thing to rectify this conformance issue.

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/82

From smarks at openjdk.org  Wed Jan  4 21:34:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Jan 2023 21:34:53 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <YWO2wTB2miEbk3Hdp7kx_ZlHysy43gInAP1YyGkerWM=.5c260521-0048-4c86-98bb-ea2ef9d5904c@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
 <YWO2wTB2miEbk3Hdp7kx_ZlHysy43gInAP1YyGkerWM=.5c260521-0048-4c86-98bb-ea2ef9d5904c@github.com>
Message-ID: <Uj8JtPgxcXBK_e4fcEmp-bUdEnMY4YptyHai5u_vA2M=.6c0e4ca0-cae0-4adc-b188-9b3caf1a8156@github.com>

On Sat, 3 Dec 2022 08:23:34 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes according to review
>>   
>>   1. Reduce duplication in tests
>>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>
> A gentle ping: please review the change and the CSR. Thanks.

@amaembo a couple comments on the test.

The test should probably have `@key randomness` added to it.

On 2022-10-28, @bplb wrote:
> jdk.test.lib.RandomFactory can be used to generate a reproducible sequence of random numbers. An example of its use may be seen for example in java/nio/file/Files/CopyAndMove.java

This bit of the test library is useful if the test is testing a random subset of the state space. It prints out the random seed on each run so that if one of the test cases fails, it's possible to reproduce it by supplying the same seed. However, it's restricted to Random and SplittableRandom, and we want to test something like Xoshiro256PlusPlus that is a RandomGenerator but not a Random. So maybe this test library can't be applied. However, take a look and see if you think it might be useful to use it.

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

PR: https://git.openjdk.org/jdk/pull/10520

From duke at openjdk.org  Wed Jan  4 22:01:55 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 4 Jan 2023 22:01:55 GMT
Subject: Integrated: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java
 fails for hr_HR
In-Reply-To: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
References: <HW9WJz7Fy72tGEo5TsSRRhHtvHiacn8-P6SLEpGDynI=.7cef2674-f825-4fe1-ab16-869c3c10ca81@github.com>
Message-ID: <wUe6Glxud2NBq-HVwcHjz9GCUDdgpfBPuE7f6rlivG0=.30e1675a-5b57-452a-8b50-b07e39721939@github.com>

On Tue, 3 Jan 2023 17:40:42 GMT, Justin Lu <duke at openjdk.org> wrote:

> Regression caused by the fix to [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217 Amendment 174 Update changes went into effect starting in 2023. 
> 
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as _java/text/Format/NumberFormat/CurrencySymbols.properties_ did not have the proper change from the Amendment 174 update as well.
> 
> Swapping the outdated **Kn** to **EUR** matches the Amendment 174 update, and fixes the failing test.

This pull request has now been integrated.

Changeset: 3b374c01
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2
Stats:     8 lines in 3 files changed: 1 ins; 2 del; 5 mod

8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR

Reviewed-by: naoto, lancea, jpai

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

PR: https://git.openjdk.org/jdk/pull/11833

From bpb at openjdk.org  Wed Jan  4 22:19:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Jan 2023 22:19:49 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
In-Reply-To: <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
Message-ID: <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>

On Wed, 4 Jan 2023 19:52:07 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> src/java.base/share/classes/java/io/CharArrayWriter.java line 101:
> 
>> 99:      */
>> 100:     public void write(char[] c, int off, int len) {
>> 101:         Objects.checkFromToIndex(off, len, c.length);
> 
> shouldn't that be Objects.checkFromIndexSize(off, len, c.length);

It looks like all the occurrences of `checkFromToIndex()` should instead be `checkFromIndexSize()`.

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

PR: https://git.openjdk.org/jdk/pull/11849

From mernst at openjdk.org  Wed Jan  4 22:38:03 2023
From: mernst at openjdk.org (Michael Ernst)
Date: Wed, 4 Jan 2023 22:38:03 GMT
Subject: RFR: 8299563: Fix typos [v3]
In-Reply-To: <L4tOcragEbgUkIEf-vIwfijCW4Tzf9erpuY3hcDqhQE=.e0bf33b3-3202-4d98-8f5a-01113cd35d1e@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>
 <L4tOcragEbgUkIEf-vIwfijCW4Tzf9erpuY3hcDqhQE=.e0bf33b3-3202-4d98-8f5a-01113cd35d1e@github.com>
Message-ID: <UfkxP-vtApCHC294vpUKfD0b7iXxq51SBuD-SmwV8HU=.d4727782-f273-40f6-8564-bf70a75ecc29@github.com>

On Wed, 4 Jan 2023 01:19:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> Hello Michael, I've created https://bugs.openjdk.org/browse/JDK-8299563 to track this final few typos. Could you please update the title of this PR to `8299563: Fix typos`? That should then allow you to proceed using this PR. Please also merge with latest master branch once more since some typo fixes from this PR have been merged recently. Thank you for your patience.

Thank you @jaikiran @LanceAndersen @aivanov-jdk !

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

PR: https://git.openjdk.org/jdk/pull/10029

From joehw at openjdk.org  Wed Jan  4 23:25:48 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 4 Jan 2023 23:25:48 GMT
Subject: RFR: 8299292: Missing elements in aliased String array [v2]
In-Reply-To: <i9KWDluCWlnNqyXK27R5HDudCa3mZ3eJ9a2qMmRfrXY=.90b9fea4-19b0-45b1-88c2-f1c68b21b5d1@github.com>
References: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
 <i9KWDluCWlnNqyXK27R5HDudCa3mZ3eJ9a2qMmRfrXY=.90b9fea4-19b0-45b1-88c2-f1c68b21b5d1@github.com>
Message-ID: <6DJRZtp42WHncOzRjdVf74PFqgZr3K3mF3OpcjNoAqA=.386862b7-cac6-46db-a8ac-595da10a947b@github.com>

On Wed, 4 Jan 2023 21:04:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary variable

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11851

From serb at openjdk.org  Thu Jan  5 01:04:48 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 5 Jan 2023 01:04:48 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <z86qCjRRB19yM2C9FRoWdItdO1zhXpQR9AWcPMo7lOY=.a4d47469-e8fc-42cb-82d5-a8a3b0caed3d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <z86qCjRRB19yM2C9FRoWdItdO1zhXpQR9AWcPMo7lOY=.a4d47469-e8fc-42cb-82d5-a8a3b0caed3d@github.com>
Message-ID: <kpnW2-ZCEO6lLCAW6p0zGyWUrgx40iUQW0rza5MtgH8=.47a04bb2-d507-497f-bd08-f42cb3306544@github.com>

On Wed, 4 Jan 2023 19:39:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> so it's difficult to write a simple functional test for this change.

It is possible to track that for some "custom" and empty collection the only method will be called is `isEmpty` and nothing else. Not sure how it is useful or not.

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

PR: https://git.openjdk.org/jdk/pull/11847

From iris at openjdk.org  Thu Jan  5 01:26:49 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Jan 2023 01:26:49 GMT
Subject: RFR: 8299292: Missing elements in aliased String array [v2]
In-Reply-To: <i9KWDluCWlnNqyXK27R5HDudCa3mZ3eJ9a2qMmRfrXY=.90b9fea4-19b0-45b1-88c2-f1c68b21b5d1@github.com>
References: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
 <i9KWDluCWlnNqyXK27R5HDudCa3mZ3eJ9a2qMmRfrXY=.90b9fea4-19b0-45b1-88c2-f1c68b21b5d1@github.com>
Message-ID: <CTjdtSUWUPcq64grOa041zR5eHonHYn-hlhP80FjlKU=.a828d009-1b58-456c-a835-0490cbb77f97@github.com>

On Wed, 4 Jan 2023 21:04:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary variable

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11851

From bpb at openjdk.org  Thu Jan  5 01:39:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 01:39:52 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
In-Reply-To: <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
 <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>
Message-ID: <Mu4VopTwTyI7l0YzjfJti6AU-Z2QCxMIXU4CiGjSy2o=.553fdd43-a304-4328-8905-80f3101de11c@github.com>

On Wed, 4 Jan 2023 22:16:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/CharArrayWriter.java line 101:
>> 
>>> 99:      */
>>> 100:     public void write(char[] c, int off, int len) {
>>> 101:         Objects.checkFromToIndex(off, len, c.length);
>> 
>> shouldn't that be Objects.checkFromIndexSize(off, len, c.length);
>
> It looks like all the occurrences of `checkFromToIndex()` should instead be `checkFromIndexSize()`.

Indeed there are at least four regression test failures with this as-is:

- java/io/InputStream/ReadParams.java
- java/io/OutputStream/WriteParams.java
- java/io/Writer/WriteParams.java
- java/nio/channels/FileChannel/Transfer2GPlus.java

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

PR: https://git.openjdk.org/jdk/pull/11849

From bpb at openjdk.org  Thu Jan  5 01:44:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 01:44:49 GMT
Subject: RFR: 8299513: Cleanup java.io
In-Reply-To: <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
 <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>
Message-ID: <r3xCIkBO3VWYW4CmVM5dKSgwKvele4k3wg6Ovd58v3w=.5f4f7847-deaf-4033-b034-f56be8849599@github.com>

On Wed, 4 Jan 2023 16:35:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/StringWriter.java line 244:
>> 
>>> 242: 
>>> 243:     private static int checkSize(int initialSize) {
>>> 244:         if (initialSize < 0) {
>> 
>> Similar checks exist e.g. in `ByteArrayOutputStream` and `CharWrite`, so could we reuse it somehow across java.io?
>
> I assume this is done so that "lock" is only set once during construction (StringWriter is a bit unusual in that it uses the SB as the lock object). A downside of the change is that it introduces casts. Another is that the expression to super is a bit complicated and forces the reader to locate checkSize at the end of the file to find the check/exception specified by the constructor. So two minds on this part, maybe it should be left unchanged.

I think the casts are worth it to set `lock` only once during construction, but would be inclined to leave out the addition of `checkSize`.

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

PR: https://git.openjdk.org/jdk/pull/11848

From alanb at openjdk.org  Thu Jan  5 07:14:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jan 2023 07:14:48 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
In-Reply-To: <Mu4VopTwTyI7l0YzjfJti6AU-Z2QCxMIXU4CiGjSy2o=.553fdd43-a304-4328-8905-80f3101de11c@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
 <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>
 <Mu4VopTwTyI7l0YzjfJti6AU-Z2QCxMIXU4CiGjSy2o=.553fdd43-a304-4328-8905-80f3101de11c@github.com>
Message-ID: <TIrzYXL3ipVw7JHUeDUPqKxenDuao-hc7y8p9_Twlv8=.4790cb63-6fa3-4493-b7a4-904911a64d75@github.com>

On Thu, 5 Jan 2023 01:36:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Indeed there are at least four regression test failures with this as-is:
> 
> * java/io/InputStream/ReadParams.java
> * java/io/OutputStream/WriteParams.java
> * java/io/Writer/WriteParams.java
> * java/nio/channels/FileChannel/Transfer2GPlus.java

The java/io tests run in tier2 and I think the GHA only run tier1.

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

PR: https://git.openjdk.org/jdk/pull/11849

From rehn at openjdk.org  Thu Jan  5 07:28:51 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Jan 2023 07:28:51 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v8]
In-Reply-To: <b7fEttZ902Ss_f8_XN84mn7rxgnk3BiSc2-hbegYi00=.daec5059-5f55-4d8a-9f19-a711a579611d@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <xy2Eago_3UXJFsvRNfJ4y3GLbfnvdSBEL8MEMLZLr44=.6fb62abf-a53b-4531-bcc6-42aaf74d030d@github.com>
 <b7fEttZ902Ss_f8_XN84mn7rxgnk3BiSc2-hbegYi00=.daec5059-5f55-4d8a-9f19-a711a579611d@github.com>
Message-ID: <eDZlEzZPIKJgCKgT1qluaqNUAqcofFtn2CCLIYUfQKY=.7c172aa0-9ec8-4d7f-9925-ae97a5b4e14d@github.com>

On Fri, 16 Dec 2022 16:10:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify logic for including __ubsan_default_options
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> I much also check: is this really needed for *all* executables we make? I would have guessed that it would suffice with the "launchers", i.e. like `java`, `javac`, `jar` etc. These are all compiled from a single source file, `src/java.base/share/native/launcher/main.c`, with different defines depending on what Java classes it should actually launch, and with different output names.
> 
> Doing things this way will also affect non-launcher executables, like `jabswitch`, `msiwrapper` and all executable test binaries. 
> 
> That might be correct, but I could not be certain of that from trying to read the backlog of discussion in this bug.

I think @magicus is back next week. Since this is mainly build stuff I'll sit this one out.

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

PR: https://git.openjdk.org/jdk/pull/11604

From mbaesken at openjdk.org  Thu Jan  5 09:02:31 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jan 2023 09:02:31 GMT
Subject: RFR: JDK-8299657: sun/tools/jhsdb/SAGetoptTest.java fails after
 8299470
Message-ID: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com>

Some exception/error message changed with 8299470 so we have to adjust the test.
Current error is 

Unexpected error 'Successor argument without leading - is expected for 'd' but we got '-c''
java.lang.RuntimeException: Bad option test 4 failed
at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124)
at SAGetoptTest.main(SAGetoptTest.java:149)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
at java.base/java.lang.Thread.run(Thread.java:1623)

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

Commit messages:
 - JDK-8299657

Changes: https://git.openjdk.org/jdk/pull/11860/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299657
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11860.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11860/head:pull/11860

PR: https://git.openjdk.org/jdk/pull/11860

From mcimadamore at openjdk.org  Thu Jan  5 09:48:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Jan 2023 09:48:01 GMT
Subject: [jdk20] Integrated: 8299561: VaList.empty() doesn't return a list
 associated with the global scope
In-Reply-To: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
References: <Z6fUJ25SDfVuXwIriXt8sgPVoQJtiqtcnFeW84PJAbs=.c7482d8e-d2e3-407c-a16c-b7ee45b675ac@github.com>
Message-ID: <kiXCYNSz2_VBPLPw1__oTQA6LbKMlDZWPb_NkSbR7eE=.9bf56c86-e429-4edd-a32b-e9d4e4ca2ba0@github.com>

On Wed, 4 Jan 2023 10:49:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a long-standing conformance issue: `VaList.empty` is specified to return a `VaList` associated with the global scope, but in some platforms (Aarch64/Linux and x64/Linux) the empty list is associated with an implicit scope instead.
> 
> This doesn't make a lot of difference, given that the empty list is always stored in a static final in the underlying implementation - that said, it would be a good thing to rectify this conformance issue.

This pull request has now been integrated.

Changeset: 9c4ed16b
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/9c4ed16be2fdb20f2917a6e8efacfbb30d3118b1
Stats:     6 lines in 3 files changed: 4 ins; 0 del; 2 mod

8299561: VaList.empty() doesn't return a list associated with the global scope

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk20/pull/82

From rgiulietti at openjdk.org  Thu Jan  5 11:08:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Jan 2023 11:08:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
Message-ID: <nWsrDkV2BngojWI5Ac8vOSagFdg3gFT-kh8OJvDkdNY=.80ac445c-f977-4247-810b-97effda3e120@github.com>

On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values

AFAIU from the doc, for `get()` and `set()` access modes as used here, a misalignment is not a problem and will not throw `IllegalStateException`.

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Thu Jan  5 11:40:52 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 11:40:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
Message-ID: <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>

On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values

The copypasted snippet above is misleading, you need to read the whole statement, so an IllegalStateException can only happen for unaligned access on access modes other than get/set (so volatile or opaque reads): "If access is misaligned then access for anything **other than the get and set access modes** will result in an IllegalStateException.", the sentence you posted is about if it is atomic or not. It just says that on 32 bits, long/double are not atomic for normal set/get.

P.S.: We definitely know that it works on 32 bit, the whole code of Lucene is full of those VarHandles :-)

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

PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Thu Jan  5 11:44:56 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 5 Jan 2023 11:44:56 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <kpnW2-ZCEO6lLCAW6p0zGyWUrgx40iUQW0rza5MtgH8=.47a04bb2-d507-497f-bd08-f42cb3306544@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <z86qCjRRB19yM2C9FRoWdItdO1zhXpQR9AWcPMo7lOY=.a4d47469-e8fc-42cb-82d5-a8a3b0caed3d@github.com>
 <kpnW2-ZCEO6lLCAW6p0zGyWUrgx40iUQW0rza5MtgH8=.47a04bb2-d507-497f-bd08-f42cb3306544@github.com>
Message-ID: <TZvRtrr5W4MxiqMcv3cHp_ichJUoJQJbDV8nF3LM1bM=.f2b99166-1ca7-4ffa-8cfa-1d88195c5645@github.com>

On Thu, 5 Jan 2023 01:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There's no regression test. However, with the current code (prior to this change) a call to `Set.of(zeroLengthArray)` returns the same instance as `Set.of()`, so it's difficult to write a simple functional test for this change. The test would have to assert that "no HashSet is allocated along this code path" which is much harder to test and frankly probably isn't worth it. So, please add one of the `noreg-*` labels to the bug to indicate the rationale for omitting a regression test.
>> 
>> https://openjdk.org/guide/#jbs-label-dictionary
>> 
>> I'd probably add the `Map.copyOf` change to this PR to avoid some bug/PR/review overhead. Thanks for mentioning this @shipilev.
>
>> so it's difficult to write a simple functional test for this change.
> 
> It is possible to track that for some "custom" and empty collection the only method will be called is `isEmpty` and nothing else. Not sure how it is useful or not.

@mrserb @stuart-marks Indeed, the reason for no regression test is because I didn't see any good way of testing "this operation will not allocate any memory" (which is the externally observable difference, besides having isEmpty being called, which of course could allocate memory (which I sincerely hope no implementations do)).

I can add the same logic to Map.copyOf, and possibly even List.copyOf (ImmutableCollections.listCopy). But will do so in additional commits in this PR.

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

PR: https://git.openjdk.org/jdk/pull/11847

From jdk at fiolino.de  Thu Jan  5 11:59:36 2023
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Thu, 5 Jan 2023 12:59:36 +0100
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
 <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>
Message-ID: <1fd57f3c-7803-62b9-cece-9efe6980147f@fiolino.de>



On 1/5/23 12:40, Uwe Schindler wrote:
> The copypasted snippet above is misleading, you need to read the whole statement, so an IllegalStateException can only happen for unaligned access on access modes other than get/set (so volatile or opaque reads): "If access is misaligned then access for anything **other than the get and set access modes** will result in an IllegalStateException.", the sentence you posted is about if it is atomic or not. It just says that on 32 bits, long/double are not atomic for normal set/get.
> 
> P.S.: We definitely know that it works on 32 bit, the whole code of Lucene is full of those VarHandles :-)

I think you are replying to my question. ;)
There are two cases here. One is the misaligned index, which is not 
relevant here because we're only using get/set.

The other is access to long/double values on 32-bit platforms. This is 
mentioned explicitly, and since you are talking about atomic access, 
it's also mentioned:

* read write access modes for all T, with the exception of access modes 
get and set for long and double on 32-bit platforms.
* atomic update access modes for int, long, float or double. (Future 
major platform releases of the JDK may support additional types for 
certain currently unsupported access modes.)

It says "access modes get and set", so no explicit atomic access mode. I 
would read it as {code}Varhandle.AccessMode.GET{/code} and SET respectively.

If it's for sure working on 32-bit platforms, then probably the Javadoc 
comment should be fixed.

-Michael

From shade at openjdk.org  Thu Jan  5 12:12:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jan 2023 12:12:51 GMT
Subject: RFR: 8294403: [REDO] make test should report only on executed
 tests [v2]
In-Reply-To: <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
 <lN0YQMuTFlj2ZuvzeWgxBAmx_vyKTtrMOZuMuWD1dPU=.50923a8a-81de-43d4-ab1f-5ef2db871dd3@github.com>
Message-ID: <mcw9KyHjTPU-15QjqqwDtUUSqa1pI6jJKf63NX5WSpA=.d4bd48e7-7669-4625-bb83-912113a6982b@github.com>

On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
>> 
>> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
>> 
>> Motivational improvements:
>> 
>> 
>> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
>> 
>> # Default JDK tree
>> 
>> # Baseline
>> real	0m9.086s
>> user	0m22.857s
>> sys	0m4.202s
>> 
>> # Patched
>> real	0m6.406s   ; +40% faster
>> user	0m17.156s
>> sys	0m3.193s
>> 
>> # +100K fuzzer tests in tree
>> 
>> # Baseline
>> real	3m1.997s
>> user	3m16.643s
>> sys	0m10.490s
>> 
>> # Patched
>> real	0m8.919s   ; 20x faster
>> user	0m17.904s
>> sys	0m4.860s
>> 
>> 
>> Additional testing:
>>  - [x] Ad-hoc timing tests (see above)
>>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

My longer testing passes well. I would like to integrate it soon, if there are no objections.

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

PR: https://git.openjdk.org/jdk/pull/11824

From stsypanov at openjdk.org  Thu Jan  5 12:14:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 5 Jan 2023 12:14:05 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
 [v2]
In-Reply-To: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
Message-ID: <6FULiwBHG9hpGGwhBct1_MgR4OmdNRwA9zXexZIXUBs=.f66dc334-606f-4040-acdb-db6ce11429db@github.com>

> Use the following methods instead of hand-written code:
> - Objects.checkFromIndexSize()
> - Objects.checkFromToIndex()

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

 - 8299600: Use checkFromIndexSize in PipedWriter.java
 - 8299600: Use checkFromIndexSize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11849/files
  - new: https://git.openjdk.org/jdk/pull/11849/files/facabce0..8af035f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11849&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11849&range=00-01

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11849.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11849/head:pull/11849

PR: https://git.openjdk.org/jdk/pull/11849

From stsypanov at openjdk.org  Thu Jan  5 12:14:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 5 Jan 2023 12:14:06 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
 [v2]
In-Reply-To: <TIrzYXL3ipVw7JHUeDUPqKxenDuao-hc7y8p9_Twlv8=.4790cb63-6fa3-4493-b7a4-904911a64d75@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
 <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>
 <Mu4VopTwTyI7l0YzjfJti6AU-Z2QCxMIXU4CiGjSy2o=.553fdd43-a304-4328-8905-80f3101de11c@github.com>
 <TIrzYXL3ipVw7JHUeDUPqKxenDuao-hc7y8p9_Twlv8=.4790cb63-6fa3-4493-b7a4-904911a64d75@github.com>
Message-ID: <kS945incHKbBRmH7AveADVhqGEdByoHg3GkjMQrdTFU=.076a9208-5072-4d16-8578-2ebc25bfea90@github.com>

On Thu, 5 Jan 2023 07:11:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Indeed there are at least four regression test failures with this as-is:
>> 
>> - java/io/InputStream/ReadParams.java
>> - java/io/OutputStream/WriteParams.java
>> - java/io/Writer/WriteParams.java
>> - java/nio/channels/FileChannel/Transfer2GPlus.java
>
>> Indeed there are at least four regression test failures with this as-is:
>> 
>> * java/io/InputStream/ReadParams.java
>> * java/io/OutputStream/WriteParams.java
>> * java/io/Writer/WriteParams.java
>> * java/nio/channels/FileChannel/Transfer2GPlus.java
> 
> The java/io tests run in tier2 and I think the GHA only run tier1.

Fixed along with copyright year

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

PR: https://git.openjdk.org/jdk/pull/11849

From pminborg at openjdk.org  Thu Jan  5 12:18:58 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jan 2023 12:18:58 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

  Use canonical NaN values also for read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/ec2e7c99..00a132c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=04-05

  Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From jdk at fiolino.de  Thu Jan  5 12:31:15 2023
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Thu, 5 Jan 2023 13:31:15 +0100
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <1fd57f3c-7803-62b9-cece-9efe6980147f@fiolino.de>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
 <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>
 <1fd57f3c-7803-62b9-cece-9efe6980147f@fiolino.de>
Message-ID: <8c58d801-1423-2e68-5577-c11bf0485d78@fiolino.de>

The more I think about it, the clearer is that the first line of the 
Javadoc is contrary to the other lines:

On 1/5/23 12:59, Michael Kuhlmann wrote:
> * read write access modes for all T, with the exception of access modes 
> get and set for long and double on 32-bit platforms.

So all read write modes will work, just if it's long or double then it 
won't work for get and for set access mode. (Or is getAndSet meant? But 
it's not called so, it's "get and set", so two access modes, or what?)

Then the following lines state that even harder access modes will work 
also for long and double.

So I think this should be labeled as "getAndSet" or at least 
"get-and-set" access mode. Currently it's very confusing.

From pminborg at openjdk.org  Thu Jan  5 12:34:12 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jan 2023 12:34:12 GMT
Subject: RFR: 8299513: Cleanup java.io [v2]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <_WD-EQq5LaItD3HwNjjZxii8pk_AJbiadmVJJ0I1Xlc=.acda7a44-e1f2-42bc-935b-869250fb1581@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Rework StringWriter constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/e028b62a..e3c107db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Thu Jan  5 12:34:12 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jan 2023 12:34:12 GMT
Subject: RFR: 8299513: Cleanup java.io [v2]
In-Reply-To: <r3xCIkBO3VWYW4CmVM5dKSgwKvele4k3wg6Ovd58v3w=.5f4f7847-deaf-4033-b034-f56be8849599@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
 <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>
 <r3xCIkBO3VWYW4CmVM5dKSgwKvele4k3wg6Ovd58v3w=.5f4f7847-deaf-4033-b034-f56be8849599@github.com>
Message-ID: <2kBTHcbilR3nHqVvWEsKRjo3SsXtMgVpwnbQ0GTBE2M=.48c51d8c-0a33-4f7b-a07b-1c83a4d918e2@github.com>

On Thu, 5 Jan 2023 01:42:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I assume this is done so that "lock" is only set once during construction (StringWriter is a bit unusual in that it uses the SB as the lock object). A downside of the change is that it introduces casts. Another is that the expression to super is a bit complicated and forces the reader to locate checkSize at the end of the file to find the check/exception specified by the constructor. So two minds on this part, maybe it should be left unchanged.
>
> I think the casts are worth it to set `lock` only once during construction, but would be inclined to leave out the addition of `checkSize`.

I have added a new proposal in the hope that the `requireNonNegative` method name and parameters should be trivial enough for users to directly understand without scrolling down. Let me know your thought on this.

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

PR: https://git.openjdk.org/jdk/pull/11848

From uschindler at openjdk.org  Thu Jan  5 12:35:53 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 12:35:53 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <nLHTBlDscamBXdYt_URjfHKjJpIjzLAQEw5d6qXapMc=.a32f5887-8f83-4212-9ec6-50f092a2a45d@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

As said before, for reads, the native varhandles can be used. There is also no separate "longBitsToRawDouble". What was the reason to add the latest commit?

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at apache.org  Thu Jan  5 12:37:33 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 13:37:33 +0100
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <8c58d801-1423-2e68-5577-c11bf0485d78@fiolino.de>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
 <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>
 <1fd57f3c-7803-62b9-cece-9efe6980147f@fiolino.de>
 <8c58d801-1423-2e68-5577-c11bf0485d78@fiolino.de>
Message-ID: <f866139c-00f0-21bd-d928-2919f4247c24@apache.org>

Hi,

I answered on the PR on github. The documentation is misleading:

    The copypasted snippet above is misleading, you need to read the
    whole statement, so an IllegalStateException can only happen for
    unaligned access on access modes other than get/set (so volatile or
    opaque reads): "If access is misaligned then access for
    anything*other than the get and set access modes*will result in an
    IllegalStateException.", the sentence you posted is about if it is
    atomic or not. It just says that on 32 bits, long/double are not
    atomic for normal set/get.

    P.S.: We definitely know that it works on 32 bit, the whole code of
    Lucene is full of those VarHandles :-)

And no, it doe snot mean "get-and-set". Read the whole text, it is 
definitely correct, but if you don't read everything it may mislead you. 
So it can be improved.

Uwe

Am 05.01.2023 um 13:31 schrieb Michael Kuhlmann:
> The more I think about it, the clearer is that the first line of the 
> Javadoc is contrary to the other lines:
>
> On 1/5/23 12:59, Michael Kuhlmann wrote:
>> * read write access modes for all T, with the exception of access 
>> modes get and set for long and double on 32-bit platforms.
>
> So all read write modes will work, just if it's long or double then it 
> won't work for get and for set access mode. (Or is getAndSet meant? 
> But it's not called so, it's "get and set", so two access modes, or 
> what?)
>
> Then the following lines state that even harder access modes will work 
> also for long and double.
>
> So I think this should be labeled as "getAndSet" or at least 
> "get-and-set" access mode. Currently it's very confusing.

-- 
Uwe Schindler
uschindler at apache.org  
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230105/1cf1e918/attachment.htm>

From rgiulietti at openjdk.org  Thu Jan  5 12:52:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Jan 2023 12:52:49 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <0wDRFeGAKxL76s6R0b3-R8Hi5jrupSD8nvrTMvDRt_o=.9d4574e7-deca-4663-a254-2664dcf052c4@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

One reason is that if the `byte[]` contains a non-canonical NaN then `get()` would return it.
The original code first reads an integer value and then converts it to a floating-point value, so for backward compatibility the same should happen in the new code.

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Thu Jan  5 13:09:50 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 13:09:50 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <P9Zh2tMiDglV2UBiMpl_t9Vwq3wemgehstE4XHwevQM=.3627e164-d1a0-46fe-894a-52fe60ef34e4@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

src/java.base/share/classes/java/io/Bits.java line 65:

> 63: 
> 64:     static float getFloat(byte[] b, int off) {
> 65:         // Using Float.floatToIntBits collapses NaN values to a single

comment is referring to wrong method

src/java.base/share/classes/java/io/Bits.java line 75:

> 73: 
> 74:     static double getDouble(byte[] b, int off) {
> 75:         // Using Double.doubleToLongBits collapses NaN values to a single

same here

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

PR: https://git.openjdk.org/jdk/pull/11840

From uschindler at openjdk.org  Thu Jan  5 13:14:50 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 13:14:50 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <0wDRFeGAKxL76s6R0b3-R8Hi5jrupSD8nvrTMvDRt_o=.9d4574e7-deca-4663-a254-2664dcf052c4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
 <0wDRFeGAKxL76s6R0b3-R8Hi5jrupSD8nvrTMvDRt_o=.9d4574e7-deca-4663-a254-2664dcf052c4@github.com>
Message-ID: <ys5tyjE1n2EDPdr7QJ8AsN896aiOxGYo8sTjmz3EfUs=.9fa292d9-7866-4ba0-b4fd-963bbf7794b4@github.com>

On Thu, 5 Jan 2023 12:50:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> One reason is that if the `byte[]` contains a non-canonical NaN then `get()` would return it. The original code first reads an integer value and then converts it to a floating-point value, so for backward compatibility the same should happen in the new code.

The method does not normalize, it does just this:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/native/libjava/Float.c#L34-L43

Theres also no `rawIntBitsToFloat`. You only need to take care of writing a float to outside the JDK, when it reads it in the normalization does not matter.

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

PR: https://git.openjdk.org/jdk/pull/11840

From jdk at fiolino.de  Thu Jan  5 13:16:57 2023
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Thu, 5 Jan 2023 14:16:57 +0100
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]
In-Reply-To: <f866139c-00f0-21bd-d928-2919f4247c24@apache.org>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OSdo5bytNDQVNhpnFU-yMEBbjBaJZl_mHjP02HP_Xq8=.21a2de4d-f7fe-4675-ae62-4bc16d2e080c@github.com>
 <98nL72fsyJ98-yaqfBRcnzM1fAfNq2wiCpOqTb8oFgI=.16e6c04d-e171-43d4-a566-48d1894b29b1@github.com>
 <1fd57f3c-7803-62b9-cece-9efe6980147f@fiolino.de>
 <8c58d801-1423-2e68-5577-c11bf0485d78@fiolino.de>
 <f866139c-00f0-21bd-d928-2919f4247c24@apache.org>
Message-ID: <8c485841-eb45-e38a-4dbb-16868b496e0c@fiolino.de>

Hi Uwe,

you are right! It's confusing because for cases 2-4, *atomic* access is 
explicitly mentioned but not for case 1. I overlooked the *atomic 
access* in the sentence before and got confused.

Thanks for the clarification!

On 1/5/23 13:37, Uwe Schindler wrote:
> Hi,
> 
> I answered on the PR on github. The documentation is misleading:
> 
>     The copypasted snippet above is misleading, you need to read the
>     whole statement, so an IllegalStateException can only happen for
>     unaligned access on access modes other than get/set (so volatile or
>     opaque reads): "If access is misaligned then access for
>     anything*other than the get and set access modes*will result in an
>     IllegalStateException.", the sentence you posted is about if it is
>     atomic or not. It just says that on 32 bits, long/double are not
>     atomic for normal set/get.
> 
>     P.S.: We definitely know that it works on 32 bit, the whole code of
>     Lucene is full of those VarHandles :-)
> 
> And no, it doe snot mean "get-and-set". Read the whole text, it is 
> definitely correct, but if you don't read everything it may mislead you. 
> So it can be improved.
> 
> Uwe
> 

From uschindler at openjdk.org  Thu Jan  5 13:19:53 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 5 Jan 2023 13:19:53 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <lIg6WlvwVDBNcitp30HyfkBV8ZrT2_q-EWGDxbbvpqs=.73d01dcc-780e-4476-add3-6cadf20fe08f@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

Anyways, I am fine with both variants. The new one is looking "more symmetric".

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

PR: https://git.openjdk.org/jdk/pull/11840

From jpai at openjdk.org  Thu Jan  5 13:24:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jan 2023 13:24:08 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial() [v2]
In-Reply-To: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
Message-ID: <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>

> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
> 
> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
> 
> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
> 
> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
> 
>> If the current thread does not support thread locals then
>> this method returns its {@link #initialValue} (or {@code null}
>> if the {@code initialValue} method is not overridden).
> 
> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
> 
> 
> public class Test {
>   public static void main(final String[] args) throws Exception {
>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
> 	var t = ThreadLocal.withInitial(() -> 2);
> 	System.out.println("Thread local value is " + t.get());
>     });
>   }
> }
> 
> Running this with `java --enable-preview --source 21 Test.java` returns:
> 
> Thread local value is 2
> 
> 
> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
> 
> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?

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

  Review suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11846/files
  - new: https://git.openjdk.org/jdk/pull/11846/files/9ac54a1e..110ad4ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11846&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11846&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11846.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11846/head:pull/11846

PR: https://git.openjdk.org/jdk/pull/11846

From jpai at openjdk.org  Thu Jan  5 13:24:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jan 2023 13:24:10 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial() [v2]
In-Reply-To: <rQ7h002VN4_HKbwnxBTPFVy2dDX2b6UBSZjwGFGpedM=.457793b0-75ca-456d-8878-db1482d85c17@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
 <rQ7h002VN4_HKbwnxBTPFVy2dDX2b6UBSZjwGFGpedM=.457793b0-75ca-456d-8878-db1482d85c17@github.com>
Message-ID: <SiHI3vO-TluNT8mdsE15IGvnuEOhkue_RHsYAuC-L6k=.fb724be4-c3ed-4655-8b20-193f8b01fb8e@github.com>

On Wed, 4 Jan 2023 20:14:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestion
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 128:
> 
>> 126:      * value other than {@code null}, then either {@code ThreadLocal} can be
>> 127:      * subclassed and this method overridden or {@link ThreadLocal#withInitial(Supplier)} method
>> 128:      * can be used to construct a {@code ThreadLocal}.
> 
> This looks okay but maybe slightly better to say "or the method withInitial(Supplier) can be used ...". 
> 
> I think you can probably reflow this paragraph to avoid having a mix of short and long lines.

Hello Alan, I've updated this PR with this suggested change and also formatted this new text to avoid having a mix of long and short lines.

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

PR: https://git.openjdk.org/jdk/pull/11846

From rgiulietti at openjdk.org  Thu Jan  5 13:24:51 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Jan 2023 13:24:51 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <vgha5TfvgMkcMvjgKya8I5YV32JbUNpFerd_CyBSv_w=.dfeb0c3c-da81-4205-80ed-aa556be65389@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

The point, I think, is not whether the result is normalized (this is not specified in detail in the Javadoc of `Double::longBitsToDouble` and `Float::intBitsToFloat`, so it's open to the implementation) but to use the same basic conversions as the original code, just to avoid any ever so slight difference.

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

PR: https://git.openjdk.org/jdk/pull/11840

From jcking at openjdk.org  Thu Jan  5 14:22:54 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 5 Jan 2023 14:22:54 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]
In-Reply-To: <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
Message-ID: <C387BK5BCVC-ehNGb7joa-OGOlfvC8CQUcWQjM-S7KE=.2e8fddba-73c8-4c0d-9a61-81061f9e519d@github.com>

On Sat, 17 Dec 2022 06:39:48 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete unintended addition of files from previous commit
>   
>   Signed-off-by: Justin King <jcking at google.com>

Ah okay, no problem. Thanks for the update.

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

PR: https://git.openjdk.org/jdk/pull/11604

From bpb at openjdk.org  Thu Jan  5 17:35:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 17:35:50 GMT
Subject: RFR: 8299513: Cleanup java.io [v2]
In-Reply-To: <2kBTHcbilR3nHqVvWEsKRjo3SsXtMgVpwnbQ0GTBE2M=.48c51d8c-0a33-4f7b-a07b-1c83a4d918e2@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
 <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>
 <r3xCIkBO3VWYW4CmVM5dKSgwKvele4k3wg6Ovd58v3w=.5f4f7847-deaf-4033-b034-f56be8849599@github.com>
 <2kBTHcbilR3nHqVvWEsKRjo3SsXtMgVpwnbQ0GTBE2M=.48c51d8c-0a33-4f7b-a07b-1c83a4d918e2@github.com>
Message-ID: <nNHu8Jr74DZnoSACUNjBGiOFE_V7lWh6aiHR4oKX0Rg=.7d12f31c-c2ef-4e63-93f2-ab770b83c330@github.com>

On Thu, 5 Jan 2023 12:29:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I think the casts are worth it to set `lock` only once during construction, but would be inclined to leave out the addition of `checkSize`.
>
> I have added a new proposal in the hope that the `requireNonNegative` method name and parameters should be trivial enough for users to directly understand without scrolling down. Let me know your thought on this.

That is definitely better but I would be inclined to place `requireNonNegative()` between the constructors and the instance methods.

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

PR: https://git.openjdk.org/jdk/pull/11848

From naoto at openjdk.org  Thu Jan  5 17:52:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jan 2023 17:52:56 GMT
Subject: Integrated: 8299292: Missing elements in aliased String array
In-Reply-To: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
References: <SVtGdF1SLUWQ37QXRlR7al-5VSjd2pBa8MtVQ0_7oI4=.a90bb091-57e0-4855-9a0a-5cb55f928656@github.com>
Message-ID: <DSDFWhqKljxVJk8d7XB_CcItxH8XGXNj3BvrDv_Afvk=.bdcf8bf3-542d-42ef-b882-6e72948fa615@github.com>

On Wed, 4 Jan 2023 19:57:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR changed the inheritance mechanism a bit with this change: https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the duplication of data. This revealed an issue in CLDRConverter buildtool that it was not capable of inheriting the partially populated, aliased elements in an array object. This changeset also removed the unused logging code.

This pull request has now been integrated.

Changeset: a49ccb95
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a49ccb959b7e50ee67b1ab4feca47c34bdbc14fe
Stats:     16 lines in 1 file changed: 5 ins; 4 del; 7 mod

8299292: Missing elements in aliased String array

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.org/jdk/pull/11851

From bpb at openjdk.org  Thu Jan  5 18:00:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 18:00:50 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
 [v2]
In-Reply-To: <kS945incHKbBRmH7AveADVhqGEdByoHg3GkjMQrdTFU=.076a9208-5072-4d16-8578-2ebc25bfea90@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <xZlHsxkdR_WCTtmQJqWy9B-ICHP17g6VT2gnoNpRtOo=.bfea6f74-c5ae-4fe5-8d90-6797f15c3153@github.com>
 <KUnrYlgWXlfusP2YeFi_1Y93sYMcUw3d76EVkWW50qY=.55cda048-aa5f-41d3-b3ac-5c9ef0777a09@github.com>
 <Mu4VopTwTyI7l0YzjfJti6AU-Z2QCxMIXU4CiGjSy2o=.553fdd43-a304-4328-8905-80f3101de11c@github.com>
 <TIrzYXL3ipVw7JHUeDUPqKxenDuao-hc7y8p9_Twlv8=.4790cb63-6fa3-4493-b7a4-904911a64d75@github.com>
 <kS945incHKbBRmH7AveADVhqGEdByoHg3GkjMQrdTFU=.076a9208-5072-4d16-8578-2ebc25bfea90@github.com>
Message-ID: <a5Tg39XHhgbkEunvrpQ2zNEawgfFj4BooLE1i8r9hF4=.b9016aa5-8b12-416b-97fd-be06c635c432@github.com>

On Thu, 5 Jan 2023 12:09:46 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>>> Indeed there are at least four regression test failures with this as-is:
>>> 
>>> * java/io/InputStream/ReadParams.java
>>> * java/io/OutputStream/WriteParams.java
>>> * java/io/Writer/WriteParams.java
>>> * java/nio/channels/FileChannel/Transfer2GPlus.java
>> 
>> The java/io tests run in tier2 and I think the GHA only run tier1.
>
> Fixed along with copyright year

The regression tests now pass.

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

PR: https://git.openjdk.org/jdk/pull/11849

From alanb at openjdk.org  Thu Jan  5 18:08:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jan 2023 18:08:51 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
 [v2]
In-Reply-To: <6FULiwBHG9hpGGwhBct1_MgR4OmdNRwA9zXexZIXUBs=.f66dc334-606f-4040-acdb-db6ce11429db@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <6FULiwBHG9hpGGwhBct1_MgR4OmdNRwA9zXexZIXUBs=.f66dc334-606f-4040-acdb-db6ce11429db@github.com>
Message-ID: <H31dTVCV254M0o3a5SjOfieDaiaBizqK2AVFIv_l2K4=.fbae33c3-c9e1-4853-8727-10808bea3bdc@github.com>

On Thu, 5 Jan 2023 12:14:05 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299600: Use checkFromIndexSize in PipedWriter.java
>  - 8299600: Use checkFromIndexSize

Version 8af035f5 looks right and I see that @bplb has run the tests.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11849

From bpb at openjdk.org  Thu Jan  5 18:08:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 18:08:51 GMT
Subject: RFR: 8299600: Use Objects.check*() where appropriate in java.io
 [v2]
In-Reply-To: <6FULiwBHG9hpGGwhBct1_MgR4OmdNRwA9zXexZIXUBs=.f66dc334-606f-4040-acdb-db6ce11429db@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
 <6FULiwBHG9hpGGwhBct1_MgR4OmdNRwA9zXexZIXUBs=.f66dc334-606f-4040-acdb-db6ce11429db@github.com>
Message-ID: <g6kDtNbwodOm3RY6yQdj6hMROQv_FyZSKJ1ZZOyjakI=.6a375a78-0ee3-45e5-a0c5-47c3ac00eb19@github.com>

On Thu, 5 Jan 2023 12:14:05 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299600: Use checkFromIndexSize in PipedWriter.java
>  - 8299600: Use checkFromIndexSize

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11849

From asemenyuk at openjdk.org  Thu Jan  5 20:21:42 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 5 Jan 2023 20:21:42 GMT
Subject: RFR: 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed
 AddLauncherTest.bug8230933
Message-ID: <mYJaZI6qEi_uWlrL4JEljwlsUsjrDwZ__ESSCZfnHYg=.72f840bd-72fe-43af-a9ae-2d6d3e567d8b@github.com>

8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933

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

Commit messages:
 - Comment fixed
 - 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933

Changes: https://git.openjdk.org/jdk/pull/11868/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299278
  Stats: 47 lines in 2 files changed: 41 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11868.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11868/head:pull/11868

PR: https://git.openjdk.org/jdk/pull/11868

From mchung at openjdk.org  Thu Jan  5 20:53:50 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Jan 2023 20:53:50 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create WMTE
 in opposite order
Message-ID: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>

Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

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

Commit messages:
 - 8299183: Invokers.checkExactType passes parameters to create WMTE in opposite order

Changes: https://git.openjdk.org/jdk/pull/11870/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299183
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11870/head:pull/11870

PR: https://git.openjdk.org/jdk/pull/11870

From duke at openjdk.org  Thu Jan  5 22:20:32 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 5 Jan 2023 22:20:32 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
Message-ID: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>

Added the missing copyright header

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

Commit messages:
 - Fix date, remove classpath
 - Add copyright header

Changes: https://git.openjdk.org/jdk/pull/11854/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11854&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299617
  Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11854.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11854/head:pull/11854

PR: https://git.openjdk.org/jdk/pull/11854

From naoto at openjdk.org  Thu Jan  5 22:20:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jan 2023 22:20:36 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
In-Reply-To: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
Message-ID: <xeR5LXlciSvXGCpbRmXmZUNTxhtvZWNXiwd37FWUK8w=.9ab78e02-bef2-4ad9-9898-956c0782a575@github.com>

On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Added the missing copyright header

Changes requested by naoto (Reviewer).

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 2:

> 1: #
> 2: # Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

This file is not new, so I'd use `2001` as the year created, which is borrowed from the test body `CurrencyFormat.java`.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 9:

> 7: # published by the Free Software Foundation.  Oracle designates this
> 8: # particular file as subject to the "Classpath" exception as provided
> 9: # by Oracle in the LICENSE file that accompanied this code.

Classpath exception is not applicable to tests.

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

PR: https://git.openjdk.org/jdk/pull/11854

From duke at openjdk.org  Thu Jan  5 22:20:37 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 5 Jan 2023 22:20:37 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
In-Reply-To: <xeR5LXlciSvXGCpbRmXmZUNTxhtvZWNXiwd37FWUK8w=.9ab78e02-bef2-4ad9-9898-956c0782a575@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
 <xeR5LXlciSvXGCpbRmXmZUNTxhtvZWNXiwd37FWUK8w=.9ab78e02-bef2-4ad9-9898-956c0782a575@github.com>
Message-ID: <Pr7a6OD8Pw0MRfnHqZLZLLXp_CUCVWl1bMwOwifcRys=.83c90f6b-fdca-40f1-b339-40b8c958f8ec@github.com>

On Wed, 4 Jan 2023 23:02:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Added the missing copyright header
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 9:
> 
>> 7: # published by the Free Software Foundation.  Oracle designates this
>> 8: # particular file as subject to the "Classpath" exception as provided
>> 9: # by Oracle in the LICENSE file that accompanied this code.
> 
> Classpath exception is not applicable to tests.

Did not know that, thank you. Made the fixes for this and your previous comment.

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

PR: https://git.openjdk.org/jdk/pull/11854

From iris at openjdk.org  Thu Jan  5 22:52:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Jan 2023 22:52:57 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
In-Reply-To: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
Message-ID: <MLYRhvSjBxkNFujey5PMVIqKKSk6zLD3AZdEWbSonDM=.cc02ddd6-e71a-4182-b9c7-4c93e0543dc3@github.com>

On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Added the missing copyright header

Provided GPL license appear to match the standard template available here:

https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-header

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11854

From iris at openjdk.org  Thu Jan  5 22:59:50 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Jan 2023 22:59:50 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order
In-Reply-To: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
Message-ID: <jyDTxPB8w9CsP70zivr7cEtVu1rvnrrgZq4XzCoAL7U=.5e1ca04b-3de2-45db-a313-b7ef8366d9db@github.com>

On Thu, 5 Jan 2023 20:45:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

Parameter order for method invocation now matches method declaration on line 521.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11870

From bpb at openjdk.org  Thu Jan  5 23:13:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Jan 2023 23:13:49 GMT
Subject: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <BjevMMDo3RAnGMKDUhF8whohpnvVv1CRo8gvkF4XMCs=.81a36983-dedd-4627-9aa3-c6e40446ece7@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11783

From naoto at openjdk.org  Fri Jan  6 00:13:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jan 2023 00:13:50 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
In-Reply-To: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
Message-ID: <IQwp_bUfGjcPuX0ues15HgBTKoU84LSBns6Qg7wwh38=.e233f7ba-21bc-4296-89e6-0c18f4d616d9@github.com>

On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Added the missing copyright header

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11854

From jpai at openjdk.org  Fri Jan  6 00:47:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jan 2023 00:47:48 GMT
Subject: RFR: 8299617: CurrencySymbols.properties is missing the copyright
 notice
In-Reply-To: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
Message-ID: <RAvXsuJ2uPFYXHcZe_qYeTErn9R7Hjrem5Uc9M7YGgE=.9660b2df-642e-4c32-bd61-eb7683134c60@github.com>

On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Added the missing copyright header

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11854

From jpai at openjdk.org  Fri Jan  6 01:08:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jan 2023 01:08:48 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order
In-Reply-To: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
Message-ID: <u0yZybemlAOxNkYmKqwn4ArJgI5yPJFMvz8nufB1k0Y=.84eb95b0-b192-4f15-ad7e-4410855baeb9@github.com>

On Thu, 5 Jan 2023 20:45:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

Hello Mandy, this looks good to me. The copyright year on the file will need an update.

There's another call to this `newWrongMethodTypeException` method on line 515 and I am guessing that one is already passing the params in the correct order. If I go by that same logic, then there appears to be a direct construction of `WrongMethodTypeException` on line 497 and I suspect the `String` passed to it is perhaps using the wrong order? It currently says:


if (handle.hasInvokeExactBehavior() && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
     throw new WrongMethodTypeException("expected " + handle.accessModeType(ad.type) + " but found "
                    + ad.symbolicMethodTypeExact);
}

Should it instead say:

if (handle.hasInvokeExactBehavior() && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
    throw new WrongMethodTypeException("expected " + ad.symbolicMethodTypeExact + " but found "
                    + handle.accessModeType(ad.type));
}

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

PR: https://git.openjdk.org/jdk/pull/11870

From duke at openjdk.org  Fri Jan  6 02:45:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 02:45:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from a
 constructor
Message-ID: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>

This PR adds a new lint warning category `this-escape`.

It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.

A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
* Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
* Some constructor `B()` of `B` invokes `A()` as its superclass constructor
* During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly

In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.

Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.

>From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.

For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.

More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.

Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.

Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.

**Patch Navigation Guide**

* Non-trivial compiler changes:
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
    * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`

* Javadoc additions of `@implNote`:

    * `src/java.base/share/classes/java/io/PipedReader.java`
    * `src/java.base/share/classes/java/io/PipedWriter.java`
    * `src/java.base/share/classes/java/lang/Throwable.java`
    * `src/java.base/share/classes/java/util/ArrayDeque.java`
    * `src/java.base/share/classes/java/util/EnumMap.java`
    * `src/java.base/share/classes/java/util/HashSet.java`
    * `src/java.base/share/classes/java/util/Hashtable.java`
    * `src/java.base/share/classes/java/util/LinkedList.java`
    * `src/java.base/share/classes/java/util/TreeMap.java`
    * `src/java.base/share/classes/java/util/TreeSet.java`

* New unit tests
    * `test/langtools/tools/javac/warnings/ThisEscape/*.java`

* **Everything else** is just adding `@SuppressWarnings("this-escape")`

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

Commit messages:
 - Remove trailing whitespace.
 - Some documentation tweaks.
 - Treat method references like the equivalent lambda.
 - Fix bug where initializers could generate duplicate warnings.
 - Javadoc fix.
 - Add ThisEscape.html doc note and link the new @implNote's to it.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - Add more @SuppressWarnings("this-escape") annotations.
 - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283

Changes: https://git.openjdk.org/jdk/pull/11874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8015831
  Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From dholmes at openjdk.org  Fri Jan  6 04:51:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Jan 2023 04:51:00 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Hi Archie,

The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

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

PR: https://git.openjdk.org/jdk/pull/11874

From jpai at openjdk.org  Fri Jan  6 06:04:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jan 2023 06:04:52 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial() [v2]
In-Reply-To: <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
 <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
Message-ID: <szBVi88WdN2y6-ooTUSMgSoG_zDllHiM97l_VWM2PYg=.2cb1a251-946c-4388-8655-fdfe2d2af7c5@github.com>

On Thu, 5 Jan 2023 13:24:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
>> 
>> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
>> 
>> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
>> 
>> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
>> 
>>> If the current thread does not support thread locals then
>>> this method returns its {@link #initialValue} (or {@code null}
>>> if the {@code initialValue} method is not overridden).
>> 
>> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
>> 
>> 
>> public class Test {
>>   public static void main(final String[] args) throws Exception {
>>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
>> 	var t = ThreadLocal.withInitial(() -> 2);
>> 	System.out.println("Thread local value is " + t.get());
>>     });
>>   }
>> }
>> 
>> Running this with `java --enable-preview --source 21 Test.java` returns:
>> 
>> Thread local value is 2
>> 
>> 
>> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
>> 
>> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestion

I've created a CSR for this change https://bugs.openjdk.org/browse/JDK-8299714

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

PR: https://git.openjdk.org/jdk/pull/11846

From jpai at openjdk.org  Fri Jan  6 06:42:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Jan 2023 06:42:58 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator
Message-ID: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>

Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

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

Commit messages:
 - 8297306: Incorrect brackets in Javadoc for a constructor of IteratorSpliterator

Changes: https://git.openjdk.org/jdk/pull/11876/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11876&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297306
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11876.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11876/head:pull/11876

PR: https://git.openjdk.org/jdk/pull/11876

From alanb at openjdk.org  Fri Jan  6 07:53:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 07:53:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <Hnu2IeLr21reuXeHYgIlKiNCwQ9zJLeg9dykcL_Y8KM=.67209ee1-a778-4bae-a7a8-d61e860f7b23@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan  6 09:16:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 09:16:48 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator
In-Reply-To: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
Message-ID: <BwpEfBpJ36qg97Zctx7fMR3c9NY2YUMmEDLl9rPExME=.a62dde7b-8015-40a4-bb34-cac654bef4ec@github.com>

On Fri, 6 Jan 2023 06:35:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

This looks okay although this is not a public class so it doesn't appear in the generated javadoc.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11876

From alanb at openjdk.org  Fri Jan  6 10:13:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 10:13:49 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial() [v2]
In-Reply-To: <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
 <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
Message-ID: <FOQjC1WO9WTHJCDLYYdTkS0OsfaS3GVh00WlVe30Q8Q=.86856003-1028-4de3-b9b9-f8dfa7418831@github.com>

On Thu, 5 Jan 2023 13:24:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
>> 
>> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
>> 
>> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
>> 
>> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
>> 
>>> If the current thread does not support thread locals then
>>> this method returns its {@link #initialValue} (or {@code null}
>>> if the {@code initialValue} method is not overridden).
>> 
>> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
>> 
>> 
>> public class Test {
>>   public static void main(final String[] args) throws Exception {
>>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
>> 	var t = ThreadLocal.withInitial(() -> 2);
>> 	System.out.println("Thread local value is " + t.get());
>>     });
>>   }
>> }
>> 
>> Running this with `java --enable-preview --source 21 Test.java` returns:
>> 
>> Thread local value is 2
>> 
>> 
>> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
>> 
>> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestion

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11846

From shade at openjdk.org  Fri Jan  6 11:31:57 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Jan 2023 11:31:57 GMT
Subject: Integrated: 8294403: [REDO] make test should report only on executed
 tests
In-Reply-To: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
References: <IoPHrSiWgA_jJjm1pCnfaTTr8xiFbyYN8Cq3liJWXjo=.c340acc6-3466-457b-82e0-b2c1ffd1cebd@github.com>
Message-ID: <6JKgG4vzz9qYTvO9IuyiD3Zav0nQxyGZTq1hua9NYLg=.86c99571-21b4-4e32-bacf-0c83cee96495@github.com>

On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time.
> 
> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg.
> 
> Motivational improvements:
> 
> 
> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java
> 
> # Default JDK tree
> 
> # Baseline
> real	0m9.086s
> user	0m22.857s
> sys	0m4.202s
> 
> # Patched
> real	0m6.406s   ; +40% faster
> user	0m17.156s
> sys	0m3.193s
> 
> # +100K fuzzer tests in tree
> 
> # Baseline
> real	3m1.997s
> user	3m16.643s
> sys	0m10.490s
> 
> # Patched
> real	0m8.919s   ; 20x faster
> user	0m17.904s
> sys	0m4.860s
> 
> 
> Additional testing:
>  - [x] Ad-hoc timing tests (see above)
>  - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
>  - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
>  - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1

This pull request has now been integrated.

Changeset: 5598acc3
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5598acc345dbd6f806145157ae6f7c591340a1d1
Stats:     13 lines in 3 files changed: 11 ins; 0 del; 2 mod

8294403: [REDO] make test should report only on executed tests

Reviewed-by: erikj, dholmes, jpai, djelinski

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

PR: https://git.openjdk.org/jdk/pull/11824

From alanb at openjdk.org  Fri Jan  6 14:00:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 14:00:52 GMT
Subject: RFR: 8299513: Cleanup java.io [v2]
In-Reply-To: <nNHu8Jr74DZnoSACUNjBGiOFE_V7lWh6aiHR4oKX0Rg=.7d12f31c-c2ef-4e63-93f2-ab770b83c330@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <WwpuxeE2J5hlrwGkE8X5wJOpl0LCVlbxj6j-GCcPZfU=.27c979da-8a53-4e89-ace7-5305fba51ea0@github.com>
 <2NZo3Ve-SeyOMN_R9Un9l8HBEkKi8yOIfNPVqWfsHto=.2f6f5766-3078-43ad-89e5-e97fcebf9e04@github.com>
 <r3xCIkBO3VWYW4CmVM5dKSgwKvele4k3wg6Ovd58v3w=.5f4f7847-deaf-4033-b034-f56be8849599@github.com>
 <2kBTHcbilR3nHqVvWEsKRjo3SsXtMgVpwnbQ0GTBE2M=.48c51d8c-0a33-4f7b-a07b-1c83a4d918e2@github.com>
 <nNHu8Jr74DZnoSACUNjBGiOFE_V7lWh6aiHR4oKX0Rg=.7d12f31c-c2ef-4e63-93f2-ab770b83c330@github.com>
Message-ID: <V2kjorG3LyRnOSxo0Q0iOeqzzPR1_MTsLZG3WSuSs5g=.a013a4a5-51af-49a0-a49d-326ba3c6d864@github.com>

On Thu, 5 Jan 2023 17:33:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I have added a new proposal in the hope that the `requireNonNegative` method name and parameters should be trivial enough for users to directly understand without scrolling down. Let me know your thought on this.
>
> That is definitely better but I would be inclined to place `requireNonNegative()` between the constructors and the instance methods.

It's a bit better but I think the original code is clearer/simpler, in particular it makes it clear that buf is used as the lock object. I realise this is very subjective but I think my preference would be to prefer that part and just make `buf` final.

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

PR: https://git.openjdk.org/jdk/pull/11848

From alanb at openjdk.org  Fri Jan  6 14:06:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 14:06:49 GMT
Subject: RFR: 8299513: Cleanup java.io [v2]
In-Reply-To: <_WD-EQq5LaItD3HwNjjZxii8pk_AJbiadmVJJ0I1Xlc=.acda7a44-e1f2-42bc-935b-869250fb1581@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <_WD-EQq5LaItD3HwNjjZxii8pk_AJbiadmVJJ0I1Xlc=.acda7a44-e1f2-42bc-935b-869250fb1581@github.com>
Message-ID: <X8G7MuFa90HQT85hAaUXCxON2Hyn-TRW2SBhro5Kjfw=.96699d1c-f801-4f98-b735-c796ddef6e49@github.com>

On Thu, 5 Jan 2023 12:34:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework StringWriter constructor

I see "nonnegative" has been changed to "non-negative" in several places. I believe both are correct and there are examples of both in javadoc and exception messages.

This is probably the first change to these files in 2023 so you'll need to bump the copyright year on most of them

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

PR: https://git.openjdk.org/jdk/pull/11848

From mcimadamore at openjdk.org  Fri Jan  6 14:18:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Jan 2023 14:18:42 GMT
Subject: [jdk20] RFR: 8299740: CaptureCallState is missing @Preview annotation
Message-ID: <PJGG_NU96AGG-bWNSDKTYu-b8XUOTC5N59kp118i4jE=.5368f4b3-f2c0-4551-ac5c-696db6da82d8@github.com>

This patch adds `@Preview` to the CaptureCallState interface.

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

Commit messages:
 - Add @Preview annotation to CaptureCallState

Changes: https://git.openjdk.org/jdk20/pull/86/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=86&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299740
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/86/head:pull/86

PR: https://git.openjdk.org/jdk20/pull/86

From alanb at openjdk.org  Fri Jan  6 14:30:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 14:30:51 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v6]
In-Reply-To: <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <OKkFmGY6xYnBoK-imd3hZSKNW5XEkzdiMJEROJcthyg=.2a165794-3c1d-48d4-8a44-7bdcc4e266b0@github.com>
Message-ID: <jPSQZ3QbfIfGfoHiXrqnWS2eNnbtUufNlKvFJgLxX5Q=.bd6c7890-4292-4f15-addb-5578651a267b@github.com>

On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use canonical NaN values also for read

test/jdk/java/io/Bits/ReadWriteValues.java line 29:

> 27:  * @compile/module=java.base java/io/BitsProxy.java
> 28:  * @run junit/othervm --add-opens java.base/java.io=ALL-UNNAMED ReadWriteValues
> 29:  */

I see you've figured out to test with a helper classes in java.io, good! 

Did you mean to add a test tag to BitsProxy? That will cause jtreg to treat it as a test in its own right and it will fail.

For ReadWriteValues, the --add-opens isn't needed as the test no longer does any deep reflection on APIs in that package. You can add a bug tag too, which should give you:


/*
 * @test
 * @bug 8299576
 * @summary Verify that reads and writes of primitives are correct
 * @compile/module=java.base java/io/BitsProxy.java
 * @run junit ReadWriteValues
 */

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

PR: https://git.openjdk.org/jdk/pull/11840

From alanb at openjdk.org  Fri Jan  6 14:32:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 14:32:51 GMT
Subject: [jdk20] RFR: 8299740: CaptureCallState is missing @Preview
 annotation
In-Reply-To: <PJGG_NU96AGG-bWNSDKTYu-b8XUOTC5N59kp118i4jE=.5368f4b3-f2c0-4551-ac5c-696db6da82d8@github.com>
References: <PJGG_NU96AGG-bWNSDKTYu-b8XUOTC5N59kp118i4jE=.5368f4b3-f2c0-4551-ac5c-696db6da82d8@github.com>
Message-ID: <hgSLhSJitii6mxDxsG4cHBsCiqJ-h05Lk4PvrGwdRHM=.3d46d44f-ba3d-47f2-8fa5-bc212a3df39b@github.com>

On Fri, 6 Jan 2023 14:10:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds `@Preview` to the CaptureCallState interface.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/86

From duke at openjdk.org  Fri Jan  6 14:51:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 14:51:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
Message-ID: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>

On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?

Hi @dholmes-ora,

The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.

Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.

Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 

> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.

Hi @AlanBateman,

As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.

> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.

Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?

If this is generally agreed as a better route then let me know and I'll update the patch.

Thanks for both of your comments.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Fri Jan  6 14:56:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Jan 2023 14:56:03 GMT
Subject: [jdk20] Integrated: 8299740: CaptureCallState is missing @Preview
 annotation
In-Reply-To: <PJGG_NU96AGG-bWNSDKTYu-b8XUOTC5N59kp118i4jE=.5368f4b3-f2c0-4551-ac5c-696db6da82d8@github.com>
References: <PJGG_NU96AGG-bWNSDKTYu-b8XUOTC5N59kp118i4jE=.5368f4b3-f2c0-4551-ac5c-696db6da82d8@github.com>
Message-ID: <WcTTKYbKikKmOp2sn2hS6bo4_WWB97iFC4ulC05bJR4=.c02da439-958f-492a-b28e-eb6bf8583d3c@github.com>

On Fri, 6 Jan 2023 14:10:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds `@Preview` to the CaptureCallState interface.

This pull request has now been integrated.

Changeset: 5eee2a07
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/5eee2a07f5db5979149cc3e96d4f608ed135a7b3
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8299740: CaptureCallState is missing @Preview annotation

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk20/pull/86

From alanb at openjdk.org  Fri Jan  6 15:41:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jan 2023 15:41:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
Message-ID: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>

On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
> 
> If this is generally agreed as a better route then let me know and I'll update the patch.

Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Fri Jan  6 15:57:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Jan 2023 15:57:50 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_mLssKO7VlglPgP2sf3S1seKgyuJazeTrpnURCpxQk=.7e318df2-ef54-484c-9cb2-bea1100fe949@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one).

See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions:

https://bugs.openjdk.org/browse/JDK-8286374

They all refer to this:

https://bugs.openjdk.org/browse/JDK-8244681

Which was submitted as a separate javac-only PR:
https://github.com/openjdk/jdk/pull/8599

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

PR: https://git.openjdk.org/jdk/pull/11874

From iris at openjdk.org  Fri Jan  6 17:07:49 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 6 Jan 2023 17:07:49 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator
In-Reply-To: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
Message-ID: <ebP7RjqB5R-uVZvx7KgFll-ZikNw-5Hzuw_hPDNZCFM=.22673714-80bb-4e56-9750-a03198c955be@github.com>

On Fri, 6 Jan 2023 06:35:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11876

From duke at openjdk.org  Fri Jan  6 17:38:54 2023
From: duke at openjdk.org (Markus KARG)
Date: Fri, 6 Jan 2023 17:38:54 GMT
Subject: Integrated: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be
 16384
In-Reply-To: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
References: <LD1mjUQ5E01OMV3QicgbhdeCMxWVbnbSmGbVmjexW9Y=.214c934a-7a21-46ad-b8c2-9920302e47d7@github.com>
Message-ID: <aH44F3olT25sWo8eC9cgWFWh0yG3xrhs4UU2D1FEBN4=.a51dd522-d20f-4255-b26e-efdcb1b45f8f@github.com>

On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG <duke at openjdk.org> wrote:

> I/O had always been much slower than CPU and memory access, and thanks to physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory cache on or nearby a CPU core, the distance between CPU core and I/O device cannot get reduced much: It will stay "far" away.
> Due to this simple logic (and other factors), the spread between performance of CPU and memory access on one hand, and performance of I/O on the other hand, increases with every new CPU generation.
> As a consequence, internal adjustment factors of the JDK need to get revised from time to time to ensure optimum performance and each hardware generation.
> 
> One such factor is the size of the temporary transfer buffer used internally by `InputStream::transferTo`.
> Since its introduction with JDK 9 many years (hence hardware generations) have passed, so it's time to check the appropriateness of that buffer's size.
> 
> Using JMH on a typical, modern cloud platform, it was proven that the current 8K buffer is (much) too small on modern hardware:
> The small buffer clearly stands in the way of faster transfers.
> The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` operation on JDK 21 could be doubled (!) by only doubling the buffer size from 8K to 16K, which seems to be a considerable and cheap deal.
> Doubling the buffer even more shows only marginal improvements of approx. 1% to 3% per duplication of size, which does not justify additional memory consumption.
> 
> 
> TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ? 47.057 ops/s
> TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ? 93.337 ops/s
> TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ? 89.555 ops/s
> TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ? 96.623 ops/s
> TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ? 40.798 ops/s
> 
> 
> Even on small or limited platforms, an investment of 8K additonal temporary buffer is very cheap and very useful, as it doubles the performance of `InputStream::transferTo`, in particular for legacy (non-NIO) applications still using `FileInputStream` and `ByteArrayOutputStream`.
> I dare to say, even if not proven, that is a very considerable (possibly the major) number of existing applications, as NIO was only adopted gradually by programmers.
> 
> Due to the given reasons, it should be approporiate to change `DEFAULT_BUFFER_SIZE` from 8192 to 16384.

This pull request has now been integrated.

Changeset: 3dcf7001
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3dcf7001611aa66a7a1b4a01dfa6dfb296e70da1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8299336: InputStream::DEFAULT_BUFFER_SIZE should be 16384

Reviewed-by: bpb

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

PR: https://git.openjdk.org/jdk/pull/11783

From naoto at openjdk.org  Fri Jan  6 17:46:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jan 2023 17:46:50 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator
In-Reply-To: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
Message-ID: <5iVJLueXpY5UZOaNrD8HccBhHCn7mxfg8veqjQybqYU=.67d71ee7-2247-435c-be32-31201db64d34@github.com>

On Fri, 6 Jan 2023 06:35:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

Hi Jai, the fix looks good as it stands. I found another location that has the same issue, i.e., `Spliterators.spliterator(Collection<? extends T> c, int characteristics)`. This is a public method so more relevant to the users IMO. I'd apply the same changes to it as well.

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

PR: https://git.openjdk.org/jdk/pull/11876

From duke at openjdk.org  Fri Jan  6 17:51:09 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 17:51:09 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs
Message-ID: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>

Removed constructors of primitive wrapper classes (deprecated for removal) for the following
- _java.text.ChoiceFormat_
- _java.text.MessageFormat_ 

Replaced with .valueOf() method

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

Commit messages:
 - Fix ChoiceFormat
 - Fix MessageFormat

Changes: https://git.openjdk.org/jdk/pull/11884/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299500
  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11884.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11884/head:pull/11884

PR: https://git.openjdk.org/jdk/pull/11884

From naoto at openjdk.org  Fri Jan  6 18:39:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jan 2023 18:39:59 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs
In-Reply-To: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
Message-ID: <iX8IMvszZjzmJ5EculSvF7l8bLvzg9W0IlI5QEV2h-8=.c5262d41-6635-4aa9-a803-edecc50ab718@github.com>

On Fri, 6 Jan 2023 17:42:53 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) for the following
> - _java.text.ChoiceFormat_
> - _java.text.MessageFormat_ 
> 
> Replaced with .valueOf() method

LGTM

src/java.base/share/classes/java/text/MessageFormat.java line 313:

> 311:  * String result = mf.format( objs );
> 312:  * // result now equals "3.14, 3.1"
> 313:  * objs = null;

Although this is not related to this fix, this line `objs = null` is not needed (and is confusing as an example snippet). I'd remove this.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11884

From naoto at openjdk.org  Fri Jan  6 18:45:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jan 2023 18:45:54 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
Message-ID: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>

Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.

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

Commit messages:
 - JIRA issue number fix
 - Fixing another test
 - Fixed the default in test
 - Disable JLine

Changes: https://git.openjdk.org/jdk20/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299689
  Stats: 34 lines in 3 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk20/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/88/head:pull/88

PR: https://git.openjdk.org/jdk20/pull/88

From duke at openjdk.org  Fri Jan  6 18:51:12 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 18:51:12 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs [v2]
In-Reply-To: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
Message-ID: <wobn2XQst0tmpvaiMQ26klTl7lomDzJMI1xkD3pCWzo=.08750e6a-47a5-49ee-994e-eeaf9576b0c6@github.com>

> Removed constructors of primitive wrapper classes (deprecated for removal) for the following
> - _java.text.ChoiceFormat_
> - _java.text.MessageFormat_ 
> 
> Replaced with .valueOf() method

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

  Remove objs=null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11884/files
  - new: https://git.openjdk.org/jdk/pull/11884/files/d6332659..cf833aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11884&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11884&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11884

From duke at openjdk.org  Fri Jan  6 18:51:13 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 18:51:13 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs [v2]
In-Reply-To: <iX8IMvszZjzmJ5EculSvF7l8bLvzg9W0IlI5QEV2h-8=.c5262d41-6635-4aa9-a803-edecc50ab718@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
 <iX8IMvszZjzmJ5EculSvF7l8bLvzg9W0IlI5QEV2h-8=.c5262d41-6635-4aa9-a803-edecc50ab718@github.com>
Message-ID: <_mekbW1uR6F5k3_CrWFZiIpp_hN-rHW6t39mAQ1A4fA=.0e09cd1c-402e-479c-b292-559c66798069@github.com>

On Fri, 6 Jan 2023 18:36:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove objs=null
>
> src/java.base/share/classes/java/text/MessageFormat.java line 313:
> 
>> 311:  * String result = mf.format( objs );
>> 312:  * // result now equals "3.14, 3.1"
>> 313:  * objs = null;
> 
> Although this is not related to this fix, this line `objs = null` is not needed (and is confusing as an example snippet). I'd remove this.

Makes sense, just got rid of it

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

PR: https://git.openjdk.org/jdk/pull/11884

From duke at openjdk.org  Fri Jan  6 19:03:00 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 19:03:00 GMT
Subject: RFR: 8299501: Usage of constructors of primitive wrapper classes
 should be avoided in java.util API docs
Message-ID: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>

Removed constructors of primitive wrapper classes (deprecated for removal) in  _java.util.Arrays_

Replaced with .valueOf() method

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

Commit messages:
 - Fix java.util.Arrays

Changes: https://git.openjdk.org/jdk/pull/11885/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11885&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299501
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11885.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11885/head:pull/11885

PR: https://git.openjdk.org/jdk/pull/11885

From lancea at openjdk.org  Fri Jan  6 19:13:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 6 Jan 2023 19:13:55 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs [v2]
In-Reply-To: <wobn2XQst0tmpvaiMQ26klTl7lomDzJMI1xkD3pCWzo=.08750e6a-47a5-49ee-994e-eeaf9576b0c6@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
 <wobn2XQst0tmpvaiMQ26klTl7lomDzJMI1xkD3pCWzo=.08750e6a-47a5-49ee-994e-eeaf9576b0c6@github.com>
Message-ID: <uIAkIHnOJw5iu6knQRY39a52YjCLjPOXlpIM6dxa6-o=.a69f7743-2193-4958-ac97-fef7a6900547@github.com>

On Fri, 6 Jan 2023 18:51:12 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) for the following
>> - _java.text.ChoiceFormat_
>> - _java.text.MessageFormat_ 
>> 
>> Replaced with .valueOf() method
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove objs=null

Looks fine Justin, thanks for doing this.

At some point we should convert the examples to be a snippet which we can do at a later time

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11884

From duke at openjdk.org  Fri Jan  6 19:22:51 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 19:22:51 GMT
Subject: RFR: 8299500: Usage of constructors of primitive wrapper classes
 should be avoided in java.text API docs [v2]
In-Reply-To: <uIAkIHnOJw5iu6knQRY39a52YjCLjPOXlpIM6dxa6-o=.a69f7743-2193-4958-ac97-fef7a6900547@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
 <wobn2XQst0tmpvaiMQ26klTl7lomDzJMI1xkD3pCWzo=.08750e6a-47a5-49ee-994e-eeaf9576b0c6@github.com>
 <uIAkIHnOJw5iu6knQRY39a52YjCLjPOXlpIM6dxa6-o=.a69f7743-2193-4958-ac97-fef7a6900547@github.com>
Message-ID: <Mf0OWJahbc-LR97Q9Y6sw3o_9uV9iL-YpXenS9Y274A=.64c6f97e-2020-418e-bffa-4939dd0dd780@github.com>

On Fri, 6 Jan 2023 19:10:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Looks fine Justin, thanks for doing this.
> 
> At some point we should convert the examples to be a snippet which we can do at a later time

Sounds good ?

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

PR: https://git.openjdk.org/jdk/pull/11884

From naoto at openjdk.org  Fri Jan  6 19:27:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jan 2023 19:27:52 GMT
Subject: RFR: 8299501: Usage of constructors of primitive wrapper classes
 should be avoided in java.util API docs
In-Reply-To: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
References: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
Message-ID: <uybDtKcg3A_GRD96sEh56HdIq8h-6hGWbxM13frhkc8=.a4201cec-e2ab-462e-934d-c239583c9166@github.com>

On Fri, 6 Jan 2023 18:54:07 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) in  _java.util.Arrays_
> 
> Replaced with .valueOf() method

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11885

From lancea at openjdk.org  Fri Jan  6 19:32:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 6 Jan 2023 19:32:54 GMT
Subject: RFR: 8299501: Usage of constructors of primitive wrapper classes
 should be avoided in java.util API docs
In-Reply-To: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
References: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
Message-ID: <qV57a3x9qcNArhqfw8aNA699Yl-ALVR5zYuco0TnVu4=.8a799f78-a6a1-496a-b138-1f8b05160d2f@github.com>

On Fri, 6 Jan 2023 18:54:07 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) in  _java.util.Arrays_
> 
> Replaced with .valueOf() method

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11885

From sviswanathan at openjdk.org  Fri Jan  6 19:48:56 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Jan 2023 19:48:56 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
 <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
 <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>
Message-ID: <mRNLfkt-X2yZ0IVQ_Hc6RtQz5E10Z8ZUdRPlMUFq4ns=.b9b7fced-2054-427e-b931-fdf818702333@github.com>

On Thu, 22 Dec 2022 13:10:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
>> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)
>
> I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good:
> 
> Before:
> 
> Benchmark                   (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes         10000  avgt    5  7845.586 ? 23.440  ns/op
> ArraysHashCode.chars         10000  avgt    5  1203.163 ? 11.995  ns/op
> ArraysHashCode.ints          10000  avgt    5  1131.915 ?  7.843  ns/op
> ArraysHashCode.multibytes    10000  avgt    5  4136.487 ?  5.790  ns/op
> ArraysHashCode.multichars    10000  avgt    5   671.328 ? 17.629  ns/op
> ArraysHashCode.multiints     10000  avgt    5   699.051 ?  8.135  ns/op
> ArraysHashCode.multishorts   10000  avgt    5  4139.300 ? 10.633  ns/op
> ArraysHashCode.shorts        10000  avgt    5  7844.019 ? 26.071  ns/op
> 
> 
> After: 
> 
> Benchmark                   (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes         10000  avgt    5  1193.208 ?  1.965  ns/op
> ArraysHashCode.chars         10000  avgt    5  1193.311 ?  5.941  ns/op
> ArraysHashCode.ints          10000  avgt    5  1132.592 ? 10.410  ns/op
> ArraysHashCode.multibytes    10000  avgt    5   657.343 ? 25.343  ns/op
> ArraysHashCode.multichars    10000  avgt    5   672.668 ?  5.229  ns/op
> ArraysHashCode.multiints     10000  avgt    5   697.143 ?  3.929  ns/op
> ArraysHashCode.multishorts   10000  avgt    5   666.738 ? 12.236  ns/op
> ArraysHashCode.shorts        10000  avgt    5  1193.563 ?  5.449  ns/op

@cl4es There seem to be failure on windows-x64 platform pre submit tests. Could you please take a look?

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

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Fri Jan  6 20:09:47 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 20:09:47 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs
Message-ID: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>

Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 

Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE

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

Commit messages:
 - Copyright year
 - Replace constructor with static field

Changes: https://git.openjdk.org/jdk/pull/11872/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11872&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299502
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11872/head:pull/11872

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Fri Jan  6 20:09:49 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 20:09:49 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs
In-Reply-To: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
Message-ID: <DIl6LFlVUgNo5GchL2B-3pi730wKt6Wt9DBx2UW5s-o=.8a022e1a-8887-4a7d-99a8-4a3d0cee9aa8@github.com>

On Thu, 5 Jan 2023 21:59:30 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
> 
> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE

src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java line 59:

> 57:  *
> 58:  * <p>The property can be set with the following code line:
> 59:  * {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE|Boolean.FALSE);}

>From a code standpoint I don't see why the OR operation is needed (Also, shouldn't a Conditional OR be used over a Bitwise OR). Is it to emphasize that true _or_ false can be passed as a parameter?

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

PR: https://git.openjdk.org/jdk/pull/11872

From stsypanov at openjdk.org  Fri Jan  6 21:04:57 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 6 Jan 2023 21:04:57 GMT
Subject: Integrated: 8299600: Use Objects.check*() where appropriate in java.io
In-Reply-To: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
References: <BuxZsoukq5LMFE4fWV476-13WM-qwh9vMekGSTeSYFw=.5816d36c-82ec-44aa-8408-ea9ac0ed680a@github.com>
Message-ID: <6LKSV9xS19x1LOTWhmmbxlQu_9-R6AwjFzvUo9CPZdI=.2b6afbd0-f361-45c2-84c2-e5f052fabe8f@github.com>

On Wed, 4 Jan 2023 15:50:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Use the following methods instead of hand-written code:
> - Objects.checkFromIndexSize()
> - Objects.checkFromToIndex()

This pull request has now been integrated.

Changeset: d086e82b
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d086e82b3c554362a8fc7095025f8f2910d6e4bc
Stats:     37 lines in 6 files changed: 10 ins; 9 del; 18 mod

8299600: Use Objects.check*() where appropriate in java.io

Reviewed-by: alanb, bpb

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

PR: https://git.openjdk.org/jdk/pull/11849

From mchung at openjdk.org  Fri Jan  6 21:15:38 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 6 Jan 2023 21:15:38 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order [v2]
In-Reply-To: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
Message-ID: <e34JU_fXQTckXzi5HdBEUHAkTIV_jHSfz3V6Lb6O5kA=.a38d421f-6710-40b2-81bd-3bbdd56cfdc1@github.com>

> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

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

 - Add a regression test
 - further cleanup newWrongMethodTypeException for clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11870/files
  - new: https://git.openjdk.org/jdk/pull/11870/files/3d074593..35968a32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11870&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11870&range=00-01

  Stats: 98 lines in 3 files changed: 87 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11870/head:pull/11870

PR: https://git.openjdk.org/jdk/pull/11870

From mchung at openjdk.org  Fri Jan  6 21:17:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 6 Jan 2023 21:17:52 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order
In-Reply-To: <u0yZybemlAOxNkYmKqwn4ArJgI5yPJFMvz8nufB1k0Y=.84eb95b0-b192-4f15-ad7e-4410855baeb9@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
 <u0yZybemlAOxNkYmKqwn4ArJgI5yPJFMvz8nufB1k0Y=.84eb95b0-b192-4f15-ad7e-4410855baeb9@github.com>
Message-ID: <lj5YIuEHSTwt6I4goovjn9LWQh-_E4cgyAEFchX9ezQ=.aef60a89-0095-42ff-a68e-12c3186f88b7@github.com>

On Fri, 6 Jan 2023 01:05:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.
>
> Hello Mandy, this looks good to me. The copyright year on the file will need an update.
> 
> There's another call to this `newWrongMethodTypeException` method on line 515 and I am guessing that one is already passing the params in the correct order. If I go by that same logic, then there appears to be a direct construction of `WrongMethodTypeException` on line 497 and I suspect the `String` passed to it is perhaps using the wrong order? It currently says:
> 
> 
> if (handle.hasInvokeExactBehavior() && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
>      throw new WrongMethodTypeException("expected " + handle.accessModeType(ad.type) + " but found "
>                     + ad.symbolicMethodTypeExact);
> }
> 
> Should it instead say:
> 
> if (handle.hasInvokeExactBehavior() && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
>     throw new WrongMethodTypeException("expected " + ad.symbolicMethodTypeExact + " but found "
>                     + handle.accessModeType(ad.type));
> }

@jaikiran good observation. 

"expected" and "actual" parameters are confusing. "expected" is ambiguous and it could refer to handle's method type or symbolic type descriptor.  I decide to rename the parameters and the exception message for clarity.

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

PR: https://git.openjdk.org/jdk/pull/11870

From joehw at openjdk.org  Fri Jan  6 21:23:55 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Jan 2023 21:23:55 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs
In-Reply-To: <DIl6LFlVUgNo5GchL2B-3pi730wKt6Wt9DBx2UW5s-o=.8a022e1a-8887-4a7d-99a8-4a3d0cee9aa8@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <DIl6LFlVUgNo5GchL2B-3pi730wKt6Wt9DBx2UW5s-o=.8a022e1a-8887-4a7d-99a8-4a3d0cee9aa8@github.com>
Message-ID: <l7FVSywHpgYUIWaJFYQ5QUEfzp8GNfpqdVXoCzSTRlE=.c520af6a-e520-465c-8269-48c635ec5d4d@github.com>

On Fri, 6 Jan 2023 19:56:20 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java line 59:
> 
>> 57:  *
>> 58:  * <p>The property can be set with the following code line:
>> 59:  * {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE|Boolean.FALSE);}
> 
> From a code standpoint I don't see why the OR operation is needed (Also, shouldn't a Conditional OR be used over a Bitwise OR). Is it to emphasize that true _or_ false can be passed as a parameter?

I think the later, that the value can be true or false. As an example, one value is fine, e.g.
  {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE);} 
  or 
  {@code setProperty("javax.xml.stream.isRepairingNamespaces", true);}
  let autoboxing handle it.

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

PR: https://git.openjdk.org/jdk/pull/11872

From lancea at openjdk.org  Fri Jan  6 21:36:51 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 6 Jan 2023 21:36:51 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs
In-Reply-To: <l7FVSywHpgYUIWaJFYQ5QUEfzp8GNfpqdVXoCzSTRlE=.c520af6a-e520-465c-8269-48c635ec5d4d@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <DIl6LFlVUgNo5GchL2B-3pi730wKt6Wt9DBx2UW5s-o=.8a022e1a-8887-4a7d-99a8-4a3d0cee9aa8@github.com>
 <l7FVSywHpgYUIWaJFYQ5QUEfzp8GNfpqdVXoCzSTRlE=.c520af6a-e520-465c-8269-48c635ec5d4d@github.com>
Message-ID: <Khoca5TYTChPwHyQkIhbgZLrKz5f4KWfv_UZWZlHEho=.02394a9b-653f-40f8-b1cb-153cbd9e5987@github.com>

On Fri, 6 Jan 2023 21:20:45 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java line 59:
>> 
>>> 57:  *
>>> 58:  * <p>The property can be set with the following code line:
>>> 59:  * {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE|Boolean.FALSE);}
>> 
>> From a code standpoint I don't see why the OR operation is needed (Also, shouldn't a Conditional OR be used over a Bitwise OR). Is it to emphasize that true _or_ false can be passed as a parameter?
>
> I think the later, that the value can be true or false. As an example, one value is fine, e.g.
>   {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE);} 
>   or 
>   {@code setProperty("javax.xml.stream.isRepairingNamespaces", true);}
>   let autoboxing handle it.

The` true|false` should just be changed to just set the value to _true_ or _false_.

I think `Boolean.TRUE` is fine.   If the consensus is to use autoboxing in the example that is fine also.

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

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Fri Jan  6 21:54:51 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 21:54:51 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs
In-Reply-To: <Khoca5TYTChPwHyQkIhbgZLrKz5f4KWfv_UZWZlHEho=.02394a9b-653f-40f8-b1cb-153cbd9e5987@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <DIl6LFlVUgNo5GchL2B-3pi730wKt6Wt9DBx2UW5s-o=.8a022e1a-8887-4a7d-99a8-4a3d0cee9aa8@github.com>
 <l7FVSywHpgYUIWaJFYQ5QUEfzp8GNfpqdVXoCzSTRlE=.c520af6a-e520-465c-8269-48c635ec5d4d@github.com>
 <Khoca5TYTChPwHyQkIhbgZLrKz5f4KWfv_UZWZlHEho=.02394a9b-653f-40f8-b1cb-153cbd9e5987@github.com>
Message-ID: <GR4VPPvewr4C2i7DguXuTA4VjnDXmq9MbAWLXPbuzn4=.db06e2b3-f87c-4c59-afdf-4e4294f7fb2b@github.com>

On Fri, 6 Jan 2023 21:34:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I think the later, that the value can be true or false. As an example, one value is fine, e.g.
>>   {@code setProperty("javax.xml.stream.isRepairingNamespaces", Boolean.TRUE);} 
>>   or 
>>   {@code setProperty("javax.xml.stream.isRepairingNamespaces", true);}
>>   let autoboxing handle it.
>
> The` true|false` should just be changed to just set the value to _true_ or _false_.
> 
> I think `Boolean.TRUE` is fine.   If the consensus is to use autoboxing in the example that is fine also.

Thank you Joe and Lance, will replace it with a single value

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

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Fri Jan  6 21:59:13 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 21:59:13 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
Message-ID: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>

> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
> 
> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE

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

  Replace | with single value in example

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11872/files
  - new: https://git.openjdk.org/jdk/pull/11872/files/44c37d9f..91d20422

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11872&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11872&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Fri Jan  6 22:44:29 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 6 Jan 2023 22:44:29 GMT
Subject: RFR: 8177418: TimeZone.getTimeZone(String id) throws
 NullPointerException when id is null
Message-ID: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>

When ID is null, TimeZone.getTimeZone(String ID) throws a NullPointerException.

For example, 


String someID = null;
TimeZone tz1 = TimeZone.getTimeZone(someID);
``` 

throws a `NullPointerException`

This change updates the documentation to make this apparent.

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

Commit messages:
 - Add missing @throws

Changes: https://git.openjdk.org/jdk/pull/11888/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8177418
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v2]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year for newly added files to 2023.
 - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01

  Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan  6 23:13:09 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 6 Jan 2023 23:13:09 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
Message-ID: <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>

On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere?
>> 
>> Hi @dholmes-ora,
>> 
>> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc.
>> 
>> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds.
>> 
>> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. 
>> 
>>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details.
>> 
>> Hi @AlanBateman,
>> 
>> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well.
>> 
>>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially.
>> 
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
>> 
>> Thanks for both of your comments.
>
>> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct?
>> 
>> If this is generally agreed as a better route then let me know and I'll update the patch.
> 
> Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hi @AlanBateman,

OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags.

I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch.

>  I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.

Hmm. Hasn't that horse already left the barn? You kind of implied that when you said:

> I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor.

In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior.

Of course I'd love to be wrong... in which case, we can fix these constructors.

Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine.

But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?).

It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape".

Thanks.

@mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list.

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

PR: https://git.openjdk.org/jdk/pull/11874

From joehw at openjdk.org  Fri Jan  6 23:19:52 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Jan 2023 23:19:52 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
Message-ID: <V0oBxDZfwPcbbtixSpz-TDx6TO_zM6s6zKU60_usezw=.018df983-9ccd-4323-8000-0df60dec568d@github.com>

On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace | with single value in example

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11872

From naoto at openjdk.org  Sat Jan  7 00:15:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 7 Jan 2023 00:15:53 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
Message-ID: <5V-EK-V8hN2br_pnqoHE5UAbl5U_DVe56E34yL_MFyE=.2cb31f1c-663e-4a36-8b47-22405db55591@github.com>

On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace | with single value in example

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11872

From jwilhelm at openjdk.org  Sat Jan  7 01:16:10 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 7 Jan 2023 01:16:10 GMT
Subject: RFR: Merge jdk20
Message-ID: <dQt3ZgDxVk_lTYQ2jUaJu55Tn1yAvkJdS7H3QvZfSAE=.754557f6-d096-4a3b-8bfc-66b05b7968ef@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299705: JCov coverage runs depend on jdk_symbols
 - 8299740: CaptureCallState is missing @Preview annotation
 - 8299528: IR test: TestEor3AArch64.java fails on aarch64
 - 8298525: javadoc crashes with "UnsupportedOperationException: Not yet implemented" in SeeTaglet.inherit
 - 8299561: VaList.empty() doesn't return a list associated with the global scope

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11889&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11889&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11889/files
  Stats: 54 lines in 10 files changed: 39 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11889/head:pull/11889

PR: https://git.openjdk.org/jdk/pull/11889

From duke at openjdk.org  Sat Jan  7 01:33:49 2023
From: duke at openjdk.org (Justin Lu)
Date: Sat, 7 Jan 2023 01:33:49 GMT
Subject: RFR: 6381945: (cal) Japanese calendar unit test system should avoid
 multiple static imports
Message-ID: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>

Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_

GregorianCalendar alone handles all the necessary imports, Calendar is not needed

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

Commit messages:
 - Update copyright
 - Remove redundant import

Changes: https://git.openjdk.org/jdk/pull/11855/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6381945
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11855/head:pull/11855

PR: https://git.openjdk.org/jdk/pull/11855

From jwilhelm at openjdk.org  Sat Jan  7 02:08:56 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 7 Jan 2023 02:08:56 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <dQt3ZgDxVk_lTYQ2jUaJu55Tn1yAvkJdS7H3QvZfSAE=.754557f6-d096-4a3b-8bfc-66b05b7968ef@github.com>
References: <dQt3ZgDxVk_lTYQ2jUaJu55Tn1yAvkJdS7H3QvZfSAE=.754557f6-d096-4a3b-8bfc-66b05b7968ef@github.com>
Message-ID: <-2H4IjL6XCZs0Br_s864ZDRUi2knCTWanFxFiVkx5Fs=.ee6eface-2519-401e-bd51-88c8dd211aab@github.com>

On Sat, 7 Jan 2023 01:08:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 5393dc9a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5393dc9a48064505f0b79b7059f87bec33c1c8fe
Stats:     54 lines in 10 files changed: 39 ins; 0 del; 15 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11889

From duke at openjdk.org  Sat Jan  7 02:22:58 2023
From: duke at openjdk.org (Justin Lu)
Date: Sat, 7 Jan 2023 02:22:58 GMT
Subject: Integrated: 8299617: CurrencySymbols.properties is missing the
 copyright notice
In-Reply-To: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
References: <3P2LV_PvCy1tn3ALX_uNgNGUvtNM2Xs672NJJpW66cQ=.9f817221-c95a-49ed-b360-3861f6a7950d@github.com>
Message-ID: <86dv7_OPtewpfAouqsztfIezb0l0Uga2NSY8yz72vmg=.5dde40e6-35ff-412a-9ab4-c8224a462490@github.com>

On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Added the missing copyright header

This pull request has now been integrated.

Changeset: d5b80abc
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5b80abcbfff57c7728d3e42a696a762f08bc7ad
Stats:     23 lines in 1 file changed: 23 ins; 0 del; 0 mod

8299617: CurrencySymbols.properties is missing the copyright notice

Reviewed-by: naoto, iris, jpai

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

PR: https://git.openjdk.org/jdk/pull/11854

From jpai at openjdk.org  Sat Jan  7 02:36:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Jan 2023 02:36:57 GMT
Subject: RFR: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial() [v2]
In-Reply-To: <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
 <j7s6PORPY2eSolzBQoJzXjdz3HAoNJkwUAZypkCxC6M=.63e76875-3cb1-4c1a-9b48-2230d21a54c9@github.com>
Message-ID: <dqoYQZc8tpb2byOjYgYYt7LkYc0mNEh9W0byuoW9ISQ=.d9b80bc5-16c7-492a-bf87-148df6b9b91b@github.com>

On Thu, 5 Jan 2023 13:24:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
>> 
>> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
>> 
>> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
>> 
>> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
>> 
>>> If the current thread does not support thread locals then
>>> this method returns its {@link #initialValue} (or {@code null}
>>> if the {@code initialValue} method is not overridden).
>> 
>> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
>> 
>> 
>> public class Test {
>>   public static void main(final String[] args) throws Exception {
>>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
>> 	var t = ThreadLocal.withInitial(() -> 2);
>> 	System.out.println("Thread local value is " + t.get());
>>     });
>>   }
>> }
>> 
>> Running this with `java --enable-preview --source 21 Test.java` returns:
>> 
>> Thread local value is 2
>> 
>> 
>> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
>> 
>> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestion

The CSR has been approved. Thank you Alan for the review.

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

PR: https://git.openjdk.org/jdk/pull/11846

From jpai at openjdk.org  Sat Jan  7 02:36:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Jan 2023 02:36:59 GMT
Subject: Integrated: 8258776: ThreadLocal#initialValue() Javadoc is unaware of
 ThreadLocal#withInitial()
In-Reply-To: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
References: <W7m6_J013kKTC4Ls8RYU6ml1ifKiQaAS0ra-dGO5_tI=.6194d074-c8f5-44b3-8816-345a5aedd57c@github.com>
Message-ID: <_QqkZmzmDt4VBNS8b8-Q11Q0XwENG8-gEopCzVHexEE=.d4f217e1-3cfa-4e4a-a031-d7c1b34654e7@github.com>

On Wed, 4 Jan 2023 14:37:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc only change which addresses the javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776? 
> 
> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests subclassing `ThreadLocal` and overriding the `initialValue()` method instead of recommending the `withInitial` method that was added in Java 8.
> 
> The commit here updates the javadoc of `initialValue()` method to note that `withInitial` method is available for use if the programmer wants to provide an initial value. The updated javadoc continues to note that the `ThreadLocal` can be subclassed and the method overriden as the other way of providing an initial value. This change now uses the `@implSpec` construct to state this default behaviour of the `initialValue()` method.
> 
> Additionally, the `get()` method's javadoc has also been updated to account for the semantics of `initialValue()`. In fact, in its current form, before the changes in this PR, the `get()` method states:
> 
>> If the current thread does not support thread locals then
>> this method returns its {@link #initialValue} (or {@code null}
>> if the {@code initialValue} method is not overridden).
> 
> which isn't accurate, since the `get()` will return a non-null value if the ThreadLocal was constructed through `ThreadLocal.withInitial`. Here's a trivial code which contradicts this current javadoc:
> 
> 
> public class Test {
>   public static void main(final String[] args) throws Exception {
>     Thread.ofPlatform().name("hello").allowSetThreadLocals(false).start(() -> {
> 	var t = ThreadLocal.withInitial(() -> 2);
> 	System.out.println("Thread local value is " + t.get());
>     });
>   }
> }
> 
> Running this with `java --enable-preview --source 21 Test.java` returns:
> 
> Thread local value is 2
> 
> 
> The updated javadoc of `get()` in this PR now matches the behaviour of this method. I believe this will need a CSR, which I'll open once we have an agreement on these changes.
> 
> Furthermore, the class level javadoc of `ThreadLocal` has an example of providing an initial value which uses the subclassing strategy. I haven't updated that part. Should we update that to show the `withInitialValue` usage instead (and maybe convert it to a snippet)?

This pull request has now been integrated.

Changeset: e209693a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e209693a37e49ba5fd5b1ad3404e9dd807c545f3
Stats:     10 lines in 1 file changed: 3 ins; 1 del; 6 mod

8258776: ThreadLocal#initialValue() Javadoc is unaware of ThreadLocal#withInitial()

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/11846

From alanb at openjdk.org  Sat Jan  7 10:38:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Jan 2023 10:38:59 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
In-Reply-To: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
Message-ID: <o8uRqpK4nF73PQbGtwN1z-m2l_4e9m8k5ETKQGHz-0E=.5781ffa9-ff9c-452b-93a9-08e7bf41a2c4@github.com>

On Fri, 6 Jan 2023 17:57:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.

src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java line 35:

> 33:  * designates the module name of the implementation, and which defaults
> 34:  * to "java.base". If no providers is available,
> 35:  * or instantiation failed, java.base built-in Console implementation

The overall change looks fine but I think for the next edit that we should move most of this comment to Console as it's Console that selects the behavior and that skips errors. Also once the SM execution mode goes away then we can re-visit that behavior.

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

PR: https://git.openjdk.org/jdk20/pull/88

From jpai at openjdk.org  Sat Jan  7 10:49:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Jan 2023 10:49:51 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order [v2]
In-Reply-To: <e34JU_fXQTckXzi5HdBEUHAkTIV_jHSfz3V6Lb6O5kA=.a38d421f-6710-40b2-81bd-3bbdd56cfdc1@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
 <e34JU_fXQTckXzi5HdBEUHAkTIV_jHSfz3V6Lb6O5kA=.a38d421f-6710-40b2-81bd-3bbdd56cfdc1@github.com>
Message-ID: <Xxo3F0JR33LiPltPDKFFOJppcFwVgUCdJSZeirI-hVw=.081c4053-0c3d-47e8-9100-1ca1b80c6cbb@github.com>

On Fri, 6 Jan 2023 21:15:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add a regression test
>  - further cleanup newWrongMethodTypeException for clarity

Thank you for the changes Mandy. Overall the error message looks more clear now.

There's a failing test in GitHub actions job which appears to be an existing test case which was expecting the older error message in the exception. That would need an update:


test VarHandleTestExact.testExactArraySet(class [Ljava.lang.Object;, "abcd", VarHandleTestExact$$Lambda$87/0x000000010015b1c0 at 2a9fbca4): failure
java.lang.AssertionError: 'handle's method type (Object[],int,Object)void but found (Object[],int,String)void' did not match the pattern '.*\\Qexpected (Object[],int,Object)void \\E.*'.
	at VarHandleTestExact.assertMatches(VarHandleTestExact.java:214)
	at VarHandleTestExact.doTest(VarHandleTestExact.java:199)
	at VarHandleTestExact.testExactArraySet(VarHandleTestExact.java:153)

test/jdk/java/lang/invoke/WrongMethodTypeTest.java line 8:

> 6:  * under the terms of the GNU General Public License version 2 only, as
> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided

>From what I understand, the copyright notice on test files don't use the "Classpath" exception and instead use a different copyright notice.

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

PR: https://git.openjdk.org/jdk/pull/11870

From lancea at openjdk.org  Sat Jan  7 11:24:52 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 7 Jan 2023 11:24:52 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
Message-ID: <FISSsIcw2WEA5kuU-HcCBQGiKPqwah22trSC88GvLjc=.024de214-a9f1-49f9-b9b9-35ef20fdb76f@github.com>

On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace | with single value in example

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11872

From lancea at openjdk.org  Sat Jan  7 11:27:50 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 7 Jan 2023 11:27:50 GMT
Subject: RFR: 6381945: (cal) Japanese calendar unit test system should
 avoid multiple static imports
In-Reply-To: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
References: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
Message-ID: <YTfyMRJRwMqQNxcYnzzutMpqTa8cNoK9Cdp_XfIcPGc=.87390fab-00ee-4fec-874b-38e6c632ac4e@github.com>

On Wed, 4 Jan 2023 21:49:18 GMT, Justin Lu <duke at openjdk.org> wrote:

> Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_
> 
> GregorianCalendar alone handles all the necessary imports, Calendar is not needed

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11855

From lancea at openjdk.org  Sat Jan  7 11:34:50 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 7 Jan 2023 11:34:50 GMT
Subject: RFR: 8177418: TimeZone.getTimeZone(String id) throws
 NullPointerException when id is null
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <IBC1VKUR4iuvDqzLR3wqtCidHJV5xdOuD5M95CPiNA8=.a0e37a58-a23f-441b-b179-acecf8fe0659@github.com>

On Fri, 6 Jan 2023 22:38:13 GMT, Justin Lu <duke at openjdk.org> wrote:

> When ID is null, TimeZone.getTimeZone(String ID) throws a NullPointerException.
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> This change updates the documentation to make this apparent.

Hi Justin,

This will require a CSR due to the change in the javadoc.  Otherwise looks fine.  Once you have your draft ready, lets us know and we can review it for you so you can get it finalized

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

PR: https://git.openjdk.org/jdk/pull/11888

From tjmnkrajyej at gmail.com  Sat Jan  7 11:47:04 2023
From: tjmnkrajyej at gmail.com (Mohamed Maaliki)
Date: Sat, 7 Jan 2023 11:47:04 +0000
Subject: 8140283: add Stream::transform method to facilitate fluent chaining
 of other methods
Message-ID: <09e3ff32-1d75-92a5-45b9-feb57027820b@gmail.com>

I?ve started working on the RFE mentioned in the title. At the moment 
I?ve implemented the method in |BaseStream| in order to cover every 
stream type: is that alright or should I restrict it to |Stream|? And if 
there?s anything else that I should know, then please let me know. Thanks.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230107/7260c954/attachment.htm>

From duke at openjdk.org  Sat Jan  7 16:24:56 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 7 Jan 2023 16:24:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v2]
In-Reply-To: <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <QUOGIQWxLc_RT0xtonZXdnCxSUR7Gkw3vj4MSp8wiW8=.23bbeb90-21fe-435a-a4e3-d631ebab9ad6@github.com>
Message-ID: <xWYztLE9Mx-jVzvGesQ0jF5PXrQYZE_aDpOvZ6EW5K8=.70ef0e5d-3fcc-4428-bbc4-d2847fd57e69@github.com>

On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year for newly added files to 2023.
>  - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations.

src/java.base/share/classes/java/lang/AssertionError.java line 75:

> 73:      */
> 74:     @SuppressWarnings("this-escape")
> 75:     public AssertionError(Object detailMessage) {

The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`.

src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77:

> 75:      * Constructs a {@code BootstrapMethodError} with the specified
> 76:      * cause.
> 77:      *

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     *

src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54:

> 52:      * throwable object.
> 53:      * A detail message is a String that describes this particular exception.
> 54:      */

Suggestion:

     *
     * @implNote This constructor invokes {@link #initCause initCause()}; see
     * <a href="{@docRoot}/java.base/java/lang/doc-files/ThisEscape.html">This Escape</a>.
     */

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Sat Jan  7 16:58:58 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 16:58:58 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v3]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <TpQ6WIGxsY1KZfY8qSobqotTj6nA5EQe7VCH8mRxe80=.48fb5e57-210b-48dc-bf00-7221e4ce1bcb@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add a few more Javadoc warnings for 'this' escape via initCause().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/f667cd56..398737fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01-02

  Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Sat Jan  7 18:05:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Jan 2023 18:05:50 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
 <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
Message-ID: <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>

On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch.
> 
> > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it.
> 
> Hmm. Hasn't that horse already left the barn? You kind of implied that when you said:
> 
> > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor.
> 
> In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior.
> 
> Of course I'd love to be wrong... in which case, we can fix these constructors.

I hope at least some of these can be fixed as leaking a part initialized object to an untrusted subclass or some other code is problematic in many ways. Skimming through the original list, then some of these may be accidental and some may be fixable without any compatibility concerns, esp. in the JDK internal classes. Yes, some horses have left the barn. A horse that got out a long time ago is j.net.ServerSocket where 3 of its constructors call an overridable bind method. Recent re-implementation would have fixed this but there were concerns that subclasses may be relying on this long standing undocumented behavior. There are other cases in the list where the leaking may be necessary part of the contract for subclasses. So it will probably require working through them on a case by case basis. I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. Developers reading these implementation notes may c
 reate code that depends on these "hooks" and it will make it very hard for the JDK to ever change the behavior. Where the leaking is a necessary part of the contract for subclassing then it may be that it has to be documented as normative text rather than an implementation note.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Sat Jan  7 19:52:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 19:52:49 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor
In-Reply-To: <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bT23KDnt3l6QShNPVLFoC9H88-v8djTLMxtXewI7gv4=.894547d3-a564-4a5d-9a6d-2264876ac642@github.com>
 <MTkJNTvGepdVz-6gfrweOnP-8laNPOemoDSdZ6S8GBo=.51eabb04-75eb-40e6-b18c-203ee564b4ae@github.com>
 <zCh-SUG-aTKJSXkfjCsxJHyjB5CvrM4Jik_-zVvXICc=.caa64740-ee13-4c8d-8bc6-429148bb84e6@github.com>
 <D_16yzU3GKCNp3muk32Ykwpy9od0qdOohTmBO8Gt_Es=.c914efeb-2b98-44ef-891a-7480fb094315@github.com>
 <iK8Zd1oZLhFZu3nWbKaBtLD0GrYVEd0iVJDbyWKhwVY=.c1066a2c-882e-4498-a9a2-5a8a78fbbfe5@github.com>
Message-ID: <kqQTTj7gYjBC70LCPLNbpfnBbTjyDTLsFX4Gvc0WO_g=.07f26c0d-b006-41fd-9cd5-48255a921d57@github.com>

On Sat, 7 Jan 2023 18:03:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance.

I agree with you - not only for that reason, but also because as others have pointed out the addition of the warning is really a separate task from the evaluation and triage of any existing leaks. Moreover, this latter task is really multiple separate tasks that belong to the various module/functional groups.

I'll remove all the Javadoc `@implNote`'s from the patch, and `src/java.base/share/classes/java/lang/doc-files/ThisEscape.html` as well - it will still be available in the git history if someone comes up with a better home for it.

This will also further reduce the number of labels and therefore required reviewers.

Thanks.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Sat Jan  7 19:59:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 19:59:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v4]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <lW3XeWImW3aoe4zyqD6Bm81B6VLrlnhmEYzKA0lwT-s=.7aa83963-79c0-4d92-a37a-47349122d1ef@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove Javadoc @implNotes; plan to triage the various existing leaks separately.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/398737fa..537b3e3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02-03

  Stats: 255 lines in 29 files changed: 0 ins; 251 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Sat Jan  7 21:08:07 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 7 Jan 2023 21:08:07 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect @bug numbers in unit tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/537b3e3c..7e2fdb07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=03-04

  Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From dholmes at openjdk.org  Sun Jan  8 23:28:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 8 Jan 2023 23:28:59 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <C5i6bXdC-YaoW2lOFLQyh5Xf1ul1I17OhQ19p1G2hgM=.2617a928-21aa-4f34-9311-0717ea0eb6d3@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

Committing unchanged files, other than a copyright year change, looks very odd here. Why was the SunMisUnsafe template updated but none of the tests actually changed?

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

PR: https://git.openjdk.org/jdk/pull/9892

From jpai at openjdk.org  Mon Jan  9 01:09:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jan 2023 01:09:04 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator [v2]
In-Reply-To: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
Message-ID: <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>

> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

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

  update another javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11876/files
  - new: https://git.openjdk.org/jdk/pull/11876/files/b887f417..d9abcaa6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11876&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11876&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11876.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11876/head:pull/11876

PR: https://git.openjdk.org/jdk/pull/11876

From jpai at openjdk.org  Mon Jan  9 01:13:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jan 2023 01:13:51 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator [v2]
In-Reply-To: <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
 <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
Message-ID: <bRuhSClYnSn4Z2VABTBS19TcgjgD0FngbyJCpL7satA=.ba3e48ae-a4b1-44c7-898f-635f7db2ef98@github.com>

On Mon, 9 Jan 2023 01:09:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update another javadoc

Hello Naoto, the brackets usage on that other method looks fine to me:

* Creates a {@code Spliterator} using the given collection's
* {@link java.util.Collection#iterator()} as the source of elements, and
* reporting its {@link java.util.Collection#size()} as its initial size.

I've now however updated that part just to use the same style of `{@link ...` as in the proposed change.

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

PR: https://git.openjdk.org/jdk/pull/11876

From jpai at openjdk.org  Mon Jan  9 01:23:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jan 2023 01:23:58 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
In-Reply-To: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
Message-ID: <yQ_a2xt8nn7gKXENd1sekwPh_WcnKiE1KTycMi2gZ6g=.40f1fa39-6ad9-49ba-ac90-94eb95810616@github.com>

On Fri, 6 Jan 2023 17:57:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.

Marked as reviewed by jpai (Reviewer).

Hello Naoto, this looks fine to me. The `RedirectTest.java` will need an update on the copyright year.

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

PR: https://git.openjdk.org/jdk20/pull/88

From david.holmes at oracle.com  Mon Jan  9 06:21:55 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jan 2023 16:21:55 +1000
Subject: jpackageapplauncher linker arguments for osx
In-Reply-To: <CAMrs=afcH+CUhY62dO=VeO7A3R++eMusdSESg9qPSMbJpSUx+g@mail.gmail.com>
References: <CAMrs=afcH+CUhY62dO=VeO7A3R++eMusdSESg9qPSMbJpSUx+g@mail.gmail.com>
Message-ID: <7ab61fe5-9073-84db-d2d3-e9e4682b366f@oracle.com>

On 8/01/2023 8:39 pm, David Schumann wrote:
> Hello,
> 
> I'm not 100% sure if this list is the correct one for this topic, feel 
> free to redirect me.

core-libs-dev - cc'd

Cheers,
David

> Currently the?jpackageapplauncher binary gets linked without the 
> "-headerpad_max_install_names" argument on osx. This prevents a user 
> from using the install_name_tool with the launcher binary.
> This means that it's currently not possible to include dylibs in the 
> application bundle.
> 
> To provide a bit more context:
> I'm using jpackage to build an app bundle. The java application itself 
> uses external native libraries, which internally use dlopen to reference 
> other libs. Normaly one would include the other libs in the app bundle, 
> and use the install_name_tool to tell the dynamic linker which paths to 
> load the libraries from. However since the launcher binary doesn't get 
> linked with the correct arguments, this isn't possible.
> 
> I wanted to discuss this change, and it it makes sense for me to open a 
> pull request for it.
> The change would be in 
> https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76 <https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76>
> 
> Best Regards,
> David Schumann
> 

From dholmes at openjdk.org  Mon Jan  9 06:39:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jan 2023 06:39:52 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
Message-ID: <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>

On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect @bug numbers in unit tests.

All your new files need a copyright and GPL header.

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

PR: https://git.openjdk.org/jdk/pull/11874

From shade at openjdk.org  Mon Jan  9 07:06:00 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Jan 2023 07:06:00 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <C5i6bXdC-YaoW2lOFLQyh5Xf1ul1I17OhQ19p1G2hgM=.2617a928-21aa-4f34-9311-0717ea0eb6d3@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
 <C5i6bXdC-YaoW2lOFLQyh5Xf1ul1I17OhQ19p1G2hgM=.2617a928-21aa-4f34-9311-0717ea0eb6d3@github.com>
Message-ID: <KBltce64z8TWepnrxi4-iyMfRRVxH-mefpx0-D1uMvs=.5d610d3c-553d-4abd-a97a-de3701d885ac@github.com>

On Sun, 8 Jan 2023 23:25:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Committing unchanged files, other than a copyright year change, looks very odd here. Why was the SunMisUnsafe template updated but none of the tests actually changed?

`X-UnsafeAccessTest.java.template` generates both `SunMisc*` and `JdkInternalMisc*` files, using `JdkInternalMisc` condition to disambiguate the two. So, if we need to change `JdkInternalMisc*`, like this PR does, we need to change `X-UnsafeAccessTest.java.template`, which regenerates `SunMisc*` too. Since `SunMisc*` tests do not have `weakCAS` operations, only the copyright updates hit them. 

You could, in principle, selectively commit only the "substantially affected" files, but I believe the rule for auto-generated files after template updates is to commit everything that was changed after the template change. This guarantees that regenerating files from the unchanged template yields no changes.

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

PR: https://git.openjdk.org/jdk/pull/9892

From iris at openjdk.org  Mon Jan  9 07:14:51 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 9 Jan 2023 07:14:51 GMT
Subject: RFR: 6381945: (cal) Japanese calendar unit test system should
 avoid multiple static imports
In-Reply-To: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
References: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
Message-ID: <Hf2z2p1OA13ubZc0cnJI4WUiCdOMWbwzKmw1VQR2s8k=.b7982a29-860d-4a50-988d-27ab355dda83@github.com>

On Wed, 4 Jan 2023 21:49:18 GMT, Justin Lu <duke at openjdk.org> wrote:

> Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_
> 
> GregorianCalendar alone handles all the necessary imports, Calendar is not needed

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11855

From dholmes at openjdk.org  Mon Jan  9 07:11:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jan 2023 07:11:57 GMT
Subject: RFR: 8292443: Weak CAS VarHandle/Unsafe tests should test
 always-failing cases
In-Reply-To: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
References: <asUQmRBgMEnYWVkmDJFJn7qamyaalZp84D6MvUvsilg=.56f27c9c-329f-4e8c-b243-b22abcc5d7ea@github.com>
Message-ID: <BelKhP3ayD13JMMyPCovthrnAk6f-QfojNdXCZvLV_A=.3d7de2be-dc9c-4fbe-b9e8-e1854d1109ec@github.com>

On Tue, 16 Aug 2022 15:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed that current VarHandle/Unsafe test cases do not test the always-failing cases. Strong CASes do test both always-success and always-failing scenarios, while weak CASes only test spurious-failure tests. We should be also testing always-failing cases for these. Weak CAS can spuriously fail, but it cannot spuriously succeed.
> 
> The PR looks large, but the actual changes are in `*.template` files, and the rest is generated from them.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux x86_32 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests
>  - [x]  Linux AArch64 fastdebug `java/lang/invoke/VarHandles` and `compiler/unsafe` tests

Ah! Sorry I  thought there were two distinct template file here.

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

PR: https://git.openjdk.org/jdk/pull/9892

From duke at openjdk.org  Mon Jan  9 08:33:09 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 9 Jan 2023 08:33:09 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

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

 - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
   
       Modifies ImmutableCollections.listCopy:
       Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
 - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
   
   Modifies Map.copyOf:
   Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11847/files
  - new: https://git.openjdk.org/jdk/pull/11847/files/52a87a2b..8e67eb86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=00-01

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11847/head:pull/11847

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Mon Jan  9 08:33:11 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 9 Jan 2023 08:33:11 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections
In-Reply-To: <kpnW2-ZCEO6lLCAW6p0zGyWUrgx40iUQW0rza5MtgH8=.47a04bb2-d507-497f-bd08-f42cb3306544@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <z86qCjRRB19yM2C9FRoWdItdO1zhXpQR9AWcPMo7lOY=.a4d47469-e8fc-42cb-82d5-a8a3b0caed3d@github.com>
 <kpnW2-ZCEO6lLCAW6p0zGyWUrgx40iUQW0rza5MtgH8=.47a04bb2-d507-497f-bd08-f42cb3306544@github.com>
Message-ID: <KEEDeMub0CmRqIQGUtySkvE4BruFOaOI-JaTCinenlk=.d270626d-c4b7-4706-8bf8-4cce57cf2cd3@github.com>

On Thu, 5 Jan 2023 01:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There's no regression test. However, with the current code (prior to this change) a call to `Set.of(zeroLengthArray)` returns the same instance as `Set.of()`, so it's difficult to write a simple functional test for this change. The test would have to assert that "no HashSet is allocated along this code path" which is much harder to test and frankly probably isn't worth it. So, please add one of the `noreg-*` labels to the bug to indicate the rationale for omitting a regression test.
>> 
>> https://openjdk.org/guide/#jbs-label-dictionary
>> 
>> I'd probably add the `Map.copyOf` change to this PR to avoid some bug/PR/review overhead. Thanks for mentioning this @shipilev.
>
>> so it's difficult to write a simple functional test for this change.
> 
> It is possible to track that for some "custom" and empty collection the only method will be called is `isEmpty` and nothing else. Not sure how it is useful or not.

@mrserb @stuart-marks I've pushed two additional commits which adds the isEmpty-check for Map and List as well, although the improvement there should be smaller, especially for Lists.

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

PR: https://git.openjdk.org/jdk/pull/11847

From pminborg at openjdk.org  Mon Jan  9 08:53:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jan 2023 08:53:22 GMT
Subject: RFR: 8299513: Cleanup java.io [v3]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <grQqDgyFqqP9nRq3QDr0d_zUxNOvNezzeoI4NI3PYT4=.05ac23a2-8123-4caa-b557-39bf890a5342@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Revert constructor, add (c) year and revert some doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/e3c107db..9331562b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=01-02

  Stats: 39 lines in 23 files changed: 3 ins; 7 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Mon Jan  9 08:57:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jan 2023 08:57:11 GMT
Subject: RFR: 8299513: Cleanup java.io [v4]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Add additional (c) years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/9331562b..a0e80355

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Mon Jan  9 09:22:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jan 2023 09:22:25 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

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

  Remove faulty test tag, improve other test tag, fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11840/files
  - new: https://git.openjdk.org/jdk/pull/11840/files/00a132c0..5d2341f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11840&range=05-06

  Stats: 13 lines in 3 files changed: 1 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11840/head:pull/11840

PR: https://git.openjdk.org/jdk/pull/11840

From alanb at openjdk.org  Mon Jan  9 09:30:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jan 2023 09:30:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
Message-ID: <TaM0rAlOWhfZnCDJBHH0KBOKq11YI-Ngbud5YYoLhak=.981a5b8a-5c23-4fab-999a-e8367a39b3a5@github.com>

On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove faulty test tag, improve other test tag, fix comments

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11840

From alanb at openjdk.org  Mon Jan  9 09:43:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jan 2023 09:43:56 GMT
Subject: RFR: 8299513: Cleanup java.io [v4]
In-Reply-To: <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
Message-ID: <H0CQ7lnz-NEvcgP7Mi4vGWSKT351Cjrhcu0ekLMTEY8=.2791c4f6-aaf4-4060-972e-feb38d39edd3@github.com>

On Mon, 9 Jan 2023 08:57:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional (c) years

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Mon Jan  9 10:33:55 2023
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Mon, 9 Jan 2023 10:33:55 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes [v7]
In-Reply-To: <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
Message-ID: <N4XtLspFmfbyoOLTXwOGgOJIwZywIlMCbMrjnSUMlSs=.3cba7c16-fe4a-406a-a609-0d822660630c@github.com>

On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

>> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`.
>> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process.
>> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value.
>> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html.  In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified.
>> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions.
>> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own.  
>> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/.
>> 
>> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas:
>> 
>> - TestStableLambdaNames$$Lambda$1/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$2/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38
>> The same method in the second run generates lambdas with different names:
>> - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470
>> 
>> If we use the introduced flag, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38
>> In the second run of the method, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470
>> 
>> We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test.
>
> Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove address from lambda class names in test on the 32-bit architecture too

Dummy comment to keep the PR alive.

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

PR: https://git.openjdk.org/jdk/pull/10024

From mcimadamore at openjdk.org  Mon Jan  9 10:36:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Jan 2023 10:36:53 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
Message-ID: <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>

On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove faulty test tag, improve other test tag, fix comments

src/java.base/share/classes/java/io/Bits.java line 77:

> 75:         // Using Double.longBitsToDouble collapses NaN values to a single
> 76:         // "canonical" NaN value
> 77:         return Double.longBitsToDouble((long) LONG.get(b, off));

For the records, I believe the template classes for byte array var handle already perform this conversion - e.g.


@ForceInline
        static $type$ get(VarHandle ob, Object oba, int index) {
            ArrayHandle handle = (ArrayHandle)ob;
            byte[] ba = (byte[]) oba;
#if[floatingPoint]
            $rawType$ rawValue = UNSAFE.get$RawType$Unaligned(
                    ba,
                    ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
                    handle.be);
            return $Type$.$rawType$BitsTo$Type$(rawValue); // <-----------------------------
#else[floatingPoint]
            return UNSAFE.get$Type$Unaligned(
                    ba,
                    ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
                    handle.be);
#end[floatingPoint]
        }
 ````

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

PR: https://git.openjdk.org/jdk/pull/11840

From lancea at openjdk.org  Mon Jan  9 10:59:52 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 9 Jan 2023 10:59:52 GMT
Subject: RFR: 8299513: Cleanup java.io [v4]
In-Reply-To: <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
Message-ID: <EyhdVLC8bcno73tGtQ9E_asJlB1GmK__ePaCEb1bOjU=.45c351d0-7a19-491f-8b9a-aee7e84b0180@github.com>

On Mon, 9 Jan 2023 08:57:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional (c) years

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11848

From uschindler at openjdk.org  Mon Jan  9 11:10:52 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Mon, 9 Jan 2023 11:10:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
 <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>
Message-ID: <EArajXgA160WMGw3l1815HBoTN1qNovQsmtEqA3y_-0=.41fdbc97-b741-40d2-90c2-3e57c84cee29@github.com>

On Mon, 9 Jan 2023 10:33:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove faulty test tag, improve other test tag, fix comments
>
> src/java.base/share/classes/java/io/Bits.java line 77:
> 
>> 75:         // Using Double.longBitsToDouble collapses NaN values to a single
>> 76:         // "canonical" NaN value
>> 77:         return Double.longBitsToDouble((long) LONG.get(b, off));
> 
> For the records, I believe the template classes for byte array var handle already perform this conversion - e.g.
> 
> 
> @ForceInline
>         static $type$ get(VarHandle ob, Object oba, int index) {
>             ArrayHandle handle = (ArrayHandle)ob;
>             byte[] ba = (byte[]) oba;
> #if[floatingPoint]
>             $rawType$ rawValue = UNSAFE.get$RawType$Unaligned(
>                     ba,
>                     ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
>                     handle.be);
>             return $Type$.$rawType$BitsTo$Type$(rawValue); // <-----------------------------
> #else[floatingPoint]
>             return UNSAFE.get$Type$Unaligned(
>                     ba,
>                     ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
>                     handle.be);
> #end[floatingPoint]
>         }
>  ````

For the other direction it uses the `floatToRawIntBits`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L148-L153

I think for symmatry we should keep it as is.

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

PR: https://git.openjdk.org/jdk/pull/11840

From mcimadamore at openjdk.org  Mon Jan  9 12:14:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Jan 2023 12:14:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <EArajXgA160WMGw3l1815HBoTN1qNovQsmtEqA3y_-0=.41fdbc97-b741-40d2-90c2-3e57c84cee29@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
 <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>
 <EArajXgA160WMGw3l1815HBoTN1qNovQsmtEqA3y_-0=.41fdbc97-b741-40d2-90c2-3e57c84cee29@github.com>
Message-ID: <oYd4iDgm15e08cSakkZPySMd2BUwPqJP63_0BPU9N6Q=.cc41c725-f17f-4a11-a448-c5cf00192da4@github.com>

On Mon, 9 Jan 2023 11:07:51 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Bits.java line 77:
>> 
>>> 75:         // Using Double.longBitsToDouble collapses NaN values to a single
>>> 76:         // "canonical" NaN value
>>> 77:         return Double.longBitsToDouble((long) LONG.get(b, off));
>> 
>> For the records, I believe the template classes for byte array var handle already perform this conversion - e.g.
>> 
>> 
>> @ForceInline
>>         static $type$ get(VarHandle ob, Object oba, int index) {
>>             ArrayHandle handle = (ArrayHandle)ob;
>>             byte[] ba = (byte[]) oba;
>> #if[floatingPoint]
>>             $rawType$ rawValue = UNSAFE.get$RawType$Unaligned(
>>                     ba,
>>                     ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
>>                     handle.be);
>>             return $Type$.$rawType$BitsTo$Type$(rawValue); // <-----------------------------
>> #else[floatingPoint]
>>             return UNSAFE.get$Type$Unaligned(
>>                     ba,
>>                     ((long) index(ba, index)) + Unsafe.ARRAY_BYTE_BASE_OFFSET,
>>                     handle.be);
>> #end[floatingPoint]
>>         }
>>  ````
>
> For the other direction it uses the `floatToRawIntBits`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L148-L153
> 
> I think for symmatry we should keep it as is.

I see - thanks for the explanation - the problem is with `floatToIntBits` vs `floatToRawIntBits` in the "put" operation. The get operation is ok, but then having asymmetry where we use a float VH in one case (get) but not in the other (put) is not desirable.

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

PR: https://git.openjdk.org/jdk/pull/11840

From rgiulietti at openjdk.org  Mon Jan  9 13:20:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 9 Jan 2023 13:20:53 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <oYd4iDgm15e08cSakkZPySMd2BUwPqJP63_0BPU9N6Q=.cc41c725-f17f-4a11-a448-c5cf00192da4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
 <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>
 <EArajXgA160WMGw3l1815HBoTN1qNovQsmtEqA3y_-0=.41fdbc97-b741-40d2-90c2-3e57c84cee29@github.com>
 <oYd4iDgm15e08cSakkZPySMd2BUwPqJP63_0BPU9N6Q=.cc41c725-f17f-4a11-a448-c5cf00192da4@github.com>
Message-ID: <TBYSWKqcKhyLLYl1DheNn2guKPaTmZJIegHFqaTa-DI=.3b0dc05d-f9ca-4532-856b-c2162d4dc803@github.com>

On Mon, 9 Jan 2023 12:12:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> For the other direction it uses the `floatToRawIntBits`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L148-L153
>> 
>> I think for symmatry we should keep it as is.
>
> I see - thanks for the explanation - the problem is with `floatToIntBits` vs `floatToRawIntBits` in the "put" operation. The get operation is ok, but then having asymmetry where we use a float VH in one case (get) but not in the other (put) is not desirable.

@mcimadamore According to the spec, `floatToRawIntBits` and `doubleToRawLongBits` ensure that the original input bits are all preserved, even for NaN values.
On the other hand, the spec says that `intBitsToFloat` and `longBitsToDouble` only ensure a best effort in preserving the output bits of NaN values.
So I think `VarHandle` `get` and `put` do their best to preserve the bits, but no more than the underlying platform can possibly offer.
This behavior for floating-point values is not fully specified in `VarHandle`, so there's room for improvement in the doc.

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

PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Mon Jan  9 14:03:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 9 Jan 2023 14:03:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <KlEenZ7O0DBvGKo8LfptAIvOJlwIOuZrv-lvszxXG3E=.f7bcba4e-9f8d-4ec0-953d-c68774c96902@github.com>
Message-ID: <efiqSfOiXFcY_J9cTnqaD-MXaNKg7b5-LsATAeEe9Xc=.a1265538-2624-4f3c-995e-6b1ecdf227b7@github.com>

On Mon, 9 Jan 2023 06:37:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> All your new files need a copyright and GPL header.

Sorry if I'm being blind but I'm not seeing it. Which file(s) are you referring to?

The `@test /nodynamiccopyright/` files don't get one per [this](https://openjdk.org/groups/compiler/tests.html#gold).

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

PR: https://git.openjdk.org/jdk/pull/11874

From fjiang at openjdk.org  Mon Jan  9 14:20:29 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 9 Jan 2023 14:20:29 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v2]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <TyAS8QEc2plNzAUn0Fm0lJpMELr-2gfE9T4CJXEVB04=.c5ff0641-e39b-4275-9455-b37eae9b307e@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build
> - [x] run TestMatrix.java manually with release/fastdebug build

Feilong Jiang 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' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - code adjustment and remove unnecessary static
 - sync with JDK-8296477
 - sync with JDK-8295044
 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/c155840c..efe8238e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=00-01

  Stats: 6771 lines in 356 files changed: 3498 ins; 2172 del; 1101 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From duke at openjdk.org  Mon Jan  9 14:52:38 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 9 Jan 2023 14:52:38 GMT
Subject: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always
 copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <O8OwpoLmD61SlClaUwygihFbXP7F2KQTjKqGFM2m45g=.967ce086-cfe8-4752-a738-e56876d37575@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

Can someone open a issue for me on JBS?

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

PR: https://git.openjdk.org/jdk/pull/11897

From duke at openjdk.org  Mon Jan  9 14:52:37 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 9 Jan 2023 14:52:37 GMT
Subject: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy
 arrays
Message-ID: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>

`JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.

I ran the tier1 test without any new errors.

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

Commit messages:
 - fix: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

Changes: https://git.openjdk.org/jdk/pull/11897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299807
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11897/head:pull/11897

PR: https://git.openjdk.org/jdk/pull/11897

From fjiang at openjdk.org  Mon Jan  9 15:09:12 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 9 Jan 2023 15:09:12 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <OchI9C-qVDi3BPfF-v7lhJ-bekvv1RO7AwhNnZqv0_c=.040b673f-c6c2-4500-8644-4e9d34be1b25@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build
> - [x] run TestMatrix.java manually with release/fastdebug build

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

  fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/efe8238e..289b8697

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From redestad at openjdk.org  Mon Jan  9 15:00:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Jan 2023 15:00:48 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v17]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <ztcKlhvp6H0YSU4hCf9lgP0nnL5HKGQGaE6hOVfy5Xg=.5a6205b5-3fa7-48a9-b0b5-b632135eb605@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:

 - Merge branch 'master' into 8282664-polyhash
 - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types
 - Handle signed subword arrays, contributed by @sviswa7
 - @sviswa7 comments
 - Pass the constant mode node through, removing need for all but one instruct declarations
 - FLAG_SET_DEFAULT
 - Merge branch 'master' into 8282664-polyhash
 - Merge branch 'master' into 8282664-polyhash
 - Missing & 0xff in StringLatin1::hashCode
 - Qualified guess on shenandoahSupport fix-up
 - ... and 58 more: https://git.openjdk.org/jdk/compare/66db0bb6...71297615

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

Changes: https://git.openjdk.org/jdk/pull/10847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=16
  Stats: 1052 lines in 33 files changed: 992 ins; 8 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Jan  9 15:23:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Jan 2023 15:23:58 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
 <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
 <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>
Message-ID: <r_bMeI15WeCUrxExArzVHzCO8d0VT3CWxT6se6KnNMI=.535740c8-fdd1-46fd-a702-a167c7f0410c@github.com>

On Thu, 22 Dec 2022 13:10:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
>> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)
>
> I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good:
> 
> Before:
> 
> Benchmark                   (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes         10000  avgt    5  7845.586 ? 23.440  ns/op
> ArraysHashCode.chars         10000  avgt    5  1203.163 ? 11.995  ns/op
> ArraysHashCode.ints          10000  avgt    5  1131.915 ?  7.843  ns/op
> ArraysHashCode.multibytes    10000  avgt    5  4136.487 ?  5.790  ns/op
> ArraysHashCode.multichars    10000  avgt    5   671.328 ? 17.629  ns/op
> ArraysHashCode.multiints     10000  avgt    5   699.051 ?  8.135  ns/op
> ArraysHashCode.multishorts   10000  avgt    5  4139.300 ? 10.633  ns/op
> ArraysHashCode.shorts        10000  avgt    5  7844.019 ? 26.071  ns/op
> 
> 
> After: 
> 
> Benchmark                   (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes         10000  avgt    5  1193.208 ?  1.965  ns/op
> ArraysHashCode.chars         10000  avgt    5  1193.311 ?  5.941  ns/op
> ArraysHashCode.ints          10000  avgt    5  1132.592 ? 10.410  ns/op
> ArraysHashCode.multibytes    10000  avgt    5   657.343 ? 25.343  ns/op
> ArraysHashCode.multichars    10000  avgt    5   672.668 ?  5.229  ns/op
> ArraysHashCode.multiints     10000  avgt    5   697.143 ?  3.929  ns/op
> ArraysHashCode.multishorts   10000  avgt    5   666.738 ? 12.236  ns/op
> ArraysHashCode.shorts        10000  avgt    5  1193.563 ?  5.449  ns/op

> @cl4es There seem to be failure on windows-x64 platform pre submit tests. Could you please take a look?

It looks like the `as_Address(ExternalAddress(StubRoutines::x86::arrays_hashcode_powers_of_31() + ...)` trick is running into some reachability issue on Windows, hitting the `assert(reachable(adr), "must be");` in `macroAssembler_x86.cpp`. Might be related to ASLR or some quirk of the VS compiler. I'll investigate.

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

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Mon Jan  9 16:14:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 16:14:02 GMT
Subject: RFR: 6381945: (cal) Japanese calendar unit test system should
 avoid multiple static imports
In-Reply-To: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
References: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
Message-ID: <L6Bv8XnN7PhuQgK0mundUBbqrl5qCfwwJ5MNFw-ieDs=.85ceed88-e321-4554-b0fc-435c3429da99@github.com>

On Wed, 4 Jan 2023 21:49:18 GMT, Justin Lu <duke at openjdk.org> wrote:

> Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_
> 
> GregorianCalendar alone handles all the necessary imports, Calendar is not needed

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11855

From naoto at openjdk.org  Mon Jan  9 16:12:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 16:12:55 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator [v2]
In-Reply-To: <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
 <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
Message-ID: <HnK67zx8vs3QIk1h1ti0tMAKZS03PAcZ61YemuTPqVM=.f9b0808d-97a2-4a61-a39c-a31f53198d8b@github.com>

On Mon, 9 Jan 2023 01:09:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update another javadoc

Looks fine to me. Thanks for the update, Jai.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11876

From naoto at openjdk.org  Mon Jan  9 16:03:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 16:03:52 GMT
Subject: RFR: 8177418: TimeZone.getTimeZone(String id) throws
 NullPointerException when id is null
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <9j8n1816UXLXcX9VN74MHGuRyXHhTJ4FCk-baS8qUQA=.f3849302-07dd-4dda-b447-73b0ecd3656c@github.com>

On Fri, 6 Jan 2023 22:38:13 GMT, Justin Lu <duke at openjdk.org> wrote:

> When ID is null, TimeZone.getTimeZone(String ID) throws a NullPointerException.
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> This change updates the documentation to make this apparent.

LGTM. Please file a CSR as Lance suggested.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11888

From redestad at openjdk.org  Mon Jan  9 16:49:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Jan 2023 16:49:25 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

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

  Explicitly lea external address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/71297615..c8c58f4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=16-17

  Stats: 11 lines in 1 file changed: 6 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Mon Jan  9 17:09:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 17:09:29 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
 [v2]
In-Reply-To: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
Message-ID: <ofO4iBdp-3cgv3tl0Fh53_p6jLMy4FuAb2-DiZ2XjrE=.5120ffd7-d94f-47f4-84b7-1b6fedc4b799@github.com>

> Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.

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

  Addressing review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/88/files
  - new: https://git.openjdk.org/jdk20/pull/88/files/b15a8bda..9a948725

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=88&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=88&range=00-01

  Stats: 15 lines in 3 files changed: 6 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/88/head:pull/88

PR: https://git.openjdk.org/jdk20/pull/88

From naoto at openjdk.org  Mon Jan  9 17:09:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 17:09:30 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
 [v2]
In-Reply-To: <o8uRqpK4nF73PQbGtwN1z-m2l_4e9m8k5ETKQGHz-0E=.5781ffa9-ff9c-452b-93a9-08e7bf41a2c4@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
 <o8uRqpK4nF73PQbGtwN1z-m2l_4e9m8k5ETKQGHz-0E=.5781ffa9-ff9c-452b-93a9-08e7bf41a2c4@github.com>
Message-ID: <jYzaEiMC-FSi13Iyh5Dw9_t8yi3EGAvI2x-o9Gq4pnQ=.c0e28208-5a34-42f6-ba77-ef03b042b515@github.com>

On Sat, 7 Jan 2023 10:35:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review suggestions
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java line 35:
> 
>> 33:  * designates the module name of the implementation, and which defaults
>> 34:  * to "java.base". If no providers is available,
>> 35:  * or instantiation failed, java.base built-in Console implementation
> 
> The overall change looks fine but I think for the next edit that we should move most of this comment to Console as it's Console that selects the behavior and that skips errors. Also once the SM execution mode goes away then we can re-visit that behavior.

Makes sense. The comment has been moved to `Console`.

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

PR: https://git.openjdk.org/jdk20/pull/88

From stsypanov at openjdk.org  Mon Jan  9 17:10:54 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 9 Jan 2023 17:10:54 GMT
Subject: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always
 copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <oJqZd78mkJCdqN2h0ewbStnNtgx4pygtZE0N_OfGAio=.d4bd66d0-372e-4e6b-b0b6-a70740676135@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

src/java.base/share/classes/java/lang/String.java line 927:

> 925:         byte[] val = s.value();
> 926:         byte coder = s.coder();
> 927:         if (coder == LATIN1 && isASCII(val)) {

Why don't we just call `s.isLatin1()` instead of `coder == LATIN1 && isASCII(val)`?

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

PR: https://git.openjdk.org/jdk/pull/11897

From serb at openjdk.org  Mon Jan  9 17:11:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Jan 2023 17:11:55 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
Message-ID: <zfEb0RIbXuxyVFxLHX-27fdbbCbk4XG70A2sHNqwFUc=.3b980565-a753-4e20-93fa-9e0edc493a59@github.com>

On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>        Modifies ImmutableCollections.listCopy:
>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>    Modifies Map.copyOf:
>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

I wonder how it will affect (if any) the performance of the common path, for example if non-empty but small ConcurrentHashMap is passed to the List.copyOf().

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

PR: https://git.openjdk.org/jdk/pull/11847

From alanb at openjdk.org  Mon Jan  9 17:21:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jan 2023 17:21:56 GMT
Subject: [jdk20] RFR: 8299689: Make use of JLine for Console as "opt-in"
 [v2]
In-Reply-To: <ofO4iBdp-3cgv3tl0Fh53_p6jLMy4FuAb2-DiZ2XjrE=.5120ffd7-d94f-47f4-84b7-1b6fedc4b799@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
 <ofO4iBdp-3cgv3tl0Fh53_p6jLMy4FuAb2-DiZ2XjrE=.5120ffd7-d94f-47f4-84b7-1b6fedc4b799@github.com>
Message-ID: <XAslFO5099b-mEhQTDSj3np4vRMve8RMdqWWilHfoY8=.5e920202-c9bd-4ff4-93f0-2d3219f28ec4@github.com>

On Mon, 9 Jan 2023 17:09:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review suggestions

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/88

From duke at openjdk.org  Mon Jan  9 17:34:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 9 Jan 2023 17:34:55 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <zfEb0RIbXuxyVFxLHX-27fdbbCbk4XG70A2sHNqwFUc=.3b980565-a753-4e20-93fa-9e0edc493a59@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <zfEb0RIbXuxyVFxLHX-27fdbbCbk4XG70A2sHNqwFUc=.3b980565-a753-4e20-93fa-9e0edc493a59@github.com>
Message-ID: <Lx0_B6SiEhwlxvQWMi0MbNeW2YRlz1-k_XvyprdexH0=.9b5786e2-3eb7-41ac-a002-01e0b54c178a@github.com>

On Mon, 9 Jan 2023 17:09:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>        Modifies ImmutableCollections.listCopy:
>>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>    Modifies Map.copyOf:
>>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.
>
> I wonder how it will affect (if any) the performance of the common path, for example if non-empty but small ConcurrentHashMap is passed to the List.copyOf().

@mrserb The "hit" is directly proportional to the cost of `isEmpty()`?but specifically for collections like ConcurrentHashMap, the very notion of "current size" is challenging at best.

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

PR: https://git.openjdk.org/jdk/pull/11847

From mchung at openjdk.org  Mon Jan  9 17:36:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Jan 2023 17:36:58 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order [v2]
In-Reply-To: <Xxo3F0JR33LiPltPDKFFOJppcFwVgUCdJSZeirI-hVw=.081c4053-0c3d-47e8-9100-1ca1b80c6cbb@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
 <e34JU_fXQTckXzi5HdBEUHAkTIV_jHSfz3V6Lb6O5kA=.a38d421f-6710-40b2-81bd-3bbdd56cfdc1@github.com>
 <Xxo3F0JR33LiPltPDKFFOJppcFwVgUCdJSZeirI-hVw=.081c4053-0c3d-47e8-9100-1ca1b80c6cbb@github.com>
Message-ID: <5m-TlvgEBySPfrHXgLFaPq1TzlMMFP1qaNkaesIO3uU=.db3884fd-ec50-43a3-b3ce-e77edb6550db@github.com>

On Sat, 7 Jan 2023 10:46:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add a regression test
>>  - further cleanup newWrongMethodTypeException for clarity
>
> test/jdk/java/lang/invoke/WrongMethodTypeTest.java line 8:
> 
>> 6:  * under the terms of the GNU General Public License version 2 only, as
>> 7:  * published by the Free Software Foundation.  Oracle designates this
>> 8:  * particular file as subject to the "Classpath" exception as provided
> 
> From what I understand, the copyright notice on test files don't use the "Classpath" exception and instead use a different copyright notice.

That's correct.   Thanks for catching it.   This reveals that the copyright header of several `test/jdk/java/lang/invoke` tests will need clean up (as this new test was copied from an existing test).

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

PR: https://git.openjdk.org/jdk/pull/11870

From duke at openjdk.org  Mon Jan  9 17:46:59 2023
From: duke at openjdk.org (Justin Lu)
Date: Mon, 9 Jan 2023 17:46:59 GMT
Subject: Integrated: 8299500: Usage of constructors of primitive wrapper
 classes should be avoided in java.text API docs
In-Reply-To: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
References: <5beb38afAjMVpmWkhEizo6dwAqadjESW5pYiwCg5JxU=.4296244c-e0d6-4c83-9c28-7641a988f07b@github.com>
Message-ID: <bo3xoS0fDk1tCd8ygg1ipn2FNbPMhGq0xyaOek2hsJA=.d3adf741-00aa-4f43-aba0-0d111018fa8f@github.com>

On Fri, 6 Jan 2023 17:42:53 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) for the following
> - _java.text.ChoiceFormat_
> - _java.text.MessageFormat_ 
> 
> Replaced with .valueOf() method

This pull request has now been integrated.

Changeset: cd10c727
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6
Stats:     8 lines in 2 files changed: 0 ins; 1 del; 7 mod

8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs

Reviewed-by: naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/11884

From mchung at openjdk.org  Mon Jan  9 18:15:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Jan 2023 18:15:42 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order [v3]
In-Reply-To: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
Message-ID: <b_0iTQ0hYM9TQkya_w9BR5j3hVlp8uwzc7I93dw4g8w=.f796d7d0-7f86-4472-9d00-85910be9a93d@github.com>

> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

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

  Update VarHandleTestExact test and new test's copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11870/files
  - new: https://git.openjdk.org/jdk/pull/11870/files/35968a32..7c963020

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11870&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11870&range=01-02

  Stats: 10 lines in 2 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11870/head:pull/11870

PR: https://git.openjdk.org/jdk/pull/11870

From smarks at openjdk.org  Mon Jan  9 18:24:51 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 9 Jan 2023 18:24:51 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
Message-ID: <wf6tFhQ8-roBqEXOCB3jq9xGzzPZeJwcJo0IOVV9ShU=.4427da12-118b-46d0-a4cf-e05ee6bf9299@github.com>

On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>        Modifies ImmutableCollections.listCopy:
>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>    Modifies Map.copyOf:
>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

Overall I think the cost of isEmpty() is likely to be relatively inexpensive, even on CHM. The CHM.isEmpty() implementation is O(n) where n is the number of counter cells, which is NOT proportional to the number of mappings contained in the map. Instead, the number of counter cells is proportional to the amount of contention there is over the map. It's hard to say what this is likely to be, but it doesn't seem obvious that this would be a pessimization.

Of course it's also possible for isEmpty() to return an out-of-date value. If it returns true and the CHM later changes size, this is a race condition, and at some point in the past we believe the CHM actually was empty; so copyOf() returning an empty collection is not an error. If isEmpty() returns false and the CHM is cleared afterward, toArray() will return an empty array. We'll end up with an empty collection, and the only penalty is that we had to go through the slow path to do that.

And yes, calling copyOf() on a collection that's being modified concurrently is a bit questionable. It'll return a snapshot of the contents at some time in the past, but if the application is aware of this, then we should be ok.

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

PR: https://git.openjdk.org/jdk/pull/11847

From naoto at openjdk.org  Mon Jan  9 18:26:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 18:26:59 GMT
Subject: [jdk20] Integrated: 8299689: Make use of JLine for Console as "opt-in"
In-Reply-To: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
References: <1Y0pELaN2mrGhHLgXtfgdO65EUNI__6wNf6oy2KKzFE=.bdd50824-05b4-4a49-ad52-d56796915261@github.com>
Message-ID: <34ZXVdltDiZjqj_KVHLzqhwRsnOw-JfQ_ZunNMfGtL0=.0a55844c-2ee8-44ed-a09c-155a6e8114a7@github.com>

On Fri, 6 Jan 2023 17:57:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Due to the fact that JLine spawns native processes to obtain terminal information on macOS/Linux, we decided to disable the JLine by default for performance degradation reasons. It is still possible to enable it by specifying it on the command line with `jdk.console` system property (not a public one though). Once we have a solution to avoid spawning processes, JLine may be back for use in the future.

This pull request has now been integrated.

Changeset: d49851a8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/d49851a8b8e80b6ffa53c2bb4f5b2897735d471f
Stats:     48 lines in 4 files changed: 24 ins; 7 del; 17 mod

8299689: Make use of JLine for Console as "opt-in"

Reviewed-by: jpai, alanb

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

PR: https://git.openjdk.org/jdk20/pull/88

From duke at openjdk.org  Mon Jan  9 18:29:55 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 9 Jan 2023 18:29:55 GMT
Subject: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always
 copy arrays
In-Reply-To: <oJqZd78mkJCdqN2h0ewbStnNtgx4pygtZE0N_OfGAio=.d4bd66d0-372e-4e6b-b0b6-a70740676135@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
 <oJqZd78mkJCdqN2h0ewbStnNtgx4pygtZE0N_OfGAio=.d4bd66d0-372e-4e6b-b0b6-a70740676135@github.com>
Message-ID: <LsEdseg9oGtpBlM6uiyw0LydSWACgZnIWZ5t6wCslpU=.e41e6178-4461-450a-bbcd-29afafb49f5e@github.com>

On Mon, 9 Jan 2023 17:07:53 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Why don't we just call `s.isLatin1()` instead of `coder == LATIN1 && isASCII(val)`?

The `isLatin1()` can only replace `coder == LATIN1`, and it is necessary to check whether it is ASCII.

In the following, we also need to pass the `coder` when calling `encodeUTF8`. Therefore, I think it is clearer to judge the `coder` directly than to call `isLatin1()`.

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

PR: https://git.openjdk.org/jdk/pull/11897

From smarks at openjdk.org  Mon Jan  9 18:29:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 9 Jan 2023 18:29:57 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
Message-ID: <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>

On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>        Modifies ImmutableCollections.listCopy:
>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>    Modifies Map.copyOf:
>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

src/java.base/share/classes/java/util/ImmutableCollections.java line 169:

> 167:     @SuppressWarnings("unchecked")
> 168:     static <E> List<E> listCopy(Collection<? extends E> coll) {
> 169:         if (coll instanceof List12 || (coll instanceof ListN && ! ((ListN<?>)coll).allowNulls)) {

Maybe replace the cast with an instanceof pattern here?

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

PR: https://git.openjdk.org/jdk/pull/11847

From pminborg at openjdk.org  Mon Jan  9 18:37:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jan 2023 18:37:56 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
Message-ID: <TbTkkR4IXRDbbe9RizXGFFvwMqKgCzxVkuqmWnM5nKY=.174c860e-1fb3-40e6-9ad4-bb99afaccecf@github.com>

On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>        Modifies ImmutableCollections.listCopy:
>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>    Modifies Map.copyOf:
>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

On the note of `CHM::isEmpty`: It would be better to rewrite this method as a short-circuitable reduction of the many CounterCells' values. As soon as at least one of them are >0 then the map is not empty. In contrast, today we sum all of the values, in many cases, unnecessary.

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

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Mon Jan  9 20:02:59 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 9 Jan 2023 20:02:59 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTestsh to jtreg java test
Message-ID: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>

Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

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

Commit messages:
 - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test

Changes: https://git.openjdk.org/jdk/pull/11910/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298939
  Stats: 240 lines in 2 files changed: 47 ins; 146 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/11910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11910/head:pull/11910

PR: https://git.openjdk.org/jdk/pull/11910

From cwimmer at openjdk.org  Mon Jan  9 20:04:34 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 9 Jan 2023 20:04:34 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
Message-ID: <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>

> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.

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

  Add comment about method inlining

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11791/files
  - new: https://git.openjdk.org/jdk/pull/11791/files/f06be05b..72667c4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11791&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11791&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11791/head:pull/11791

PR: https://git.openjdk.org/jdk/pull/11791

From cwimmer at openjdk.org  Mon Jan  9 20:04:36 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 9 Jan 2023 20:04:36 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <vnPbbKkqmAszESKiu1c6CL8Jk0xJTyTSZsVJ5tLekdY=.45264b20-9c51-46f4-a006-e222ad8f3d08@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <vnPbbKkqmAszESKiu1c6CL8Jk0xJTyTSZsVJ5tLekdY=.45264b20-9c51-46f4-a006-e222ad8f3d08@github.com>
Message-ID: <V6uHq-3p-beY_cQnVnz2ta4DOziyRDIzxOB8O5JX288=.c54bfcdb-bf92-43c4-9858-d72eaf7ae2fd@github.com>

On Tue, 27 Dec 2022 23:36:52 GMT, Ismael Juma <duke at openjdk.org> wrote:

>> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about method inlining
>
> src/java.base/share/classes/java/lang/String.java line 3133:
> 
>> 3131:         {
>> 3132:             // All the checks above can potentially be constant folded by
>> 3133:             // a JIT/AOT compiler when the regex is a constant string.
> 
> Probably worth mentioning explicitly that the private `split` was extracted to help with inlining (to reduce the probability of future regressions).

I extended the comment

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

PR: https://git.openjdk.org/jdk/pull/11791

From cwimmer at openjdk.org  Mon Jan  9 20:06:53 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 9 Jan 2023 20:06:53 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
In-Reply-To: <ad2Zj_AZmx3Dp8fP_wi3zwIF38jI9TAttio64QkR7Oc=.317ea2b3-eba0-4a87-8e16-8b01c3241cdb@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <ad2Zj_AZmx3Dp8fP_wi3zwIF38jI9TAttio64QkR7Oc=.317ea2b3-eba0-4a87-8e16-8b01c3241cdb@github.com>
Message-ID: <DjHtsU5WJNr-mQ1IJh6rGWm85mn5hRyRzAYoHl2p-bk=.77d4b4bf-f862-4ece-916c-00e60783b166@github.com>

On Wed, 28 Dec 2022 20:42:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Is there any benchmark proving the benefit?

The Graal compiler can do the inlining and constant folding. That is especially important when doing AOT compilation as part of GraalVM Native Image builds, in which case the regular expression engine of the JDK remains unreachable in many cases, leading to smaller binaries.

Currently, GraalVM uses a substitution to patch the JDK, but that is not a good long-term solution: https://github.com/oracle/graal/pull/5732/files#diff-422e3fa386126a69506423650c878a251e18cc6e6cfdb39d87923a88a97628a3R209

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

PR: https://git.openjdk.org/jdk/pull/11791

From igraves at openjdk.org  Mon Jan  9 20:41:56 2023
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 9 Jan 2023 20:41:56 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <WXmNZhZPiiv_uma2xU6mJcF-DwkY3P267rnKZt2gOMg=.927cd9e8-94a4-459d-9ddc-efb4d7c15c2a@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <WXmNZhZPiiv_uma2xU6mJcF-DwkY3P267rnKZt2gOMg=.927cd9e8-94a4-459d-9ddc-efb4d7c15c2a@github.com>
Message-ID: <D-Rp6SVtyfQbgK-OoNHVMfXDVKT5blF1PzhDrvBoWhU=.dddd54ad-576b-4053-bdfd-a678deed2748@github.com>

On Thu, 15 Dec 2022 06:43:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 27:
> 
>> 25: package jdk.tools.jlink.internal.plugins;
>> 26: 
>> 27: import java.text.NumberFormat;
> 
> I suspect this is an unused import?

Yes thank you.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 111:
> 
>> 109:                             zip = new ZipPlugin(resFilter, zipLevel);
>> 110:                             break;
>> 111:                         } catch (NumberFormatException ignored) {}
> 
> Hello Ian, previously before this change (and even now for non `zip-` values) we throw an `IllegalArgumentException` if the value for compression level is incorrect. Should we do the same for wrong values of `zip-` and throw `IllegalArgumentException` when we catch a `NumberFormatException`?

Yes, though in this case when we catch a NumberFormatException, the result falls through to the IllegalArgumentException and prints the offending level ("zip-*") value.

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

PR: https://git.openjdk.org/jdk/pull/11617

From darcy at openjdk.org  Mon Jan  9 20:44:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Jan 2023 20:44:52 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <TBYSWKqcKhyLLYl1DheNn2guKPaTmZJIegHFqaTa-DI=.3b0dc05d-f9ca-4532-856b-c2162d4dc803@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
 <8aowsJzamy0T0FooFgDPVVu_9m_OYVQgQdpAKTXFAbI=.87f52413-31fb-4c55-a0bc-70e3678d48e4@github.com>
 <EArajXgA160WMGw3l1815HBoTN1qNovQsmtEqA3y_-0=.41fdbc97-b741-40d2-90c2-3e57c84cee29@github.com>
 <oYd4iDgm15e08cSakkZPySMd2BUwPqJP63_0BPU9N6Q=.cc41c725-f17f-4a11-a448-c5cf00192da4@github.com>
 <TBYSWKqcKhyLLYl1DheNn2guKPaTmZJIegHFqaTa-DI=.3b0dc05d-f9ca-4532-856b-c2162d4dc803@github.com>
Message-ID: <9fD7mNCizlQdJTy5H_hyICCq-U10VW5X_fNfpidAP7Y=.9aedce75-6a64-4bcd-9890-181331d14a10@github.com>

On Mon, 9 Jan 2023 13:17:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I see - thanks for the explanation - the problem is with `floatToIntBits` vs `floatToRawIntBits` in the "put" operation. The get operation is ok, but then having asymmetry where we use a float VH in one case (get) but not in the other (put) is not desirable.
>
> @mcimadamore According to the spec, `floatToRawIntBits` and `doubleToRawLongBits` ensure that the original input bits are all preserved, even for NaN values.
> On the other hand, the spec says that `intBitsToFloat` and `longBitsToDouble` only ensure a best effort in preserving the output bits of NaN values.
> So I think `VarHandle` `get` and `put` do their best to preserve the bits, but no more than the underlying platform can possibly offer.
> This behavior for floating-point values is not fully specified in `VarHandle`, so there's room for improvement in the doc.

At least for the purposes of this PR, I think leaving the calls to the bitwise conversion methods in place is fine.

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

PR: https://git.openjdk.org/jdk/pull/11840

From igraves at openjdk.org  Mon Jan  9 20:48:55 2023
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 9 Jan 2023 20:48:55 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <WXmNZhZPiiv_uma2xU6mJcF-DwkY3P267rnKZt2gOMg=.927cd9e8-94a4-459d-9ddc-efb4d7c15c2a@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <WXmNZhZPiiv_uma2xU6mJcF-DwkY3P267rnKZt2gOMg=.927cd9e8-94a4-459d-9ddc-efb4d7c15c2a@github.com>
Message-ID: <U0W4R2ouB3kSCrzotNs8Zm-g1uaQGOpROX9gXKDpjV0=.b58a46ac-67d9-42cc-bce7-55b6d950fe77@github.com>

On Thu, 15 Dec 2022 06:45:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 49:
> 
>> 47: 
>> 48:     private static final int DEFAULT_COMPRESSION = 6;
>> 49:     private int compressionLevel;
> 
> Perhaps we could mark this as `final`?

Agreed

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

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Mon Jan  9 21:05:43 2023
From: duke at openjdk.org (Victor Toni)
Date: Mon, 9 Jan 2023 21:05:43 GMT
Subject: RFR: 8203035: Implement equals() and hashCode() for Throwable
Message-ID: <kUAymdlB4YL_BLTzTlvWvXjcGWRCEpe_hGU-2wr3NLo=.d53bc474-3c62-474f-a738-a5319aed1d68@github.com>

Being able to compare instances of Throwable allows simple detection of exceptions raised by the same circumstances. Comparison allows for reduction of excessive logging e.g. in hotspots without requiring custom code to compare Throwables.

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

Commit messages:
 - 8203035: Implement equals() and hashCode() for Throwable

Changes: https://git.openjdk.org/jdk/pull/11624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8203035
  Stats: 329 lines in 2 files changed: 329 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11624/head:pull/11624

PR: https://git.openjdk.org/jdk/pull/11624

From aturbanov at openjdk.org  Mon Jan  9 21:23:37 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 9 Jan 2023 21:23:37 GMT
Subject: RFR: 8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes
Message-ID: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>

`jdk.internal.jrtfs.JrtFileSystem#getFileAttributes` never return `null`

https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L206-L213
So, no need to check for `null` its result.
Seems it was copied from ZipPath (name of variable suggests that) - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L769. But for ZipFileSystem `null` is expected.

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

Commit messages:
 - [PATCH] Unnecessary null check in JrtPath.getAttributes

Changes: https://git.openjdk.org/jdk/pull/11911/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299835
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11911.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11911/head:pull/11911

PR: https://git.openjdk.org/jdk/pull/11911

From duke at openjdk.org  Mon Jan  9 21:28:02 2023
From: duke at openjdk.org (Justin Lu)
Date: Mon, 9 Jan 2023 21:28:02 GMT
Subject: Integrated: 8299502: Usage of constructors of primitive wrapper
 classes should be avoided in javax.xml API docs
In-Reply-To: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
Message-ID: <MwPPS2R54ZGhKXwELYBWdOxNX6GksUb_jFZSwhzP4Xg=.8430fac9-4430-47b3-8480-c24a73a93af8@github.com>

On Thu, 5 Jan 2023 21:59:30 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
> 
> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE

This pull request has now been integrated.

Changeset: b8852f65
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8852f65a0adcb9ee5693bb6727a0668aa9808bf
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs

Reviewed-by: joehw, naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Mon Jan  9 21:29:00 2023
From: duke at openjdk.org (Justin Lu)
Date: Mon, 9 Jan 2023 21:29:00 GMT
Subject: Integrated: 8299501: Usage of constructors of primitive wrapper
 classes should be avoided in java.util API docs
In-Reply-To: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
References: <Z-TR8oONVprJf-rkNwBH_Ir2p-dOOcn-IpYZTcU6G2Q=.31764ea1-56ed-4877-a9fa-55f8044ef36a@github.com>
Message-ID: <ZNcPgp4MtavlPQa1xG5j-uxBwRq5yAtslW-ue2x428g=.4d5059e0-8f9c-47a6-a732-ecefce5d1040@github.com>

On Fri, 6 Jan 2023 18:54:07 GMT, Justin Lu <duke at openjdk.org> wrote:

> Removed constructors of primitive wrapper classes (deprecated for removal) in  _java.util.Arrays_
> 
> Replaced with .valueOf() method

This pull request has now been integrated.

Changeset: f36f1354
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f36f1354c63a500c70ae51a9c2b2d21ad55cfa77
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs

Reviewed-by: naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/11885

From duke at openjdk.org  Mon Jan  9 21:35:52 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 9 Jan 2023 21:35:52 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <TbTkkR4IXRDbbe9RizXGFFvwMqKgCzxVkuqmWnM5nKY=.174c860e-1fb3-40e6-9ad4-bb99afaccecf@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <TbTkkR4IXRDbbe9RizXGFFvwMqKgCzxVkuqmWnM5nKY=.174c860e-1fb3-40e6-9ad4-bb99afaccecf@github.com>
Message-ID: <egX4XTxGPzpXI0B7zqvGJMJvH6fLkx2UkhuXGpNGAzk=.c04acb3d-c51f-47a1-acff-bd14af61efbd@github.com>

On Mon, 9 Jan 2023 18:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>        Modifies ImmutableCollections.listCopy:
>>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>    Modifies Map.copyOf:
>>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.
>
> On the note of `CHM::isEmpty`: It would be better to rewrite this method as a short-circuitable reduction of the many CounterCells' values. As soon as at least one of them are >0 then the map is not empty. In contrast, today we sum all of the values, in many cases, unnecessary.

@minborg Yes, I noted that when I looked into the current impl of CHM.isEmpty() as well. Seems like either a bespoke isEmpty implementation, or having isEmpty() rely on a more generalized "isLargerThan(0)" would be appropriate. With that said, I'm hesitant to make any modifications to CHM as a part of this PR :)

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

PR: https://git.openjdk.org/jdk/pull/11847

From mchung at openjdk.org  Mon Jan  9 21:41:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Jan 2023 21:41:58 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option
In-Reply-To: <3qBQbDWN99tyr32fbrT86WixwxSPzA235ISVqt70f5I=.b6202387-ed59-4124-809e-58771ed5bffa@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <3qBQbDWN99tyr32fbrT86WixwxSPzA235ISVqt70f5I=.b6202387-ed59-4124-809e-58771ed5bffa@github.com>
Message-ID: <7azCDfhh8pLeQtPfhvwoiUrNF0QlnjP7NuVkoKJurYs=.0e7d23a0-554c-49d0-99c1-adc71f9046f7@github.com>

On Mon, 12 Dec 2022 14:17:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through this (not a detailed review) and I think it's mostly okay. It's --compress 0 and 2 that should be listed as deprecated as --compress 1 is string sharing rather than zip compression.

I also think it's good to deprecate the old values.   I think we can separate the StringSharingPlugin as a separate plugin option and deprecate --compress 1 as well.   Something like this:


  --compress <compress>               Compression to use in compressing resources:
                                        Accepted values are:  
                                        zip-[0-9], where zip-0 provides no  
                                        compression, and zip-9 provides the 
                                        best compression. Default is zip-6.
                                        Deprecated values:
                                        0:  No compression. Equivalent to zip-0.
                                        1:  Equivalent to --compact-constant-pools
                                        2:  Equivalent to zip-6.

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

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Mon Jan  9 21:53:56 2023
From: duke at openjdk.org (Justin Lu)
Date: Mon, 9 Jan 2023 21:53:56 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs
Message-ID: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>

The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:

java.lang.ArrayStoreException
java.lang.ClassCastException
java.lang.Double.compare(double, double)
java.lang.Float.compare(float, float)
java.lang.Integer.getInteger(String, int)
java.lang.Integer.valueOf(String)
java.lang.Integer.valueOf(String, int)
java.lang.Long.getLong(String, long)
java.lang.Long.valueOf(String)
java.lang.Long.valueOf(String, int)
java.lang.Short.valueOf(String)
java.lang.Short.valueOf(String, int) 

This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

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

Commit messages:
 - Fix Integer
 - Fix Long
 - Fix Short
 - Fix ASE, Double, Float

Changes: https://git.openjdk.org/jdk/pull/11912/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11912&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299498
  Stats: 19 lines in 6 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/11912.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11912/head:pull/11912

PR: https://git.openjdk.org/jdk/pull/11912

From duke at openjdk.org  Mon Jan  9 22:13:57 2023
From: duke at openjdk.org (Justin Lu)
Date: Mon, 9 Jan 2023 22:13:57 GMT
Subject: Integrated: 6381945: (cal) Japanese calendar unit test system should
 avoid multiple static imports
In-Reply-To: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
References: <f4wmT52fL0lCivElrgCtsDNAJKl6Fa-Qyw4WX0OVgGk=.d9511063-55b8-432c-967b-27458ba0f378@github.com>
Message-ID: <8ApzF3tkVBLvB79FhBYPCKuD2bwxns6ofVnI9yVCRWE=.34c386ef-0b74-48c4-bf78-1a7d73c63178@github.com>

On Wed, 4 Jan 2023 21:49:18 GMT, Justin Lu <duke at openjdk.org> wrote:

> Within _test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java_
> 
> GregorianCalendar alone handles all the necessary imports, Calendar is not needed

This pull request has now been integrated.

Changeset: f79b3d42
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f79b3d42f07b703f0e3b9fc67c92dee260b0e602
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

6381945: (cal) Japanese calendar unit test system should avoid multiple static imports

Reviewed-by: lancea, iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/11855

From jwilhelm at openjdk.org  Mon Jan  9 22:30:21 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 9 Jan 2023 22:30:21 GMT
Subject: RFR: Merge jdk20
Message-ID: <0F0t-iGx4y1JbU5e0XOucZ6bPa7jeDXZ8rdeXu3KmuQ=.6ef59616-bfd8-4574-9f7d-38b51ef522e4@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299689: Make use of JLine for Console as "opt-in"

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11913&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11913&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11913/files
  Stats: 48 lines in 4 files changed: 24 ins; 7 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/11913.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11913/head:pull/11913

PR: https://git.openjdk.org/jdk/pull/11913

From alexey.semenyuk at oracle.com  Mon Jan  9 22:57:00 2023
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 9 Jan 2023 17:57:00 -0500
Subject: jpackageapplauncher linker arguments for osx
In-Reply-To: <7ab61fe5-9073-84db-d2d3-e9e4682b366f@oracle.com>
References: <CAMrs=afcH+CUhY62dO=VeO7A3R++eMusdSESg9qPSMbJpSUx+g@mail.gmail.com>
 <7ab61fe5-9073-84db-d2d3-e9e4682b366f@oracle.com>
Message-ID: <70f0b82a-ff2c-9e18-e447-0df51becc110@oracle.com>

Hi David,

The request to adjust osx linker command lines looks reasonable. Please 
go ahead with a pull request.

- Alexey

On 1/9/2023 1:21 AM, David Holmes wrote:
> On 8/01/2023 8:39 pm, David Schumann wrote:
>> Hello,
>>
>> I'm not 100% sure if this list is the correct one for this topic, 
>> feel free to redirect me.
>
> core-libs-dev - cc'd
>
> Cheers,
> David
>
>> Currently the?jpackageapplauncher binary gets linked without the 
>> "-headerpad_max_install_names" argument on osx. This prevents a user 
>> from using the install_name_tool with the launcher binary.
>> This means that it's currently not possible to include dylibs in the 
>> application bundle.
>>
>> To provide a bit more context:
>> I'm using jpackage to build an app bundle. The java application 
>> itself uses external native libraries, which internally use dlopen to 
>> reference other libs. Normaly one would include the other libs in the 
>> app bundle, and use the install_name_tool to tell the dynamic linker 
>> which paths to load the libraries from. However since the launcher 
>> binary doesn't get linked with the correct arguments, this isn't 
>> possible.
>>
>> I wanted to discuss this change, and it it makes sense for me to open 
>> a pull request for it.
>> The change would be in 
>> https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76 
>> <https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76> 
>>
>>
>> Best Regards,
>> David Schumann
>>


From asemenyuk at openjdk.org  Mon Jan  9 23:02:04 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Jan 2023 23:02:04 GMT
Subject: RFR: 8298735: Some tools/jpackage/windows/* tests fails with jtreg
 test timeout
Message-ID: <BoHagQ4Eyn_D7q_dSw8IZvfJExOV5aDfm_EhMvcMVi8=.80d4f01e-97ae-4571-bb65-bbba4f58ad90@github.com>

Increase failed test timeouts.
Simple tests got an x1.5 increase and parametrized tests got an x2 increase

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

Commit messages:
 - 8298735: Some tools/jpackage/windows/* tests fails with jtreg test timeout

Changes: https://git.openjdk.org/jdk/pull/11914/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298735
  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11914.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11914/head:pull/11914

PR: https://git.openjdk.org/jdk/pull/11914

From redestad at openjdk.org  Mon Jan  9 23:17:00 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Jan 2023 23:17:00 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
Message-ID: <BItgwfh46nW3qkM6xcSkc-h85qzl0oiwJLsHxMtj6AQ=.6b233899-7876-4d62-94f2-270cd7a3ab44@github.com>

On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly lea external address

Explicitly loading the address to a register seems to do the trick, avoiding the pitfalls of `as_Address(AddressLiteral)` - which apparently only works (portably) when we know for certain the address is in some allowed range. There's no measurable difference on microbenchmarks (there might be a couple of extra lea instructions on the vectorized paths, but that disappears in the noise). Thanks @fisk for the suggestion!

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

PR: https://git.openjdk.org/jdk/pull/10847

From sspitsyn at openjdk.org  Mon Jan  9 23:17:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Jan 2023 23:17:55 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v2]
In-Reply-To: <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
References: <Q9aSWyhdNcS73UVmoosyrDRJZnqqAPk_G99quTgutxA=.76691773-e4c2-4190-bc6d-e54d11f1ae33@github.com>
 <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
Message-ID: <55O_xJx412kcO8MhN5FF7iKHxHsh-aDVyNicIi7oeHM=.9d261cd0-7d22-4931-8c7f-e1fee9d4a4a4@github.com>

On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This problem has two sides.
>> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value.
>> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents`
>> value has been set to `true` when an agent library is loaded into running VM.
>> The fix is to get rid of this cashing.
>> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization.
>> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire.
>> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync.
>> 
>> Testing:
>> The originally failed tests are passed now:
>> 
>> runtime/vthread/RedefineClass.java
>> runtime/vthread/TestObjectAllocationSampleEvent.java 
>> 
>> In progress:
>> Run the tiers 1-6 to make sure there are no regression.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove caching if notifyJvmtiEvents in yieldContinuation

One more artificial comment to keep the PR alive.

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

PR: https://git.openjdk.org/jdk/pull/11304

From jwilhelm at openjdk.org  Mon Jan  9 23:34:58 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 9 Jan 2023 23:34:58 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <0F0t-iGx4y1JbU5e0XOucZ6bPa7jeDXZ8rdeXu3KmuQ=.6ef59616-bfd8-4574-9f7d-38b51ef522e4@github.com>
References: <0F0t-iGx4y1JbU5e0XOucZ6bPa7jeDXZ8rdeXu3KmuQ=.6ef59616-bfd8-4574-9f7d-38b51ef522e4@github.com>
Message-ID: <1qsnUFtQVBBDL3EybpslbMMTquL-6rOWpql11B66Fl0=.b86784a6-3a4c-4727-b0a3-6511202652b7@github.com>

On Mon, 9 Jan 2023 22:22:11 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 4395578b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4395578b6f0432d158c4b6c0c0a9d0838f74baa8
Stats:     48 lines in 4 files changed: 24 ins; 7 del; 17 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11913

From naoto at openjdk.org  Mon Jan  9 23:51:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jan 2023 23:51:51 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs
In-Reply-To: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
Message-ID: <Q34dy4Dign_rLyAphO4INtEFAO4YEaKwMHVWOo1O5ts=.5f0f0e3b-1b17-46ac-a41a-7acc65c9e88d@github.com>

On Mon, 9 Jan 2023 21:46:49 GMT, Justin Lu <duke at openjdk.org> wrote:

> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
> 
> java.lang.ArrayStoreException
> java.lang.ClassCastException
> java.lang.Double.compare(double, double)
> java.lang.Float.compare(float, float)
> java.lang.Integer.getInteger(String, int)
> java.lang.Integer.valueOf(String)
> java.lang.Integer.valueOf(String, int)
> java.lang.Long.getLong(String, long)
> java.lang.Long.valueOf(String)
> java.lang.Long.valueOf(String, int)
> java.lang.Short.valueOf(String)
> java.lang.Short.valueOf(String, int) 
> 
> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11912

From duke at openjdk.org  Tue Jan 10 00:07:02 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 00:07:02 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable
Message-ID: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>

The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.

This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.

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

Commit messages:
 - Fix setDefault()
 - second user.timezone fix
 - Switch tag

Changes: https://git.openjdk.org/jdk/pull/11915/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299836
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11915.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11915/head:pull/11915

PR: https://git.openjdk.org/jdk/pull/11915

From serb at openjdk.org  Tue Jan 10 00:28:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 10 Jan 2023 00:28:55 GMT
Subject: RFR: 8299513: Cleanup java.io [v4]
In-Reply-To: <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
Message-ID: <c6yB1UAHuFwZMEl0iNbRnJ-M9B1qBYWRKCFVAGNskkI=.711fa8e0-4a2b-4313-9b7d-20eda5ca7a3f@github.com>

On Mon, 9 Jan 2023 08:57:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional (c) years

src/java.base/share/classes/java/io/DataInputStream.java line 582:

> 580:      * @see        java.io.DataInputStream#readUnsignedShort()
> 581:      */
> 582:     public static String readUTF(DataInput in) throws IOException {

I remember a few years ago asked to create a CCC to remove the final keyword in the final class. This change seems broader, probably the rules are changed since then, but this one actually may affect the method signature. And subclasses will allow hiding this method.

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

PR: https://git.openjdk.org/jdk/pull/11848

From sviswanathan at openjdk.org  Tue Jan 10 00:28:58 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 10 Jan 2023 00:28:58 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <BItgwfh46nW3qkM6xcSkc-h85qzl0oiwJLsHxMtj6AQ=.6b233899-7876-4d62-94f2-270cd7a3ab44@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
 <BItgwfh46nW3qkM6xcSkc-h85qzl0oiwJLsHxMtj6AQ=.6b233899-7876-4d62-94f2-270cd7a3ab44@github.com>
Message-ID: <k-hGVU32ERSEKPe8ShboYwKvcKIBVYNI9UlGF_Gt67Q=.5a588234-95f2-44ea-961e-8c666f54ad96@github.com>

On Mon, 9 Jan 2023 23:13:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicitly lea external address
>
> Explicitly loading the address to a register seems to do the trick, avoiding the pitfalls of `as_Address(AddressLiteral)` - which apparently only works (portably) when we know for certain the address is in some allowed range. There's no measurable difference on microbenchmarks (there might be a couple of extra lea instructions on the vectorized paths, but that disappears in the noise). Thanks @fisk for the suggestion!

Thanks @cl4es for fixing this issue. Changes look good to me.

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

PR: https://git.openjdk.org/jdk/pull/10847

From naoto at openjdk.org  Tue Jan 10 00:34:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jan 2023 00:34:52 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable
In-Reply-To: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
Message-ID: <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>

On Mon, 9 Jan 2023 23:59:19 GMT, Justin Lu <duke at openjdk.org> wrote:

> The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.
> 
> This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.

src/java.base/share/classes/java/util/TimeZone.java line 634:

> 632:      *
> 633:      * <ul>
> 634:      * <li>Use the {@systemProperty user.timezone} property value as the default

I'd only modify this location and keep others intact. Otherwise, the search would show all locations which may not best serve the user's needs.

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

PR: https://git.openjdk.org/jdk/pull/11915

From duke at openjdk.org  Tue Jan 10 00:46:35 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 00:46:35 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
Message-ID: <booD5DTZARyLMvJGOuYaHFUW3phrjF3-0XReKAozjBg=.74bc5713-175e-460d-8ff9-084996c0b4bf@github.com>

> The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.
> 
> This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.

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

  Toggle first instance as a system property, revert rest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11915/files
  - new: https://git.openjdk.org/jdk/pull/11915/files/8962d0d4..6935162e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11915&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11915&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11915.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11915/head:pull/11915

PR: https://git.openjdk.org/jdk/pull/11915

From duke at openjdk.org  Tue Jan 10 00:46:38 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 00:46:38 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>
Message-ID: <-CcRErvCFHvXsQx3fhUS9SW4leNiYANXNAd478K2Er8=.bcd8328b-0433-4527-ac2b-807118bc2f85@github.com>

On Tue, 10 Jan 2023 00:31:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Toggle first instance as a system property, revert rest
>
> src/java.base/share/classes/java/util/TimeZone.java line 634:
> 
>> 632:      *
>> 633:      * <ul>
>> 634:      * <li>Use the {@systemProperty user.timezone} property value as the default
> 
> I'd only modify this location and keep others intact. Otherwise, the search would show all locations which may not best serve the user's needs.

Good point, I reverted the rest, so that only this first instance is tagged as _ at systemProperty_

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

PR: https://git.openjdk.org/jdk/pull/11915

From darcy at openjdk.org  Tue Jan 10 01:05:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Jan 2023 01:05:54 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs
In-Reply-To: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
Message-ID: <p-KRdleQ5-WX_VZ0fz2yamK3mlD8XxYF5I8TiiqWrF8=.c37b888f-f9d1-4c8d-a41c-04727217b8d8@github.com>

On Mon, 9 Jan 2023 21:46:49 GMT, Justin Lu <duke at openjdk.org> wrote:

> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
> 
> java.lang.ArrayStoreException
> java.lang.ClassCastException
> java.lang.Double.compare(double, double)
> java.lang.Float.compare(float, float)
> java.lang.Integer.getInteger(String, int)
> java.lang.Integer.valueOf(String)
> java.lang.Integer.valueOf(String, int)
> java.lang.Long.getLong(String, long)
> java.lang.Long.valueOf(String)
> java.lang.Long.valueOf(String, int)
> java.lang.Short.valueOf(String)
> java.lang.Short.valueOf(String, int) 
> 
> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

Looks fine.

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

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11912

From mchung at openjdk.org  Tue Jan 10 01:16:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 10 Jan 2023 01:16:53 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs
In-Reply-To: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
Message-ID: <-EJpt1f2NeWKSVI9u3ahSG5czburRT-4wKfVtkx1SWI=.2015c276-e496-4cb1-af2c-a699792a04dc@github.com>

On Mon, 9 Jan 2023 21:46:49 GMT, Justin Lu <duke at openjdk.org> wrote:

> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
> 
> java.lang.ArrayStoreException
> java.lang.ClassCastException
> java.lang.Double.compare(double, double)
> java.lang.Float.compare(float, float)
> java.lang.Integer.getInteger(String, int)
> java.lang.Integer.valueOf(String)
> java.lang.Integer.valueOf(String, int)
> java.lang.Long.getLong(String, long)
> java.lang.Long.valueOf(String)
> java.lang.Long.valueOf(String, int)
> java.lang.Short.valueOf(String)
> java.lang.Short.valueOf(String, int) 
> 
> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

It'd be good to update the javadoc of  `Byte.valueOf(String s)` and `Byte.valueOf(String s, int radix)`  to replace  `new Byte(...)` with `Byte.valueOf`.

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

PR: https://git.openjdk.org/jdk/pull/11912

From bchristi at openjdk.org  Tue Jan 10 01:19:01 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 10 Jan 2023 01:19:01 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <BPGeq1ebmVJWTzKbivBCRS-0yZM2Y4V-rUa9pMIha4w=.949872c2-614f-4282-bd7d-e67eaa8a9704@github.com>

On Fri, 22 Jul 2022 20:51:59 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.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Keepalive

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

PR: https://git.openjdk.org/jdk/pull/8311

From duke at openjdk.org  Tue Jan 10 01:20:50 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 01:20:50 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs
In-Reply-To: <-EJpt1f2NeWKSVI9u3ahSG5czburRT-4wKfVtkx1SWI=.2015c276-e496-4cb1-af2c-a699792a04dc@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <-EJpt1f2NeWKSVI9u3ahSG5czburRT-4wKfVtkx1SWI=.2015c276-e496-4cb1-af2c-a699792a04dc@github.com>
Message-ID: <S-BfcMPSHYgPolXKdG2Lp-0uw8ZVi5eeUbSmqsOE4-4=.7f62dcf8-b06d-4750-8645-32da7e531c58@github.com>

On Tue, 10 Jan 2023 01:14:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It'd be good to update the javadoc of `Byte.valueOf(String s)` and `Byte.valueOf(String s, int radix)` to replace `new Byte(...)` with `Byte.valueOf`.

Thanks for spotting that, I will also add those changes into this PR.

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

PR: https://git.openjdk.org/jdk/pull/11912

From jpai at openjdk.org  Tue Jan 10 01:37:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:37:53 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <booD5DTZARyLMvJGOuYaHFUW3phrjF3-0XReKAozjBg=.74bc5713-175e-460d-8ff9-084996c0b4bf@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <booD5DTZARyLMvJGOuYaHFUW3phrjF3-0XReKAozjBg=.74bc5713-175e-460d-8ff9-084996c0b4bf@github.com>
Message-ID: <QI3k2S_5unLG2O1OlIYFTqtwbvmyi9Rdx33ygZHxR4Y=.a42f2f81-e96a-4434-b792-241722c8de5a@github.com>

On Tue, 10 Jan 2023 00:46:35 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.
>> 
>> This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Toggle first instance as a system property, revert rest

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11915

From jpai at openjdk.org  Tue Jan 10 01:37:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:37:54 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <-CcRErvCFHvXsQx3fhUS9SW4leNiYANXNAd478K2Er8=.bcd8328b-0433-4527-ac2b-807118bc2f85@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>
 <-CcRErvCFHvXsQx3fhUS9SW4leNiYANXNAd478K2Er8=.bcd8328b-0433-4527-ac2b-807118bc2f85@github.com>
Message-ID: <plmoO5VXQVrZMq3uRid0jZw6YPK8nRK6FpWcCkGkHUc=.c6fa274f-504e-418a-b2d4-5be81392ce59@github.com>

On Tue, 10 Jan 2023 00:42:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 634:
>> 
>>> 632:      *
>>> 633:      * <ul>
>>> 634:      * <li>Use the {@systemProperty user.timezone} property value as the default
>> 
>> I'd only modify this location and keep others intact. Otherwise, the search would show all locations which may not best serve the user's needs.
>
> Good point, I reverted the rest, so that only this first instance is tagged as _ at systemProperty_

Like Naoto notes, my understanding of it is that the `@systemProperty` should appear only once at the place where the semantics of that system property is being defined. This mail, which was sent when this tag was introduced, has more details https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056653.html.

I think using it here is fine, but you may want to check how it "reads" on the generated javadoc index page for system properties.

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

PR: https://git.openjdk.org/jdk/pull/11915

From jpai at openjdk.org  Tue Jan 10 01:53:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:53:54 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <plmoO5VXQVrZMq3uRid0jZw6YPK8nRK6FpWcCkGkHUc=.c6fa274f-504e-418a-b2d4-5be81392ce59@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>
 <-CcRErvCFHvXsQx3fhUS9SW4leNiYANXNAd478K2Er8=.bcd8328b-0433-4527-ac2b-807118bc2f85@github.com>
 <plmoO5VXQVrZMq3uRid0jZw6YPK8nRK6FpWcCkGkHUc=.c6fa274f-504e-418a-b2d4-5be81392ce59@github.com>
Message-ID: <DWsJK1b4e57rqD8TRluqxHZg4Cu7o7E4KfmRGUUdy30=.364ec5c8-8f01-4b1b-90e5-965db5a42148@github.com>

On Tue, 10 Jan 2023 01:34:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> but you may want to check how it "reads" on the generated javadoc index page for system properties.

For clarity, I meant the page where you will see all the system properties - there's a "Index" on top of the javadoc API page https://docs.oracle.com/en/java/javase/19/docs/api/index.html which leads to a page which has a link to the "System Properties" page, which should lead to https://docs.oracle.com/en/java/javase/19/docs/api/system-properties.html

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

PR: https://git.openjdk.org/jdk/pull/11915

From jpai at openjdk.org  Tue Jan 10 01:56:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:56:57 GMT
Subject: RFR: 8297306: Incorrect brackets in Javadoc for a constructor of
 IteratorSpliterator [v2]
In-Reply-To: <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
 <Vjp3q5ondTkT-cCoZyhK-o2kDdoIQUdmrjLE2EDcDkQ=.7c1c4a65-c14f-4b4f-9aba-54868fcb873a@github.com>
Message-ID: <3tI_qQWf6jSX7oqldK-6V8nJ8sZY3aGcq7oayM9X_n0=.eb5c1ebe-c760-4100-97c4-fe8fcd639b2a@github.com>

On Mon, 9 Jan 2023 01:09:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update another javadoc

Thank you everyone for the reviews.

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

PR: https://git.openjdk.org/jdk/pull/11876

From jpai at openjdk.org  Tue Jan 10 01:56:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:56:58 GMT
Subject: Integrated: 8297306: Incorrect brackets in Javadoc for a constructor
 of IteratorSpliterator
In-Reply-To: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
References: <o6buKzxJ7VcIJJ9bvTd_m670SXXZIqPmSARBfAhA5Ak=.0a3ce179-14c4-42b5-a2a8-a31ac9ce15e0@github.com>
Message-ID: <gUupKsMjp_7MLvj74hRWSoc_ic4OYYqx-0RQhc1q9tc=.128fd362-4077-4a4a-83fa-19bcebaa2597@github.com>

On Fri, 6 Jan 2023 06:35:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes an issue in the javadoc text of the internal class IteratorSpliterator? This addresses the issue reported at  https://bugs.openjdk.org/browse/JDK-8297306.

This pull request has now been integrated.

Changeset: b7eb4e2f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7eb4e2ffd3bce12fd960ab8102bfaabf89e8865
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8297306: Incorrect brackets in Javadoc for a constructor of IteratorSpliterator

Reviewed-by: alanb, iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/11876

From jpai at openjdk.org  Tue Jan 10 01:57:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jan 2023 01:57:52 GMT
Subject: RFR: 8299183: Invokers.checkExactType passes parameters to create
 WMTE in opposite order [v3]
In-Reply-To: <b_0iTQ0hYM9TQkya_w9BR5j3hVlp8uwzc7I93dw4g8w=.f796d7d0-7f86-4472-9d00-85910be9a93d@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
 <b_0iTQ0hYM9TQkya_w9BR5j3hVlp8uwzc7I93dw4g8w=.f796d7d0-7f86-4472-9d00-85910be9a93d@github.com>
Message-ID: <sfs-suA8PWFmEom90QewMzvO-rPKPIxQ3rQTASas8mA=.2e74dd03-de75-418b-ad4f-9d931971bb83@github.com>

On Mon, 9 Jan 2023 18:15:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update VarHandleTestExact test and new test's copyright header

Thank you Mandy for the changes. Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11870

From smarks at openjdk.org  Tue Jan 10 02:03:55 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 10 Jan 2023 02:03:55 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <mU_b-yOSWNdY0t6THkAkRhIP32KMswd0LDr2cg5s_Qs=.64e71317-1216-4171-a9cc-91ee58785d08@github.com>

On Fri, 22 Jul 2022 20:51:59 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.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

`Reference.reachabilityFence(this)`

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

PR: https://git.openjdk.org/jdk/pull/8311

From almatvee at openjdk.org  Tue Jan 10 05:07:52 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 10 Jan 2023 05:07:52 GMT
Subject: RFR: 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed
 AddLauncherTest.bug8230933
In-Reply-To: <mYJaZI6qEi_uWlrL4JEljwlsUsjrDwZ__ESSCZfnHYg=.72f840bd-72fe-43af-a9ae-2d6d3e567d8b@github.com>
References: <mYJaZI6qEi_uWlrL4JEljwlsUsjrDwZ__ESSCZfnHYg=.72f840bd-72fe-43af-a9ae-2d6d3e567d8b@github.com>
Message-ID: <DiBg8xSGumsCHV-CoegY_Y_vut4MleBRFGE_EUSHYi0=.ef251118-cbea-4281-b83f-981af608669f@github.com>

On Thu, 5 Jan 2023 20:10:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933

Marked as reviewed by almatvee (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11868

From almatvee at openjdk.org  Tue Jan 10 05:38:51 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 10 Jan 2023 05:38:51 GMT
Subject: RFR: 8298735: Some tools/jpackage/windows/* tests fails with jtreg
 test timeout
In-Reply-To: <BoHagQ4Eyn_D7q_dSw8IZvfJExOV5aDfm_EhMvcMVi8=.80d4f01e-97ae-4571-bb65-bbba4f58ad90@github.com>
References: <BoHagQ4Eyn_D7q_dSw8IZvfJExOV5aDfm_EhMvcMVi8=.80d4f01e-97ae-4571-bb65-bbba4f58ad90@github.com>
Message-ID: <5Q7iV58cc1n15m47X1aE4-0aunmR9vxmsPZjT29kjz0=.dfe25bb2-73fd-4bc2-adfb-a9bd7ea1b931@github.com>

On Mon, 9 Jan 2023 22:53:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Increase failed test timeouts.
> Simple tests got an x1.5 increase and parametrized tests got an x2 increase

Marked as reviewed by almatvee (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11914

From alanb at openjdk.org  Tue Jan 10 07:28:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jan 2023 07:28:55 GMT
Subject: RFR: 8299513: Cleanup java.io [v4]
In-Reply-To: <c6yB1UAHuFwZMEl0iNbRnJ-M9B1qBYWRKCFVAGNskkI=.711fa8e0-4a2b-4313-9b7d-20eda5ca7a3f@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <AYZleyn4bjKdZFiHfx_x7j5qJRSy4qHdMdxEzVRuicA=.4672f425-1468-46aa-b80a-8d946ac4c9ad@github.com>
 <c6yB1UAHuFwZMEl0iNbRnJ-M9B1qBYWRKCFVAGNskkI=.711fa8e0-4a2b-4313-9b7d-20eda5ca7a3f@github.com>
Message-ID: <76vMjJE6kx7CZCBNOfqqWyhje11_023jiMYfgaK74EY=.7e8da52c-a4d4-43d7-95d0-8b0059833ef9@github.com>

On Tue, 10 Jan 2023 00:26:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add additional (c) years
>
> src/java.base/share/classes/java/io/DataInputStream.java line 582:
> 
>> 580:      * @see        java.io.DataInputStream#readUnsignedShort()
>> 581:      */
>> 582:     public static String readUTF(DataInput in) throws IOException {
> 
> I remember a few years ago asked to create a CCC to remove the final keyword of the method in the final class. This change seems broader, probably the rules are changed since then, but this one actually may affect the method signature. And subclasses will allow hiding this method.

Now that you bring it up, a final modifier on static methods does show up in the javadoc, and is included in signature tests too.

@minborg I agree the final modifier doesn't make sense here but I think it will need a CSR to track the sig change.If you don't want to do that then just drop this part, and it can be done separately.

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

PR: https://git.openjdk.org/jdk/pull/11848

From alanb at openjdk.org  Tue Jan 10 08:13:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jan 2023 08:13:55 GMT
Subject: RFR: 8203035: Implement equals() and hashCode() for Throwable
In-Reply-To: <kUAymdlB4YL_BLTzTlvWvXjcGWRCEpe_hGU-2wr3NLo=.d53bc474-3c62-474f-a738-a5319aed1d68@github.com>
References: <kUAymdlB4YL_BLTzTlvWvXjcGWRCEpe_hGU-2wr3NLo=.d53bc474-3c62-474f-a738-a5319aed1d68@github.com>
Message-ID: <NsBjo7vHWbj8ugoUydHyFNFWDQbuQRfiymdcAcRdTik=.1a604da3-54c6-4906-8187-a52bf2451b91@github.com>

On Sat, 10 Dec 2022 18:11:30 GMT, Victor Toni <duke at openjdk.org> wrote:

> Being able to compare instances of Throwable allows simple detection of exceptions raised by the same circumstances. Comparison allows for reduction of excessive logging e.g. in hotspots without requiring custom code to compare Throwables.

@ViToni  I don't know if you have JBS access but can you read through the comments JDK-8203035 to see the concerns with this proposal?

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

PR: https://git.openjdk.org/jdk/pull/11624

From pminborg at openjdk.org  Tue Jan 10 08:17:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 08:17:51 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <TbTkkR4IXRDbbe9RizXGFFvwMqKgCzxVkuqmWnM5nKY=.174c860e-1fb3-40e6-9ad4-bb99afaccecf@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <TbTkkR4IXRDbbe9RizXGFFvwMqKgCzxVkuqmWnM5nKY=.174c860e-1fb3-40e6-9ad4-bb99afaccecf@github.com>
Message-ID: <YPCn80hgdUlJ3KmGdfibAGg4hRxgJ9KjI-kM3DK6lcU=.0030cb51-ac96-41b8-98dc-28688b652e0a@github.com>

On Mon, 9 Jan 2023 18:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> On the note of `CHM::isEmpty`: It would be better to rewrite this method as a short-circuitable reduction of the many CounterCells' values. As soon as at least one of them are >0 then the map is not empty. In contrast, today we sum all of the values, in many cases, unnecessary.

Well, turns out this is harder than said and the original solution is not that bad after all.

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

PR: https://git.openjdk.org/jdk/pull/11847

From alanb at openjdk.org  Tue Jan 10 08:56:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jan 2023 08:56:52 GMT
Subject: RFR: 8299835: (jrtfs) Unnecessary null check in
 JrtPath.getAttributes
In-Reply-To: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
References: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
Message-ID: <2-_peaTX0e7G_vnUs_sozA2kt2ZomUJ40VkqmfqGrYw=.440a9f72-de32-4bd8-9f60-01408ada680d@github.com>

On Mon, 9 Jan 2023 20:55:14 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `jdk.internal.jrtfs.JrtFileSystem#getFileAttributes` never return `null`
> 
> https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L206-L213
> So, no need to check for `null` its result.
> Seems it was copied from ZipPath (name of variable suggests that) - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L769. But for ZipFileSystem `null` is expected.

This looks okay as the 2-arg getFileAttrbutes will throw if the entry doesn't exist in the file system. I assume you'll update the end copyright year to 2023 before you integrate this.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11911

From aturbanov at openjdk.org  Tue Jan 10 09:14:11 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 10 Jan 2023 09:14:11 GMT
Subject: RFR: 8299835: (jrtfs) Unnecessary null check in
 JrtPath.getAttributes [v2]
In-Reply-To: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
References: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
Message-ID: <Vqogv9CS_iB8J6QOC0jrUaC8IaJ7oH9qvU82inWFLvw=.0afd7da9-2248-44bc-a024-5ac5f77bf773@github.com>

> `jdk.internal.jrtfs.JrtFileSystem#getFileAttributes` never return `null`
> 
> https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L206-L213
> So, no need to check for `null` its result.
> Seems it was copied from ZipPath (name of variable suggests that) - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L769. But for ZipFileSystem `null` is expected.

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

  8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes
  
  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11911/files
  - new: https://git.openjdk.org/jdk/pull/11911/files/6237726d..74068b94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11911&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11911&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11911

From turbanoff at gmail.com  Tue Jan 10 09:35:04 2023
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 10 Jan 2023 12:35:04 +0300
Subject: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE
Message-ID: <CAF+DQ5f=O9zQmc70TJNv3kNbO=L+f5jgTgpY1N1T02WiQqEQVA@mail.gmail.com>

Hello.
I've noticed that ZipFileStore#supportsFileAttributeView(String)
doesn't throw NullPointerException when 'null' is passed as an
argument.

public boolean supportsFileAttributeView(String name) {
    return "basic".equals(name) || "zip".equals(name) ||
           (("owner".equals(name) || "posix".equals(name)) && zfs.supportPosix);
}

Method body was changed to not throw NPE in JDK-8213031.
I wonder if it was an intentional change or not?


My reproducer shows difference between ZipFileStore and WindowsFileStore

public static void main(String[] args) throws IOException {
    checkFsForNull(FileSystems.newFileSystem(Path.of("D:\\config.zip")));
    checkFsForNull(FileSystems.getDefault());
}

private static void checkFsForNull(FileSystem fs) {
    fs.getFileStores().iterator().next().supportsFileAttributeView((String)null);
}



Andrey Turbanov

From david at dev-core.org  Tue Jan 10 09:59:02 2023
From: david at dev-core.org (David Schumann)
Date: Tue, 10 Jan 2023 10:59:02 +0100
Subject: jpackageapplauncher linker arguments for osx
In-Reply-To: <70f0b82a-ff2c-9e18-e447-0df51becc110@oracle.com>
References: <CAMrs=afcH+CUhY62dO=VeO7A3R++eMusdSESg9qPSMbJpSUx+g@mail.gmail.com>
 <7ab61fe5-9073-84db-d2d3-e9e4682b366f@oracle.com>
 <70f0b82a-ff2c-9e18-e447-0df51becc110@oracle.com>
Message-ID: <CAMrs=act-s253_xKU3MjrpYLVRw6AGzzcQBhr1bexwiU7QGU8w@mail.gmail.com>

Hi Alexey,

great! I've created the PR: https://github.com/openjdk/jdk/pull/11922

Best regards,
David Schumann



Am Mo., 9. Jan. 2023 um 23:57 Uhr schrieb Alexey Semenyuk <
alexey.semenyuk at oracle.com>:

> Hi David,
>
> The request to adjust osx linker command lines looks reasonable. Please
> go ahead with a pull request.
>
> - Alexey
>
> On 1/9/2023 1:21 AM, David Holmes wrote:
> > On 8/01/2023 8:39 pm, David Schumann wrote:
> >> Hello,
> >>
> >> I'm not 100% sure if this list is the correct one for this topic,
> >> feel free to redirect me.
> >
> > core-libs-dev - cc'd
> >
> > Cheers,
> > David
> >
> >> Currently the jpackageapplauncher binary gets linked without the
> >> "-headerpad_max_install_names" argument on osx. This prevents a user
> >> from using the install_name_tool with the launcher binary.
> >> This means that it's currently not possible to include dylibs in the
> >> application bundle.
> >>
> >> To provide a bit more context:
> >> I'm using jpackage to build an app bundle. The java application
> >> itself uses external native libraries, which internally use dlopen to
> >> reference other libs. Normaly one would include the other libs in the
> >> app bundle, and use the install_name_tool to tell the dynamic linker
> >> which paths to load the libraries from. However since the launcher
> >> binary doesn't get linked with the correct arguments, this isn't
> >> possible.
> >>
> >> I wanted to discuss this change, and it it makes sense for me to open
> >> a pull request for it.
> >> The change would be in
> >>
> https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76
> >> <
> https://github.com/openjdk/jdk/blob/master/make/modules/jdk.jpackage/Lib.gmk#L76>
>
> >>
> >>
> >> Best Regards,
> >> David Schumann
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230110/63a5fd54/attachment-0001.htm>

From Alan.Bateman at oracle.com  Tue Jan 10 10:23:52 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Jan 2023 10:23:52 +0000
Subject: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE
In-Reply-To: <CAF+DQ5f=O9zQmc70TJNv3kNbO=L+f5jgTgpY1N1T02WiQqEQVA@mail.gmail.com>
References: <CAF+DQ5f=O9zQmc70TJNv3kNbO=L+f5jgTgpY1N1T02WiQqEQVA@mail.gmail.com>
Message-ID: <1494baf2-10c9-de9b-65c7-e40e47a9404d@oracle.com>



On 10/01/2023 09:35, Andrey Turbanov wrote:
> Hello.
> I've noticed that ZipFileStore#supportsFileAttributeView(String)
> doesn't throw NullPointerException when 'null' is passed as an
> argument.
>
> public boolean supportsFileAttributeView(String name) {
>      return "basic".equals(name) || "zip".equals(name) ||
>             (("owner".equals(name) || "posix".equals(name)) && zfs.supportPosix);
> }
>
> Method body was changed to not throw NPE in JDK-8213031.
> I wonder if it was an intentional change or not?
The review of that feature went through many iterations over 8 months 
and this was missed, so maybe a short coming in the zipfs tests. Can you 
create a bug for this?

-Alan.

From pminborg at openjdk.org  Tue Jan 10 10:40:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 10:40:57 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
Message-ID: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>

`java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 

* Add `@Serial` annotations 
* Seal classes and restrict subclassing for internal classes 
* Use pattern matching for instance 
* Remove redundant modifiers (such as some final declarations) 
* Use Objects.requireNonNull for invariant checking 
* Use diamond operators instead of explicit types 
* Simplify expressions using Math::max

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

Commit messages:
 - Untrack file
 - Modernize ConcurrentHashMap

Changes: https://git.openjdk.org/jdk/pull/11924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299852
  Stats: 385 lines in 1 file changed: 14 ins; 22 del; 349 mod
  Patch: https://git.openjdk.org/jdk/pull/11924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11924/head:pull/11924

PR: https://git.openjdk.org/jdk/pull/11924

From prappo at openjdk.org  Tue Jan 10 12:06:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Jan 2023 12:06:53 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <ItIUkpAnlosYy6UfShKQ5XX7vqdPFtNjjFeu7k19Ev0=.f48ffbdb-6be9-4d8d-ba54-c45b34492fe6@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

I'm sure others will note or have already noted elsewhere that we don't do direct PRs against JSR 166.

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

PR: https://git.openjdk.org/jdk/pull/11924

From lancea at openjdk.org  Tue Jan 10 12:08:52 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Jan 2023 12:08:52 GMT
Subject: RFR: 8299835: (jrtfs) Unnecessary null check in
 JrtPath.getAttributes [v2]
In-Reply-To: <Vqogv9CS_iB8J6QOC0jrUaC8IaJ7oH9qvU82inWFLvw=.0afd7da9-2248-44bc-a024-5ac5f77bf773@github.com>
References: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
 <Vqogv9CS_iB8J6QOC0jrUaC8IaJ7oH9qvU82inWFLvw=.0afd7da9-2248-44bc-a024-5ac5f77bf773@github.com>
Message-ID: <gkVUCQ6XZ-sB1CabC4tL17dHbNx7azsQK5HmkcvEpIY=.95d9c6c8-8c80-4d4d-9d09-e33ebc6687b7@github.com>

On Tue, 10 Jan 2023 09:14:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> `jdk.internal.jrtfs.JrtFileSystem#getFileAttributes` never return `null`
>> 
>> https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L206-L213
>> So, no need to check for `null` its result.
>> Seems it was copied from ZipPath (name of variable suggests that) - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L769. But for ZipFileSystem `null` is expected.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes
>   
>   update copyright year

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11911

From turbanoff at gmail.com  Tue Jan 10 12:27:23 2023
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 10 Jan 2023 15:27:23 +0300
Subject: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE
In-Reply-To: <1494baf2-10c9-de9b-65c7-e40e47a9404d@oracle.com>
References: <CAF+DQ5f=O9zQmc70TJNv3kNbO=L+f5jgTgpY1N1T02WiQqEQVA@mail.gmail.com>
 <1494baf2-10c9-de9b-65c7-e40e47a9404d@oracle.com>
Message-ID: <CAF+DQ5f15jRD6KGGxRRg6M5VX=qbs2D0p+q-OSH6iUYAF=X7ug@mail.gmail.com>

Filled https://bugs.openjdk.org/browse/JDK-8299864

Andrey Turbanov

??, 10 ???. 2023 ?. ? 13:24, Alan Bateman <Alan.Bateman at oracle.com>:
>
>
>
> On 10/01/2023 09:35, Andrey Turbanov wrote:
> > Hello.
> > I've noticed that ZipFileStore#supportsFileAttributeView(String)
> > doesn't throw NullPointerException when 'null' is passed as an
> > argument.
> >
> > public boolean supportsFileAttributeView(String name) {
> >      return "basic".equals(name) || "zip".equals(name) ||
> >             (("owner".equals(name) || "posix".equals(name)) && zfs.supportPosix);
> > }
> >
> > Method body was changed to not throw NPE in JDK-8213031.
> > I wonder if it was an intentional change or not?
> The review of that feature went through many iterations over 8 months
> and this was missed, so maybe a short coming in the zipfs tests. Can you
> create a bug for this?
>
> -Alan.

From pminborg at openjdk.org  Tue Jan 10 13:34:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 13:34:49 GMT
Subject: RFR: 8299513: Cleanup java.io [v5]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <RQwMshI2yqBZbCRb5SVXVjAl3AlAbam4BFvOXPHHdCg=.50e35ad9-936c-4489-b707-98dc87ebe8a0@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Revert removal of a final keyword

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/a0e80355..78803a1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Tue Jan 10 13:36:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 13:36:53 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <ItIUkpAnlosYy6UfShKQ5XX7vqdPFtNjjFeu7k19Ev0=.f48ffbdb-6be9-4d8d-ba54-c45b34492fe6@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
 <ItIUkpAnlosYy6UfShKQ5XX7vqdPFtNjjFeu7k19Ev0=.f48ffbdb-6be9-4d8d-ba54-c45b34492fe6@github.com>
Message-ID: <9XR0NaeHsjdxCA4jVjwSsB23BUzYAv8B1IdjyGrGJLU=.74546917-1e1e-4774-bf5b-263e5b5bd5c1@github.com>

On Tue, 10 Jan 2023 12:04:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I'm sure others will note or have already noted elsewhere that we don't do direct PRs against JSR 166.

Yes. I will change the PR to a draft as we explore ways to integrate the spirit of the proposed changes.

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

PR: https://git.openjdk.org/jdk/pull/11924

From fjiang at openjdk.org  Tue Jan 10 13:46:34 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 10 Jan 2023 13:46:34 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v4]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <lBJfYwtDY0mvwBv67Ip0QNHimWjd38gWXtjG4Pe3XnQ=.d007810c-1a2f-45d2-92e1-992cdf8cdf06@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build
> - [x] run TestMatrix.java manually with release/fastdebug build

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

  fix callArranger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/289b8697..fd312661

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=02-03

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From mcimadamore at openjdk.org  Tue Jan 10 14:12:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 14:12:06 GMT
Subject: [jdk20] RFR: 8299862: OfAddress setter should disallow heap segments
Message-ID: <OJWkAs9idLUyIbnPPaRK74Xhahzcgf94ojYLzaerx_I=.351c7567-a1b9-4aa9-8b0e-58c6fc1b7898@github.com>

When unifying memory address with memory segments, we missed the case where a heap memory segment is passed as a value to a var handle address setters.

The solution is to reuse the same check we use when validating segment downcall parameters also for segment memory writes.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk20/pull/92/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=92&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299862
  Stats: 27 lines in 5 files changed: 23 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/92/head:pull/92

PR: https://git.openjdk.org/jdk20/pull/92

From jvernee at openjdk.org  Tue Jan 10 14:25:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Jan 2023 14:25:04 GMT
Subject: [jdk20] RFR: 8299862: OfAddress setter should disallow heap
 segments
In-Reply-To: <OJWkAs9idLUyIbnPPaRK74Xhahzcgf94ojYLzaerx_I=.351c7567-a1b9-4aa9-8b0e-58c6fc1b7898@github.com>
References: <OJWkAs9idLUyIbnPPaRK74Xhahzcgf94ojYLzaerx_I=.351c7567-a1b9-4aa9-8b0e-58c6fc1b7898@github.com>
Message-ID: <IxyipgglvETH4eUf8fuR13CR2Q5aR4AMNU31urF9Iug=.f3f4fc90-5d30-4681-b075-827f87853c6b@github.com>

On Tue, 10 Jan 2023 14:04:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When unifying memory address with memory segments, we missed the case where a heap memory segment is passed as a value to a var handle address setters.
> 
> The solution is to reuse the same check we use when validating segment downcall parameters also for segment memory writes.

Thanks for fixing.

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/92

From rriggs at openjdk.org  Tue Jan 10 15:01:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 15:01:57 GMT
Subject: RFR: 8299513: Cleanup java.io [v5]
In-Reply-To: <RQwMshI2yqBZbCRb5SVXVjAl3AlAbam4BFvOXPHHdCg=.50e35ad9-936c-4489-b707-98dc87ebe8a0@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <RQwMshI2yqBZbCRb5SVXVjAl3AlAbam4BFvOXPHHdCg=.50e35ad9-936c-4489-b707-98dc87ebe8a0@github.com>
Message-ID: <81XszaEM2sgFpfCl7rfW5V1x35jgS9gnvOdPGaX4vvQ=.52e0d183-2190-484c-a4ee-4c6a6900b48e@github.com>

On Tue, 10 Jan 2023 13:34:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removal of a final keyword

src/java.base/share/classes/java/io/ObjectStreamConstants.java line 38:

> 36:      * Magic number that is written to the stream header.
> 37:      */
> 38:     short STREAM_MAGIC = (short)0xaced;

I'd prefer to retain the `static`, it is easier to read and not have to remember that this declaration is in an interface.

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

PR: https://git.openjdk.org/jdk/pull/11848

From fjiang at openjdk.org  Tue Jan 10 15:15:23 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 10 Jan 2023 15:15:23 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build
> - [x] run TestMatrix.java manually with release/fastdebug build

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

  fix callArranger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/fd312661..fee96ae8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From pminborg at openjdk.org  Tue Jan 10 15:33:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 15:33:47 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't
 throw NPE
Message-ID: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>

This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

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

Commit messages:
 - Check null invariants

Changes: https://git.openjdk.org/jdk/pull/11926/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299864
  Stats: 49 lines in 2 files changed: 26 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11926.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Tue Jan 10 15:55:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 15:55:59 GMT
Subject: RFR: 8299513: Cleanup java.io [v5]
In-Reply-To: <81XszaEM2sgFpfCl7rfW5V1x35jgS9gnvOdPGaX4vvQ=.52e0d183-2190-484c-a4ee-4c6a6900b48e@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <RQwMshI2yqBZbCRb5SVXVjAl3AlAbam4BFvOXPHHdCg=.50e35ad9-936c-4489-b707-98dc87ebe8a0@github.com>
 <81XszaEM2sgFpfCl7rfW5V1x35jgS9gnvOdPGaX4vvQ=.52e0d183-2190-484c-a4ee-4c6a6900b48e@github.com>
Message-ID: <xOT3PGaKzJBA8iLCsHm-OJ-nDYjjTz2WAzA0kAbW1RE=.910cfbc0-70d5-4a99-966c-7bb3a04eb733@github.com>

On Tue, 10 Jan 2023 14:59:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert removal of a final keyword
>
> src/java.base/share/classes/java/io/ObjectStreamConstants.java line 38:
> 
>> 36:      * Magic number that is written to the stream header.
>> 37:      */
>> 38:     short STREAM_MAGIC = (short)0xaced;
> 
> I'd prefer to retain the `static`, it is easier to read and not have to remember that this declaration is in an interface.

I think the class should not be an interface in the first place but this is hard to change now.

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Tue Jan 10 16:06:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Jan 2023 16:06:15 GMT
Subject: RFR: 8299513: Cleanup java.io [v6]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Revert removal of static modifier in OSC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/78803a1a..f231c16b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=04-05

  Stats: 32 lines in 1 file changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From naoto at openjdk.org  Tue Jan 10 16:58:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jan 2023 16:58:04 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <booD5DTZARyLMvJGOuYaHFUW3phrjF3-0XReKAozjBg=.74bc5713-175e-460d-8ff9-084996c0b4bf@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <booD5DTZARyLMvJGOuYaHFUW3phrjF3-0XReKAozjBg=.74bc5713-175e-460d-8ff9-084996c0b4bf@github.com>
Message-ID: <sPM3Grz6u4dk8NKcIEkcSBLkh3x7rrDikLLBLCQNh9c=.aeed302d-ed9c-46f1-8815-923ada304834@github.com>

On Tue, 10 Jan 2023 00:46:35 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.
>> 
>> This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Toggle first instance as a system property, revert rest

LGTM. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11915

From eirbjo at gmail.com  Tue Jan 10 17:00:21 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 10 Jan 2023 18:00:21 +0100
Subject: ZipFile.isSignatureRelated returns true for files in META-INF
 subdirectories
Message-ID: <CA+pBWhs9EpASb6JGpcy5x2H4ToRZoALkhv1oJFe0Sw4qExB6dA@mail.gmail.com>

Hi,

ZipFile.isSignatureRelated currently returns true for paths such as the
following:

META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA

While this path does start with "META-INF/" and ends with ".DSA", the file
does not live in the META-INF/ directory _directly_, but rather several
directories below.

This causes such .DSA files to be incorrectly (?) included in the
verification of META-INF/MANIFEST.MF in JarFile.initializeVerifier, which
then fails with:

Exception in thread "main" java.lang.SecurityException: Invalid signature
> file digest for Manifest main attributes
> at
> java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340)
> at
> java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282)
> at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327)
> at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
> at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760)
> at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058)
> at
> java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72)
> at
> java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)


A few questions:

1: Where Is the exact location of signature related files specified?

2: Is the current behaviour indeed incorrect?

3: Should ZipFile.isSignatureRelated be updated such that it only matches
signature related files which reside exactly in "META-INF/" ?

The context for this is that I'm making a fat jar Maven plugin which embeds
dependency jars by "unpacking" them into subdirectories of
META-INF/libraries/.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230110/8dd0c588/attachment.htm>

From mchung at openjdk.org  Tue Jan 10 17:08:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 10 Jan 2023 17:08:59 GMT
Subject: Integrated: 8299183: Invokers.checkExactType passes parameters to
 create WMTE in opposite order
In-Reply-To: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
References: <68ERvONXzd-5lr4Au21sLFN-etSesjFy8tHzLSTsil0=.ea75bf5c-9dc8-4fbe-83b0-b55bc30da2c6@github.com>
Message-ID: <3Jr1rx8n2STtF4IVeA9wIJr_MRCUPTiaDXtvZQN44Sk=.6aa027a3-40b9-4836-85be-6a456fd943bf@github.com>

On Thu, 5 Jan 2023 20:45:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.  Fix `Invokers.checkExactType` to call `newWrongMethodTypeException(actual, expected)` with parameters in right order.

This pull request has now been integrated.

Changeset: a86b6f6f
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a86b6f6fde11a1cb27f926c43d53585049fed5e4
Stats:     103 lines in 4 files changed: 85 ins; 1 del; 17 mod

8299183: Invokers.checkExactType passes parameters to create WMTE in opposite order

Reviewed-by: iris, jpai

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

PR: https://git.openjdk.org/jdk/pull/11870

From naoto at openjdk.org  Tue Jan 10 17:27:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jan 2023 17:27:08 GMT
Subject: RFR: 8299571: ZoneRulesProvider.registerProvider() can leave
 inconsistent state on failure
Message-ID: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>

Fixing the subject method to recover gracefully on a failed `ZoneRulesProvider` registration.

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

Commit messages:
 - Added a test
 - 8299571: ZoneRulesProvider.registerProvider() can leave inconsistent state on failure

Changes: https://git.openjdk.org/jdk/pull/11928/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299571
  Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11928.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11928/head:pull/11928

PR: https://git.openjdk.org/jdk/pull/11928

From lancea at openjdk.org  Tue Jan 10 17:34:57 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Jan 2023 17:34:57 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE
In-Reply-To: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
Message-ID: <uQsVMsEsbWprC315LIjuCuA20JcAB6ymsIIRAJCgo18=.92cf0733-a314-446a-8e2e-b368f54f5aaa@github.com>

On Tue, 10 Jan 2023 15:26:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

Thanks for taking this on Per.

I think we also need to add a test for getAttribute() and getFileStoreAttributeView() as I do not see  it being tested in test/jdk/jdk/nio/zipfs/ZipFSTester.java or test/jdk/jdk/nio/zipfs/Basic.java

A few more minor comments below:

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java line 43:

> 41:  * @author Xueming Shen, Rajendra Gutupalli, Jaya Hangal
> 42:  */
> 43: final class ZipFileStore extends FileStore {

This should be OK but might suggest adding a release note

test/jdk/jdk/nio/zipfs/ZipFSTester.java line 1086:

> 1084:     }
> 1085: 
> 1086:     static void test8299864(FileSystem fs)  {

Please add a comment explaining the test and change the method name as would prefer to have names that are a bit more descriptive than a bug number.

I realize some of the existing methods follow the same naming as you are proposing, but we are trying to avoid this and make the tests more descriptive going forward

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

PR: https://git.openjdk.org/jdk/pull/11926

From rriggs at openjdk.org  Tue Jan 10 17:35:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 17:35:53 GMT
Subject: RFR: 8299513: Clean up java.io [v6]
In-Reply-To: <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
Message-ID: <N9K0O7rxw3x1TvaKaq5x0lbDQbN6bEYkMAkbasypCbc=.84286db4-4ddc-4bf7-9102-1ed038bae502@github.com>

On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removal of static modifier in OSC

The `static` declarations should be restored in ObjectStreamConstants.

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

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11848

From rriggs at openjdk.org  Tue Jan 10 17:35:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 17:35:55 GMT
Subject: RFR: 8299513: Clean up java.io [v5]
In-Reply-To: <xOT3PGaKzJBA8iLCsHm-OJ-nDYjjTz2WAzA0kAbW1RE=.910cfbc0-70d5-4a99-966c-7bb3a04eb733@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <RQwMshI2yqBZbCRb5SVXVjAl3AlAbam4BFvOXPHHdCg=.50e35ad9-936c-4489-b707-98dc87ebe8a0@github.com>
 <81XszaEM2sgFpfCl7rfW5V1x35jgS9gnvOdPGaX4vvQ=.52e0d183-2190-484c-a4ee-4c6a6900b48e@github.com>
 <xOT3PGaKzJBA8iLCsHm-OJ-nDYjjTz2WAzA0kAbW1RE=.910cfbc0-70d5-4a99-966c-7bb3a04eb733@github.com>
Message-ID: <68vJ5kRdfWHye--JUWif3OA7nL3c6XmmKd5_quTEWJQ=.3e01103b-51ce-4c62-878c-db9095e319fb@github.com>

On Tue, 10 Jan 2023 15:52:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectStreamConstants.java line 38:
>> 
>>> 36:      * Magic number that is written to the stream header.
>>> 37:      */
>>> 38:     short STREAM_MAGIC = (short)0xaced;
>> 
>> I'd prefer to retain the `static`, it is easier to read and not have to remember that this declaration is in an interface.
>
> I think the class should not be an interface in the first place but this is hard to change now.

Just because the static is not required does NOT mean it should be omitted!.

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

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Tue Jan 10 17:54:54 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 17:54:54 GMT
Subject: RFR: 8299836: Make `user.timezone` system property searchable [v2]
In-Reply-To: <DWsJK1b4e57rqD8TRluqxHZg4Cu7o7E4KfmRGUUdy30=.364ec5c8-8f01-4b1b-90e5-965db5a42148@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
 <ht-dKzV43CB4PFc2Pch72zfPDpyow13J3z-BFa56mgU=.79757d4f-08f1-4e4f-94c9-eff711121712@github.com>
 <-CcRErvCFHvXsQx3fhUS9SW4leNiYANXNAd478K2Er8=.bcd8328b-0433-4527-ac2b-807118bc2f85@github.com>
 <plmoO5VXQVrZMq3uRid0jZw6YPK8nRK6FpWcCkGkHUc=.c6fa274f-504e-418a-b2d4-5be81392ce59@github.com>
 <DWsJK1b4e57rqD8TRluqxHZg4Cu7o7E4KfmRGUUdy30=.364ec5c8-8f01-4b1b-90e5-965db5a42148@github.com>
Message-ID: <lRTQ3sYzqXKV-Xi5Jqo7vHfmM0uAgJKKrMz91Lx4V80=.d344bfb7-3f08-4ac4-991f-4d0303b110d3@github.com>

On Tue, 10 Jan 2023 01:50:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Like Naoto notes, my understanding of it is that the `@systemProperty` should appear only once at the place where the semantics of that system property is being defined. This mail, which was sent when this tag was introduced, has more details https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056653.html.
>> 
>> I think using it here is fine, but you may want to check how it "reads" on the generated javadoc index page for system properties.
>
>> but you may want to check how it "reads" on the generated javadoc index page for system properties.
> 
> For clarity, I meant the page where you will see all the system properties - there's a "Index" on top of the javadoc API page https://docs.oracle.com/en/java/javase/19/docs/api/index.html which leads to a page which has a link to the "System Properties" page, which should lead to https://docs.oracle.com/en/java/javase/19/docs/api/system-properties.html

Hi Jai,

I read the article and have a better understanding of when _ at systemProperty_ should be used and the supporting features.

I wasn't aware such a [page](https://docs.oracle.com/en/java/javase/19/docs/api/system-properties.html) existed, I checked that _user.timezone_ was displayed and linked to _java.util.TimeZone.getDefault()_ properly.

Thanks for the help!

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

PR: https://git.openjdk.org/jdk/pull/11915

From duke at openjdk.org  Tue Jan 10 18:02:22 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 18:02:22 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
Message-ID: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>

> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
> 
> java.lang.ArrayStoreException
> java.lang.ClassCastException
> java.lang.Double.compare(double, double)
> java.lang.Float.compare(float, float)
> java.lang.Integer.getInteger(String, int)
> java.lang.Integer.valueOf(String)
> java.lang.Integer.valueOf(String, int)
> java.lang.Long.getLong(String, long)
> java.lang.Long.valueOf(String)
> java.lang.Long.valueOf(String, int)
> java.lang.Short.valueOf(String)
> java.lang.Short.valueOf(String, int) 
> 
> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

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

  Include Byte in changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11912/files
  - new: https://git.openjdk.org/jdk/pull/11912/files/fc79e191..eb88d193

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11912&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11912&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11912.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11912/head:pull/11912

PR: https://git.openjdk.org/jdk/pull/11912

From asemenyuk at openjdk.org  Tue Jan 10 18:05:57 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Jan 2023 18:05:57 GMT
Subject: Integrated: 8298735: Some tools/jpackage/windows/* tests fails with
 jtreg test timeout
In-Reply-To: <BoHagQ4Eyn_D7q_dSw8IZvfJExOV5aDfm_EhMvcMVi8=.80d4f01e-97ae-4571-bb65-bbba4f58ad90@github.com>
References: <BoHagQ4Eyn_D7q_dSw8IZvfJExOV5aDfm_EhMvcMVi8=.80d4f01e-97ae-4571-bb65-bbba4f58ad90@github.com>
Message-ID: <N1zn_k6-NRQSbd-7UzjzpQMaq59ysbSpvF5A3rsXe38=.09cf88f8-5149-4e03-bb5a-21a5790614ad@github.com>

On Mon, 9 Jan 2023 22:53:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Increase failed test timeouts.
> Simple tests got an x1.5 increase and parametrized tests got an x2 increase

This pull request has now been integrated.

Changeset: 3c99e786
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c99e786ab4f89448f8d2a6eaf532255a8a560bf
Stats:     10 lines in 10 files changed: 0 ins; 0 del; 10 mod

8298735: Some tools/jpackage/windows/* tests fails with jtreg test timeout

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/11914

From asemenyuk at openjdk.org  Tue Jan 10 18:06:59 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Jan 2023 18:06:59 GMT
Subject: Integrated: 8299278: tools/jpackage/share/AddLauncherTest.java#id1
 failed AddLauncherTest.bug8230933
In-Reply-To: <mYJaZI6qEi_uWlrL4JEljwlsUsjrDwZ__ESSCZfnHYg=.72f840bd-72fe-43af-a9ae-2d6d3e567d8b@github.com>
References: <mYJaZI6qEi_uWlrL4JEljwlsUsjrDwZ__ESSCZfnHYg=.72f840bd-72fe-43af-a9ae-2d6d3e567d8b@github.com>
Message-ID: <svYdwNotnxvEcuLohKAn_kHPAcwQ9vgsGB9WoV_zCTA=.8550fff3-94ff-4587-9144-5b72ad19f2f2@github.com>

On Thu, 5 Jan 2023 20:10:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933

This pull request has now been integrated.

Changeset: c595f965
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c595f965abcf0ea80ace87b8f2180feebbb8984e
Stats:     47 lines in 2 files changed: 41 ins; 0 del; 6 mod

8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/11868

From rriggs at openjdk.org  Tue Jan 10 18:10:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 18:10:55 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <fC4TnoKuQLbN01yBBW2pAFLRAT3iqhDkEeRck6pGUQo=.d15cedaa-44cc-4e07-8135-9245b8b50ec4@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

Given that type conversions create the primitive wrapper instances when they are needed, I think the examples should be reconsidered. They needlessly suggest that the wrapper instances need to be explicitly created.

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

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11912

From serb at openjdk.org  Tue Jan 10 18:36:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 10 Jan 2023 18:36:56 GMT
Subject: RFR: 8299513: Clean up java.io [v6]
In-Reply-To: <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
Message-ID: <9RuOb9Seyy1p-ri1OdVdWnNB_0wOFvHIK2X8Qbu5CFs=.c97605e7-c5bf-4b78-98fb-3cbf3e8ae8ec@github.com>

On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removal of static modifier in OSC

Please do not type the "/integrate" when none of the reviewer approved the latest meaningful version

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

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Tue Jan 10 18:42:49 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 18:42:49 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <fC4TnoKuQLbN01yBBW2pAFLRAT3iqhDkEeRck6pGUQo=.d15cedaa-44cc-4e07-8135-9245b8b50ec4@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
 <fC4TnoKuQLbN01yBBW2pAFLRAT3iqhDkEeRck6pGUQo=.d15cedaa-44cc-4e07-8135-9245b8b50ec4@github.com>
Message-ID: <GnwoPNMGjqqJ3soZiAzTUV0DB3AuOq4xIQqGtLbLz7g=.892b04ad-126a-4288-9c33-21bbfbb8343e@github.com>

On Tue, 10 Jan 2023 18:07:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Given that type conversions create the primitive wrapper instances when they are needed, I think the examples should be reconsidered. They needlessly suggest that the wrapper instances need to be explicitly created.

Hi Roger, thanks for the comment,

When I was deciding between autoboxing and using the valueOf() methods, I personally saw the latter as providing more clarity from a documentation standpoint but I understand your concerns. Curious what others think on the decision of using one vs the other.

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

PR: https://git.openjdk.org/jdk/pull/11912

From mcimadamore at openjdk.org  Tue Jan 10 18:52:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 18:52:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
Message-ID: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>

On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect @bug numbers in unit tests.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:

> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
> 2344:             return false;
> 2345:         innerType = erasure(innerType);

The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:

> 83:  *
> 84:  * <p>
> 85:  * When tracking references, we distinguish between direct references and indirect references,

I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:

> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
> 1097:         this.visitScoped(tree, false, t -> {
> 1098:             while (true) {

Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?

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

PR: https://git.openjdk.org/jdk/pull/11874

From serb at openjdk.org  Tue Jan 10 19:12:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 10 Jan 2023 19:12:59 GMT
Subject: RFR: 8299513: Clean up java.io [v6]
In-Reply-To: <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
Message-ID: <ENRVKBcPCTc6h9l6j2aaPhBs_pKibtmYbvbvOOH1omU=.116210f9-895d-473a-89cf-850117b1f2c5@github.com>

On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removal of static modifier in OSC

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Tue Jan 10 19:22:58 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 19:22:58 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
Message-ID: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>

On Mon, 9 Jan 2023 15:03:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect @bug numbers in unit tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:
> 
>> 83:  *
>> 84:  * <p>
>> 85:  * When tracking references, we distinguish between direct references and indirect references,
> 
> I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?

It's slightly different from that.

Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.

This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.

Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).

You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.

Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:
> 
>> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>> 1097:         this.visitScoped(tree, false, t -> {
>> 1098:             while (true) {
> 
> Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?

Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.

The `ThisEscapeLoop.java` unit test demonstrates:

public class ThisEscapeLoop { 
    
    public ThisEscapeLoop() { 
        ThisEscapeLoop ref1 = this;
        ThisEscapeLoop ref2 = null;
        ThisEscapeLoop ref3 = null;
        ThisEscapeLoop ref4 = null;
        for (int i = 0; i < 100; i++) {
            ref4 = ref3;
            ref3 = ref2;
            ref2 = ref1;
            if (ref4 != null)
                ref4.mightLeak();
        }
    }

    public void mightLeak() {
    }
}

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Tue Jan 10 19:44:56 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 19:44:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
Message-ID: <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>

On Mon, 9 Jan 2023 14:23:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect @bug numbers in unit tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:
> 
>> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
>> 2344:             return false;
>> 2345:         innerType = erasure(innerType);
> 
> The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).

OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.

Just to confirm, you are saying that this:

`if (erasure(type).equalsIgnoreMetadata(outerType)) {`

should be replaced with this?

`if (isSameType(type, outerType)) {`

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

PR: https://git.openjdk.org/jdk/pull/11874

From rriggs at openjdk.org  Tue Jan 10 20:02:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 20:02:56 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <iLiDUnvvn4HrM835XGDEQhdNITamSJYc9a5NqlOLtQ8=.0e35084b-3286-413a-a087-534dd7a3296f@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

I see your point about clarity; these snippets are not usage examples, but are showing how the method could be implemented. I'd lean toward the auto-boxing technique to keep the example to a minimum.

Since you are updating the example, perhaps they should use `@snippet lang="java" { .... }` instead of the @code and blockquote markup.

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

PR: https://git.openjdk.org/jdk/pull/11912

From darcy at openjdk.org  Tue Jan 10 20:07:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Jan 2023 20:07:52 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <GnwoPNMGjqqJ3soZiAzTUV0DB3AuOq4xIQqGtLbLz7g=.892b04ad-126a-4288-9c33-21bbfbb8343e@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
 <fC4TnoKuQLbN01yBBW2pAFLRAT3iqhDkEeRck6pGUQo=.d15cedaa-44cc-4e07-8135-9245b8b50ec4@github.com>
 <GnwoPNMGjqqJ3soZiAzTUV0DB3AuOq4xIQqGtLbLz7g=.892b04ad-126a-4288-9c33-21bbfbb8343e@github.com>
Message-ID: <tHk03QDzdehH44KSclCXGrJRhIhNtxD2CBwPWWfCYmU=.2b670ef6-cc80-4fab-8dba-6f0c02846649@github.com>

On Tue, 10 Jan 2023 18:40:28 GMT, Justin Lu <duke at openjdk.org> wrote:

> > Given that type conversions create the primitive wrapper instances when they are needed, I think the examples should be reconsidered. They needlessly suggest that the wrapper instances need to be explicitly created.
> 
> Hi Roger, thanks for the comment,
> 
> When I was deciding between autoboxing and using the valueOf() methods, I personally saw the latter as providing more clarity from a documentation standpoint but I understand your concerns. Curious what others think on the decision of using one vs the other.

I concur that it is clearer to readers to have the explicit valueOf call in the code examples.

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

PR: https://git.openjdk.org/jdk/pull/11912

From duke at openjdk.org  Tue Jan 10 20:22:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 10 Jan 2023 20:22:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v6]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <-cVR0e9azbb3U9vWObNm1dBbUGIDuI7T6bAOpuPSG8I=.a55f2d47-00ae-471c-a51c-df638c104487@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add this-escape to the Javadoc list of strings supported by @SuppressWarnings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/7e2fdb07..d70d12f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11874

From mchung at openjdk.org  Tue Jan 10 20:26:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 10 Jan 2023 20:26:57 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <zZ1XvHNM8H1S5qSEmjnDaUkbASvLUoVcDFDyGBQpuj0=.46eecf3c-1247-45f3-8bee-15d049058e86@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

The code is used to show for example `getInteger(String nm, int val)` is equivalent to calling `getInteger(nm, Integer.valueOf(val))`.   I agree with Justin that it's clearer to use the `valueOf` methods.   In fact, `getInteger(String nam, int val)` example can't be represented with autoboxing.

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

PR: https://git.openjdk.org/jdk/pull/11912

From rriggs at openjdk.org  Tue Jan 10 20:32:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 20:32:54 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <yOvGs_A_AGHfKReIS-bUyWX7HWZeZpaMH3TYvK3GDfo=.d8883e70-0bf6-42ac-ae2d-1120ca414a15@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11912

From mchung at openjdk.org  Tue Jan 10 20:53:23 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 10 Jan 2023 20:53:23 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <qRee_BFWSm-ZvS-c7YRTs89AY_4XswThObJRRnBtESU=.aa9018c4-bb10-44af-a293-a45c347fa6c3@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11912

From lancea at openjdk.org  Tue Jan 10 20:58:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 10 Jan 2023 20:58:43 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
Message-ID: <OMevOsyWggxC82KCRfr8LBWf-nmpvPDbWY9Po73tZMo=.3d92f60a-de25-4c92-a4de-cbdece944071@github.com>

On Tue, 10 Jan 2023 18:02:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
>> 
>> java.lang.ArrayStoreException
>> java.lang.ClassCastException
>> java.lang.Double.compare(double, double)
>> java.lang.Float.compare(float, float)
>> java.lang.Integer.getInteger(String, int)
>> java.lang.Integer.valueOf(String)
>> java.lang.Integer.valueOf(String, int)
>> java.lang.Long.getLong(String, long)
>> java.lang.Long.valueOf(String)
>> java.lang.Long.valueOf(String, int)
>> java.lang.Short.valueOf(String)
>> java.lang.Short.valueOf(String, int) 
>> 
>> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include Byte in changes

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11912

From iris at openjdk.org  Tue Jan 10 21:34:19 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 10 Jan 2023 21:34:19 GMT
Subject: RFR: 8299571: ZoneRulesProvider.registerProvider() can leave
 inconsistent state on failure
In-Reply-To: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
References: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
Message-ID: <Mjv5SygCmNLYNJGC20W5szl2IwdAvOTazv7G4qN-DEQ=.97a725ef-93b3-4351-854a-6f0ed73eeea3@github.com>

On Tue, 10 Jan 2023 17:17:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the subject method to recover gracefully on a failed `ZoneRulesProvider` registration.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11928

From rriggs at openjdk.org  Tue Jan 10 22:00:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Jan 2023 22:00:15 GMT
Subject: RFR: 8299571: ZoneRulesProvider.registerProvider() can leave
 inconsistent state on failure
In-Reply-To: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
References: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
Message-ID: <FLeUJ719V0sciruYfr-7EYmicF8NFx6cnMhGbS_-Ha0=.2688c579-e0dc-4e16-ad4d-176c1f571682@github.com>

On Tue, 10 Jan 2023 17:17:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the subject method to recover gracefully on a failed `ZoneRulesProvider` registration.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11928

From martin at openjdk.org  Tue Jan 10 22:20:16 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 10 Jan 2023 22:20:16 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <DF2gsa5p5bOcLcKZBNDWVvSWEru8Azyo4TiPpAUoS9s=.a8c764f5-2369-48f0-871f-a7849275b2f6@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

ObMention @DougLea

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

PR: https://git.openjdk.org/jdk/pull/11924

From duke at openjdk.org  Tue Jan 10 22:31:12 2023
From: duke at openjdk.org (Justin Lu)
Date: Tue, 10 Jan 2023 22:31:12 GMT
Subject: RFR: 8299498: Usage of constructors of primitive wrapper classes
 should be avoided in java.lang API docs [v2]
In-Reply-To: <iLiDUnvvn4HrM835XGDEQhdNITamSJYc9a5NqlOLtQ8=.0e35084b-3286-413a-a087-534dd7a3296f@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
 <6YjZ3O7S9Xdw87dzp8HjPo73fiqkpAcT6r6_XuTDX8A=.b906c65e-ddac-44de-8549-9baa975cdc45@github.com>
 <iLiDUnvvn4HrM835XGDEQhdNITamSJYc9a5NqlOLtQ8=.0e35084b-3286-413a-a087-534dd7a3296f@github.com>
Message-ID: <3oEJNii_bdySIivREr_6sxZCznix2tT6GJFmyptHh8E=.4012283e-f94b-4e86-a742-a82b9e005d6a@github.com>

On Tue, 10 Jan 2023 19:59:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Since you are updating the example, perhaps they should use `@snippet lang="java" { .... }` instead of the @code and blockquote markup.

That's a good point and Lance brought that up as well, I will create a separate issue to address instances where that change can be made.

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

PR: https://git.openjdk.org/jdk/pull/11912

From martin at openjdk.org  Tue Jan 10 22:57:15 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 10 Jan 2023 22:57:15 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <04VCC41rg12eRj9281Vg0ks0HubI42rzmGC0b_uQPXg=.37a70599-dd97-42c1-8f95-199567a81bb2@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 104:

> 102:  * {@code size}, {@code isEmpty}, and {@code containsValue} are typically
> 103:  * useful only when a map is not undergoing concurrent updates in other threads.
> 104:  * Otherwise, the results of these methods reflect transient states

I agree the added comma here is an improvement.

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 357:

> 355:      * sometimes deviate significantly from uniform randomness.  This
> 356:      * includes the case when N > (1<<30), so some keys MUST collide.
> 357:      * Similarly, for dumb or hostile usages in which multiple keys are

"Similarly" should almost always be followed by a comma, but this is an exception.

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

PR: https://git.openjdk.org/jdk/pull/11924

From martin at openjdk.org  Tue Jan 10 23:03:15 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 10 Jan 2023 23:03:15 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <heqO343JqyrZ8aUExqN5wvpnnV7LAsXBvf9GkD4ZnVQ=.915b2892-9b98-4fb6-abd8-2571ca18b555@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 629:

> 627:      * exported).  Otherwise, keys and vals are never null.
> 628:      */
> 629:     static sealed class Node<K,V> implements Map.Entry<K,V> {

There is a long term modernization task of making nested classes private to make use of
https://openjdk.org/jeps/181
It looks like this is an example.

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

PR: https://git.openjdk.org/jdk/pull/11924

From joehw at openjdk.org  Tue Jan 10 23:05:13 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 10 Jan 2023 23:05:13 GMT
Subject: RFR: 8299571: ZoneRulesProvider.registerProvider() can leave
 inconsistent state on failure
In-Reply-To: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
References: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
Message-ID: <yquntFNBiZp26HkMPQfWsMGacegnQ0SWcBUv555CXXg=.2abdf2d1-66e5-4488-a6cd-8ad5f63efe0a@github.com>

On Tue, 10 Jan 2023 17:17:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the subject method to recover gracefully on a failed `ZoneRulesProvider` registration.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11928

From martin at openjdk.org  Tue Jan 10 23:10:15 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 10 Jan 2023 23:10:15 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <xSQejH58MUP9U3uM_vnzbyGdpZj6k8kQCHNxmU2SCWg=.2e5ad169-0771-44e5-9594-8443abae93c8@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 2002:

> 2000:         }
> 2001:         if (delta != 0)
> 2002:             addCount((long)delta, binCount);

Not sure why delta is not declared long as in clear().  But if not, then the explicit cast is documentation of the implementation choice to declare it int.

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

PR: https://git.openjdk.org/jdk/pull/11924

From mcimadamore at openjdk.org  Tue Jan 10 23:41:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 23:41:19 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
Message-ID: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>

On Tue, 10 Jan 2023 19:42:06 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345:
>> 
>>> 2343:         if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS))
>>> 2344:             return false;
>>> 2345:         innerType = erasure(innerType);
>> 
>> The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances).
>
> OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.
> 
> Just to confirm, you are saying that this:
> 
> `if (erasure(type).equalsIgnoreMetadata(outerType)) {`
> 
> should be replaced with this?
> 
> `if (isSameType(type, outerType)) {`

yes

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Tue Jan 10 23:49:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Jan 2023 23:49:12 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
Message-ID: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>

On Tue, 10 Jan 2023 19:18:04 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85:
>> 
>>> 83:  *
>>> 84:  * <p>
>>> 85:  * When tracking references, we distinguish between direct references and indirect references,
>> 
>> I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect?
>
> It's slightly different from that.
> 
> Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.
> 
> This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.
> 
> Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).
> 
> You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.
> 
> Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.

So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct?

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 00:07:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 00:07:14 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com>
Message-ID: <HODQOhvCyM19eFBP_7D9TSbUv6HqKnEA6JfEG13N5wk=.2562e5f0-8468-4f7a-a9f8-49e6183845b1@github.com>

On Tue, 10 Jan 2023 23:45:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> It's slightly different from that.
>> 
>> Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_.
>> 
>> This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared.
>> 
>> Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`).
>> 
>> You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`.
>> 
>> Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference.
>
> So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct?

Yes - although it's not tracked being tracked any more precisely than "one or more levels of indirection".

And of course by "reference" we only mean "the possibility of a reference" - in general we don't know for sure.

Here's the logic:
* The analysis knows `this` is a direct reference
* Therefore the array expression `{ this }` has an indirect reference (but no direct reference)
* The outer array expression `{ { this } }` therefore _also_ has an indirect reference (but no direct reference)

At this point, we don't know how many levels of indirection there are in `array` though.... only that its ? 1.

* There expression `array[0]` therefore is determined to have both direct and indirect references (they are both _possible_ because we've dereferenced something with an indirect reference)
* As does `array[0][0]` for the same reason

So invoking `array[0][0].hashCode()` means invoking `hashCode()` on something that has a possible direct reference, and is therefore a leak.

Note that because of the imprecision in the number of levels of indirection, invoking `array[0].hashCode()` would also have generated a warning - but in that case, a false positive.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Wed Jan 11 00:07:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 00:07:15 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
Message-ID: <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>

On Tue, 10 Jan 2023 19:20:35 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098:
>> 
>>> 1096:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>>> 1097:         this.visitScoped(tree, false, t -> {
>>> 1098:             while (true) {
>> 
>> Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code?
>
> Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.
> 
> The `ThisEscapeLoop.java` unit test demonstrates:
> 
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = ref3;
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public void mightLeak() {
>     }
> }

So, if the code was be like this:


ThisEscapeLoop ref11 = this;
ThisEscapeLoop ref12 = null;
ThisEscapeLoop ref13 = null;
ThisEscapeLoop ref14 = null;
for (int i = 0; i < 100; i++) {
    ref14 = ref13;
    ref13 = ref12;
    ref12 = ref11;
    ThisEscapeLoop ref21 = ref14;
    ThisEscapeLoop ref22 = null;
    ThisEscapeLoop ref23 = null;
    ThisEscapeLoop ref24 = null;
    for (int i = 0; i < 100; i++) {
        ref24 = ref23;
        ref23 = ref22;
        ref22 = ref21;
        if (ref24 != null)
            ref24.mightLeak();
    }
}


Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 00:25:10 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 00:25:10 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
Message-ID: <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>

On Wed, 11 Jan 2023 00:04:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies.
>> 
>> The `ThisEscapeLoop.java` unit test demonstrates:
>> 
>> public class ThisEscapeLoop { 
>>     
>>     public ThisEscapeLoop() { 
>>         ThisEscapeLoop ref1 = this;
>>         ThisEscapeLoop ref2 = null;
>>         ThisEscapeLoop ref3 = null;
>>         ThisEscapeLoop ref4 = null;
>>         for (int i = 0; i < 100; i++) {
>>             ref4 = ref3;
>>             ref3 = ref2;
>>             ref2 = ref1;
>>             if (ref4 != null)
>>                 ref4.mightLeak();
>>         }
>>     }
>> 
>>     public void mightLeak() {
>>     }
>> }
>
> So, if the code was be like this:
> 
> 
> ThisEscapeLoop ref11 = this;
> ThisEscapeLoop ref12 = null;
> ThisEscapeLoop ref13 = null;
> ThisEscapeLoop ref14 = null;
> for (int i = 0; i < 100; i++) {
>     ref14 = ref13;
>     ref13 = ref12;
>     ref12 = ref11;
>     ThisEscapeLoop ref21 = ref14;
>     ThisEscapeLoop ref22 = null;
>     ThisEscapeLoop ref23 = null;
>     ThisEscapeLoop ref24 = null;
>     for (int i = 0; i < 100; i++) {
>         ref24 = ref23;
>         ref23 = ref22;
>         ref22 = ref21;
>         if (ref24 != null)
>             ref24.mightLeak();
>     }
> }
> 
> 
> Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?

Actually I think it would take 1 + 1 + 3 iterations.

During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.

It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.

However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.

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

PR: https://git.openjdk.org/jdk/pull/11874

From jvernee at openjdk.org  Wed Jan 11 02:31:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 02:31:16 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well
Message-ID: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>

A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

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

Commit messages:
 - add parameter order clarification

Changes: https://git.openjdk.org/jdk20/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=95&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299090
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/95/head:pull/95

PR: https://git.openjdk.org/jdk20/pull/95

From duke at openjdk.org  Wed Jan 11 03:30:03 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 03:30:03 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Use the more appropriate Type comparison method Types.isSameType().
 - Add some more comments to clarify how the analysis works.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/d70d12f4..6e96a7d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=05-06

  Stats: 31 lines in 2 files changed: 16 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 03:30:05 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 03:30:05 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <oWX_ZhpcpYhGU0fVGA-R3I_p0yYPNkW6NKBT9c7FwoU=.3219ea09-6087-409f-a55e-3b1abdc3dc20@github.com>
 <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com>
Message-ID: <7jUSzUYT_eWYGbHkDes10f2-1i5DNdmDGDACe8qsXU4=.5bca0f1b-e004-48bc-87e0-48d6fb9deb96@github.com>

On Tue, 10 Jan 2023 23:38:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit.
>> 
>> Just to confirm, you are saying that this:
>> 
>> `if (erasure(type).equalsIgnoreMetadata(outerType)) {`
>> 
>> should be replaced with this?
>> 
>> `if (isSameType(type, outerType)) {`
>
> yes

Thanks... updated in `6e96a7d76f8`.

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

PR: https://git.openjdk.org/jdk/pull/11874

From aturbanov at openjdk.org  Wed Jan 11 07:11:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 07:11:14 GMT
Subject: RFR: 8299513: Clean up java.io [v6]
In-Reply-To: <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
Message-ID: <g8S7cDfDXKbPRHm6FNoRQVHPaijSUQ5nk9De7yMIIjc=.ba84618c-d8ea-4892-86e1-bdc8fa94c294@github.com>

On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removal of static modifier in OSC

src/java.base/share/classes/java/io/ObjectStreamConstants.java line 123:

> 121:      * new Proxy Class Descriptor.
> 122:      */
> 123:     static byte TC_PROXYCLASSDESC =       (byte)0x7D;

alignment is confusing here. As we touch every constant here I suggest to realign all values properly. (Or remove alignment attempt completely.)

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Wed Jan 11 08:35:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 08:35:00 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v2]
In-Reply-To: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
Message-ID: <E0JieJOC3pUhdvx3Luq1OO8B0czX9cEvReAc8MG74Pw=.fa468695-815d-412a-993f-b0fe668327b5@github.com>

> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

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

  Rename and improve NPE testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11926/files
  - new: https://git.openjdk.org/jdk/pull/11926/files/9e6e8e54..8c465592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=00-01

  Stats: 26 lines in 1 file changed: 17 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11926.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Wed Jan 11 08:35:02 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 08:35:02 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v2]
In-Reply-To: <uQsVMsEsbWprC315LIjuCuA20JcAB6ymsIIRAJCgo18=.92cf0733-a314-446a-8e2e-b368f54f5aaa@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
 <uQsVMsEsbWprC315LIjuCuA20JcAB6ymsIIRAJCgo18=.92cf0733-a314-446a-8e2e-b368f54f5aaa@github.com>
Message-ID: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com>

On Tue, 10 Jan 2023 17:29:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This should be OK but might suggest adding a release note

Do we need to do that for a package-private class? Maybe for internal use?

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

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Wed Jan 11 08:39:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 08:39:17 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v3]
In-Reply-To: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
Message-ID: <z5feRhzQnkjdRNUB7SJI1FkaA2zvk0wYHcp7OGeEwWo=.92d4493d-dd4c-4194-b287-fb75aaa7ca23@github.com>

> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

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

  Add test method comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11926/files
  - new: https://git.openjdk.org/jdk/pull/11926/files/8c465592..84813af1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=01-02

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11926.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Wed Jan 11 08:43:36 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 08:43:36 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v4]
In-Reply-To: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
Message-ID: <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com>

> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

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

  Fix typo and add bug ref

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11926/files
  - new: https://git.openjdk.org/jdk/pull/11926/files/84813af1..6003faae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11926&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11926.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11926/head:pull/11926

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Wed Jan 11 08:54:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 08:54:13 GMT
Subject: RFR: 8299513: Clean up java.io [v6]
In-Reply-To: <N9K0O7rxw3x1TvaKaq5x0lbDQbN6bEYkMAkbasypCbc=.84286db4-4ddc-4bf7-9102-1ed038bae502@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <Nx35QcLUR3dlw1QNPP0v6rS9SxAO7WHmue6swGc4Iwc=.f0fcc633-f66a-40fb-946a-a440262b6fdb@github.com>
 <N9K0O7rxw3x1TvaKaq5x0lbDQbN6bEYkMAkbasypCbc=.84286db4-4ddc-4bf7-9102-1ed038bae502@github.com>
Message-ID: <ht7jWzybBlCTSfjZgrb9FsZueDSe_cYH-78C_ngSFx0=.970d259a-df74-4b51-9d86-ddfaa9e1961f@github.com>

On Tue, 10 Jan 2023 17:33:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The `static` declarations should be restored in ObjectStreamConstants.

This has been fixed in [a previous commit](https://github.com/openjdk/jdk/pull/11848/commits/f231c16b9074c711ed6a417331a35a205516532a)

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

PR: https://git.openjdk.org/jdk/pull/11848

From alanb at openjdk.org  Wed Jan 11 09:02:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 09:02:16 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v4]
In-Reply-To: <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
 <uQsVMsEsbWprC315LIjuCuA20JcAB6ymsIIRAJCgo18=.92cf0733-a314-446a-8e2e-b368f54f5aaa@github.com>
 <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com>
Message-ID: <WlZxA4NZY7RaYiT3I1Zs7nZqU3K0rttJMeTwlfa-6bI=.2adb617b-a991-41e4-a919-5e5ea0598e80@github.com>

On Wed, 11 Jan 2023 08:30:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java line 43:
>> 
>>> 41:  * @author Xueming Shen, Rajendra Gutupalli, Jaya Hangal
>>> 42:  */
>>> 43: final class ZipFileStore extends FileStore {
>> 
>> This should be OK but might suggest adding a release note
>
>> This should be OK but might suggest adding a release note
> 
> Do we need to do that for a package-private class? Maybe for internal use?

This is a implementation class in a non-exported package so it's okay.

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

PR: https://git.openjdk.org/jdk/pull/11926

From pminborg at openjdk.org  Wed Jan 11 09:17:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 09:17:52 GMT
Subject: RFR: 8299513: Clean up java.io [v7]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

 - Update src/java.base/share/classes/java/io/ObjectStreamConstants.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Clean up ObjectStreamConstants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/f231c16b..33cdd8f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=05-06

  Stats: 22 lines in 3 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From aturbanov at openjdk.org  Wed Jan 11 09:17:52 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 09:17:52 GMT
Subject: RFR: 8299513: Clean up java.io [v7]
In-Reply-To: <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>
Message-ID: <RNg_-b-avPI1_dBKWsRumjIbg7VBMD8HlSO37pNfPD8=.8cff893f-87b9-4371-bf89-e5619c6b5291@github.com>

On Wed, 11 Jan 2023 09:13:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/io/ObjectStreamConstants.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Clean up ObjectStreamConstants

src/java.base/share/classes/java/io/ObjectStreamConstants.java line 108:

> 106:      * number of bytes in this block data.
> 107:      */
> 108:     static byte TC_BLOCKDATALONG= 0x7A;

Add space before `=`
Suggestion:

    static byte TC_BLOCKDATALONG = 0x7A;

src/java.base/share/classes/java/io/ObjectStreamConstants.java line 139:

> 137:      * First wire handle to be assigned.
> 138:      */
> 139:     static int BASE_WIRE_HANDLE = 0x7e0000;

Isn't it a part of public API? You shouldn't rename such things in cleanup PRs.

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectStreamConstants.html#baseWireHandle

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Wed Jan 11 09:22:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 09:22:24 GMT
Subject: RFR: 8299513: Clean up java.io [v8]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <EjvhhBjFiPnv29NdlRBEHMsq3rttIqHJirKtGqTf1mk=.c2a4f885-6bd6-45b1-bfed-5e9668a1025b@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Revert renaming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/33cdd8f1..5a4cb55e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=06-07

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From aturbanov at openjdk.org  Wed Jan 11 09:22:26 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 09:22:26 GMT
Subject: RFR: 8299513: Clean up java.io [v7]
In-Reply-To: <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>
Message-ID: <1a964oPsdZ8Chdyav5yoI3u-nH8Po7HG5XXjdQtjDm8=.540f4a45-ba0f-42db-826e-3216f05aff14@github.com>

On Wed, 11 Jan 2023 09:17:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/io/ObjectStreamConstants.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Clean up ObjectStreamConstants

Let's revert changes in public API

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

Changes requested by aturbanov (Committer).

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Wed Jan 11 09:22:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 09:22:29 GMT
Subject: RFR: 8299513: Clean up java.io [v7]
In-Reply-To: <RNg_-b-avPI1_dBKWsRumjIbg7VBMD8HlSO37pNfPD8=.8cff893f-87b9-4371-bf89-e5619c6b5291@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <rDgmdASpCtahbVU_nj7yXLiHkzB06Mgi6RLEffHlFFM=.1250bd04-4445-4954-bec4-7d9cea73df62@github.com>
 <RNg_-b-avPI1_dBKWsRumjIbg7VBMD8HlSO37pNfPD8=.8cff893f-87b9-4371-bf89-e5619c6b5291@github.com>
Message-ID: <E_X_ipLNX9jfd6WtLemZKjuyrAjNPMv6bqSHG3l-Mgw=.216534d9-7c08-43c5-ad79-223426023dbb@github.com>

On Wed, 11 Jan 2023 09:13:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/io/ObjectStreamConstants.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Clean up ObjectStreamConstants
>
> src/java.base/share/classes/java/io/ObjectStreamConstants.java line 139:
> 
>> 137:      * First wire handle to be assigned.
>> 138:      */
>> 139:     static int BASE_WIRE_HANDLE = 0x7e0000;
> 
> Isn't it a part of public API? You shouldn't rename such things in cleanup PRs.
> 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectStreamConstants.html#baseWireHandle

Oops. Thanks for spotting this. Fixed.

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

PR: https://git.openjdk.org/jdk/pull/11848

From clanger at openjdk.org  Wed Jan 11 09:33:06 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 11 Jan 2023 09:33:06 GMT
Subject: [jdk20] RFR: 8299439:
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
Message-ID: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>

Hi all,

This pull request contains a backport of [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 4 Jan 2023 and was reviewed by Naoto Sato, Lance Andersen and Jaikiran Pai.

Thanks!

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

Commit messages:
 - Backport 3b374c0153950ab193f3a188b57d3404b4ce2fe2

Changes: https://git.openjdk.org/jdk20/pull/96/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=96&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299439
  Stats: 8 lines in 3 files changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk20/pull/96.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/96/head:pull/96

PR: https://git.openjdk.org/jdk20/pull/96

From alanb at openjdk.org  Wed Jan 11 10:00:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 10:00:17 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <YTFDx3W-vSpm2vWvpxalmta-FRLbjwjlT62wZK4tpqo=.a5acb199-2bf4-452d-aa3f-47dcfe56580f@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

Would it be possible to provide some context on which public API you are testing with and the micro benchmark that you are using?

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

PR: https://git.openjdk.org/jdk/pull/11897

From mcimadamore at openjdk.org  Wed Jan 11 10:35:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 10:35:15 GMT
Subject: [jdk20] Integrated: 8299862: OfAddress setter should disallow heap
 segments
In-Reply-To: <OJWkAs9idLUyIbnPPaRK74Xhahzcgf94ojYLzaerx_I=.351c7567-a1b9-4aa9-8b0e-58c6fc1b7898@github.com>
References: <OJWkAs9idLUyIbnPPaRK74Xhahzcgf94ojYLzaerx_I=.351c7567-a1b9-4aa9-8b0e-58c6fc1b7898@github.com>
Message-ID: <sFTaYj7CIUbpSZu4vuTnpPpLoyhpWYcHLwNrtOVPKS8=.aa31ef4a-e082-4991-8e60-93b4c7a9a876@github.com>

On Tue, 10 Jan 2023 14:04:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When unifying memory address with memory segments, we missed the case where a heap memory segment is passed as a value to a var handle address setters.
> 
> The solution is to reuse the same check we use when validating segment downcall parameters also for segment memory writes.

This pull request has now been integrated.

Changeset: 945ef075
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/945ef07564bb2e7db9743d07d7d9ac7faa3f3d4d
Stats:     27 lines in 5 files changed: 23 ins; 0 del; 4 mod

8299862: OfAddress setter should disallow heap segments

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk20/pull/92

From aturbanov at openjdk.org  Wed Jan 11 10:40:17 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 10:40:17 GMT
Subject: RFR: 8299513: Clean up java.io [v8]
In-Reply-To: <EjvhhBjFiPnv29NdlRBEHMsq3rttIqHJirKtGqTf1mk=.c2a4f885-6bd6-45b1-bfed-5e9668a1025b@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <EjvhhBjFiPnv29NdlRBEHMsq3rttIqHJirKtGqTf1mk=.c2a4f885-6bd6-45b1-bfed-5e9668a1025b@github.com>
Message-ID: <bFe1iX2daV0aoIjNI6_BkTSHNlq_0cfpNszTmpxHhmk=.8a60c623-6973-4658-81d7-c5fa291b675c@github.com>

On Wed, 11 Jan 2023 09:22:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert renaming

src/java.base/share/classes/java/io/DataInputStream.java line 2:

> 1: /*
> 2:  * Copyright (c) 1994, 2023, Oracle and/or its affiliates. All rights reserved.

Only copyright year is updated in this file?

src/java.base/share/classes/java/io/ExpiringCache.java line 41:

> 39:     // Clear out old entries every few queries
> 40:     private int queryCount;
> 41:     private final int queryOverflow = 300;

can it be made `static` too?

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

PR: https://git.openjdk.org/jdk/pull/11848

From rgiulietti at openjdk.org  Wed Jan 11 10:55:00 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 10:55:00 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
Message-ID: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>

This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

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

Commit messages:
 - 8299677: Formatter.format might take a long time to format an integer or floating-point

Changes: https://git.openjdk.org/jdk/pull/11939/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299677
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11939.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11939/head:pull/11939

PR: https://git.openjdk.org/jdk/pull/11939

From alanb at openjdk.org  Wed Jan 11 11:57:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 11:57:14 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <XWeuFtHasOFu41shi9DYvFMVbbTquItYEl6LBTCGebk=.3f2a4334-28b1-4316-bde0-580564cf4547@github.com>

On Wed, 11 Jan 2023 10:47:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

I assume this issue has been there for a long time, just not noticed because it would be unusual to specify a width of this magnitude. The switch to using repeat + one insert looks good. Are you okay for tests in this area?

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

PR: https://git.openjdk.org/jdk/pull/11939

From pminborg at openjdk.org  Wed Jan 11 12:11:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 12:11:26 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well
In-Reply-To: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
Message-ID: <rp55y16Zw51fib86Ndn13F2Bj-mOvrCbXfiSEYMOZrs=.1f80b127-2214-441c-897f-cf1b9d2930a9@github.com>

On Wed, 11 Jan 2023 02:19:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

LGTM

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

Marked as reviewed by pminborg (Committer).

PR: https://git.openjdk.org/jdk20/pull/95

From redestad at openjdk.org  Wed Jan 11 12:19:21 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Jan 2023 12:19:21 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
Message-ID: <3XcxGKxGGuk9z2Zz5qx32DcWsv5edlNMISuEw0lVawE=.fdc71f3d-ddee-485b-b6b5-c56ef6380368@github.com>

On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly lea external address

I'll do another round of internal testing (tier1-4). Unless I hear any objections I plan to integrate this once all testing looks satisfactory.

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

PR: https://git.openjdk.org/jdk/pull/10847

From mcimadamore at openjdk.org  Wed Jan 11 12:36:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 12:36:25 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well
In-Reply-To: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
Message-ID: <4E283VhwsF-JdqzSc0eaQVaSVHoPr5ObLmaMthS_HqE=.92bb681a-f968-4fb9-ae11-168ae7e54f20@github.com>

On Wed, 11 Jan 2023 02:19:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

src/java.base/share/classes/java/lang/foreign/Linker.java line 328:

> 326:          * For this purpose, a downcall method handle linked with the {@link #captureCallState(String[])}
> 327:          * option will feature an additional {@link MemorySegment} parameter directly
> 328:          * following the target address parameter. This parameter represents the native segment

Should we also mention the allocator parameter which can occur if the function returns a struct by value?

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

PR: https://git.openjdk.org/jdk20/pull/95

From rgiulietti at openjdk.org  Wed Jan 11 12:48:12 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 12:48:12 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <XWeuFtHasOFu41shi9DYvFMVbbTquItYEl6LBTCGebk=.3f2a4334-28b1-4316-bde0-580564cf4547@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <XWeuFtHasOFu41shi9DYvFMVbbTquItYEl6LBTCGebk=.3f2a4334-28b1-4316-bde0-580564cf4547@github.com>
Message-ID: <8CjFyxeUQH4-ZzXeur5dwY514tnr-3Qy79pc4GqotZ0=.ba1ade73-85b1-4da7-8b93-5e88a8fb4075@github.com>

On Wed, 11 Jan 2023 11:53:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> I assume this issue has been there for a long time, just not noticed because it would be unusual to specify a width of this magnitude. The switch to using repeat + one insert looks good. Are you okay for tests in this area?

@AlanBateman This is not a functional bug, only an enhancement to overcome the long times for large, unrealistic widths.
Consequently, I have no specific tests that measure the timing against some hard-coded limits, if I understand you correctly.

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

PR: https://git.openjdk.org/jdk/pull/11939

From jlaskey at openjdk.org  Wed Jan 11 12:54:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 11 Jan 2023 12:54:12 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <UIt7A_4Z4QKgku8tksxSdoyRAIQEipRI3XBgWQ-6aQ0=.9ca04948-723e-43b7-9fa2-d13bad067c88@github.com>

On Wed, 11 Jan 2023 10:47:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

Just as a note, I've been thinking about adding a `repeat(String src, int count)` method to AbstractStringBuffer for quite some. I've held off because I would add a `fillWith(T[] dst, T[] src, int start, int end)` methods to `java.util.Arrays` first. I think both sets of methods would be generally useful based on use patterns in the JDK but for time and motivation.

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

PR: https://git.openjdk.org/jdk/pull/11939

From jvernee at openjdk.org  Wed Jan 11 12:56:20 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 12:56:20 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well
In-Reply-To: <4E283VhwsF-JdqzSc0eaQVaSVHoPr5ObLmaMthS_HqE=.92bb681a-f968-4fb9-ae11-168ae7e54f20@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
 <4E283VhwsF-JdqzSc0eaQVaSVHoPr5ObLmaMthS_HqE=.92bb681a-f968-4fb9-ae11-168ae7e54f20@github.com>
Message-ID: <Yy8B2i5eHsjie_18Zpq-F4AhABHvgU8vfmN2-uHdLbE=.48932bd2-332c-4e7b-a041-981b4d9a4693@github.com>

On Wed, 11 Jan 2023 12:33:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 328:
> 
>> 326:          * For this purpose, a downcall method handle linked with the {@link #captureCallState(String[])}
>> 327:          * option will feature an additional {@link MemorySegment} parameter directly
>> 328:          * following the target address parameter. This parameter represents the native segment
> 
> Should we also mention the allocator parameter which can occur if the function returns a struct by value?

Hmm yeah. The SegmentAllocator is also specified to be immediately after the address parameter, so it's unclear in which order they would be. I'll update this.

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

PR: https://git.openjdk.org/jdk20/pull/95

From duke at openjdk.org  Wed Jan 11 13:12:14 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 11 Jan 2023 13:12:14 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <YTFDx3W-vSpm2vWvpxalmta-FRLbjwjlT62wZK4tpqo=.a5acb199-2bf4-452d-aa3f-47dcfe56580f@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
 <YTFDx3W-vSpm2vWvpxalmta-FRLbjwjlT62wZK4tpqo=.a5acb199-2bf4-452d-aa3f-47dcfe56580f@github.com>
Message-ID: <Mhf8SKJvGTclkxTQbUu651sWZ5NwWH9x9PYoe6fwFgM=.3509f1a8-77e3-46db-aea2-63e50f4343c7@github.com>

On Wed, 11 Jan 2023 09:56:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
>> 
>> I ran the tier1 test without any new errors.
>
> Would it be possible to provide some context on which public API you are testing with and the micro benchmark that you are using?

@AlanBateman 

This PR mainly affects `Files.readString` and `java.util.zip.ZipCoder`.

I designed a micro benchmark for `Files.readString`: [NoRepl.java](https://gist.github.com/Glavo/0aa47d47f329ceabf7dd4c3b9d2848e2).

This benchmark tests the performance of `Files.readString`. To avoid interference, the test is based on the memory file system.

This is the baseline:


Benchmark                                (length)  Mode  Cnt         Score        Error  Units
NoRepl.testReadAscii                            0  avgt    5       192.584 ?      1.670  ns/op
NoRepl.testReadAscii                         1024  avgt    5       296.760 ?      2.599  ns/op
NoRepl.testReadAscii                         8192  avgt    5       427.220 ?      0.809  ns/op
NoRepl.testReadAscii                      1048576  avgt    5     29082.579 ?     34.780  ns/op
NoRepl.testReadAscii                     33554432  avgt    5   1168901.308 ? 240228.024  ns/op
NoRepl.testReadUTF8                             0  avgt    5       206.196 ?      2.296  ns/op
NoRepl.testReadUTF8                          1024  avgt    5      1290.403 ?      3.920  ns/op
NoRepl.testReadUTF8                          8192  avgt    5      9371.318 ?     55.165  ns/op
NoRepl.testReadUTF8                       1048576  avgt    5   1203194.297 ?   5787.171  ns/op
NoRepl.testReadUTF8                      33554432  avgt    5  44567374.591 ? 170568.947  ns/op


This is the result based on this PR:


Benchmark                                (length)  Mode  Cnt         Score        Error  Units
NoRepl.testReadAscii                            0  avgt    5       210.050 ?     22.174  ns/op
NoRepl.testReadAscii                         1024  avgt    5       285.811 ?      4.448  ns/op
NoRepl.testReadAscii                         8192  avgt    5       350.318 ?      0.504  ns/op
NoRepl.testReadAscii                      1048576  avgt    5     19565.571 ?     33.153  ns/op
NoRepl.testReadAscii                     33554432  avgt    5    857566.083 ?  18352.548  ns/op
NoRepl.testReadUTF8                             0  avgt    5       196.632 ?      0.633  ns/op
NoRepl.testReadUTF8                          1024  avgt    5      1295.354 ?      4.450  ns/op
NoRepl.testReadUTF8                          8192  avgt    5      9381.675 ?    127.045  ns/op
NoRepl.testReadUTF8                       1048576  avgt    5   1200648.741 ?   4259.763  ns/op
NoRepl.testReadUTF8                      33554432  avgt    5  44481499.656 ? 284353.880  ns/op


This PR has very slight performance degradation (about 0.1%, almost negligible) when reading files containing non-ASCII characters.

For large ASCII files, the performance is improved by 30%~50%.

Although such a significant performance improvement on the memory file system cannot be achieved on the hard disk file system, this PR can still reduce one copy of the array and temporary memory allocation for ASCII files.

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

PR: https://git.openjdk.org/jdk/pull/11897

From jvernee at openjdk.org  Wed Jan 11 13:17:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 13:17:53 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v2]
In-Reply-To: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
Message-ID: <7mx3APvsfoJxsVdFI4NdbSeMnTS5bX8KCTC1wucgEjw=.0fda56a2-6794-4cb8-a31a-2d7d5c171599@github.com>

> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

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

  Mention SegmentAllocator parameter as well

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/95/files
  - new: https://git.openjdk.org/jdk20/pull/95/files/275d0cc1..ab53c5a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=95&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=95&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/95/head:pull/95

PR: https://git.openjdk.org/jdk20/pull/95

From jvernee at openjdk.org  Wed Jan 11 13:17:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 13:17:56 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v2]
In-Reply-To: <Yy8B2i5eHsjie_18Zpq-F4AhABHvgU8vfmN2-uHdLbE=.48932bd2-332c-4e7b-a041-981b4d9a4693@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
 <4E283VhwsF-JdqzSc0eaQVaSVHoPr5ObLmaMthS_HqE=.92bb681a-f968-4fb9-ae11-168ae7e54f20@github.com>
 <Yy8B2i5eHsjie_18Zpq-F4AhABHvgU8vfmN2-uHdLbE=.48932bd2-332c-4e7b-a041-981b4d9a4693@github.com>
Message-ID: <4YNntGtGTpSrA9E3UAE0YBxTnh0i6UKZhp34BX0qF5U=.407fdf4a-e9cb-47b7-a1d3-12a24f174475@github.com>

On Wed, 11 Jan 2023 12:53:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 328:
>> 
>>> 326:          * For this purpose, a downcall method handle linked with the {@link #captureCallState(String[])}
>>> 327:          * option will feature an additional {@link MemorySegment} parameter directly
>>> 328:          * following the target address parameter. This parameter represents the native segment
>> 
>> Should we also mention the allocator parameter which can occur if the function returns a struct by value?
>
> Hmm yeah. The SegmentAllocator is also specified to be immediately after the address parameter, so it's unclear in which order they would be. I'll update this.

Mentioned the SegmentAllocator parameter as well now (in both places)

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

PR: https://git.openjdk.org/jdk20/pull/95

From mcimadamore at openjdk.org  Wed Jan 11 13:36:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 13:36:12 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v2]
In-Reply-To: <7mx3APvsfoJxsVdFI4NdbSeMnTS5bX8KCTC1wucgEjw=.0fda56a2-6794-4cb8-a31a-2d7d5c171599@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
 <7mx3APvsfoJxsVdFI4NdbSeMnTS5bX8KCTC1wucgEjw=.0fda56a2-6794-4cb8-a31a-2d7d5c171599@github.com>
Message-ID: <VovCSw6j5nXX2_pbb5H7six1uQM84tKYu3BIW8OvBEQ=.47679063-ca9b-4500-8581-e66345d2ebb6@github.com>

On Wed, 11 Jan 2023 13:17:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mention SegmentAllocator parameter as well

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/java/lang/foreign/Linker.java line 306:

> 304:          * <p>
> 305:          * A downcall method handle linked with this option will feature an additional {@link MemorySegment}
> 306:          * parameter directly following the target address, and optional SegmentAllocator parameters.

use `{@code}` or `{@link}` for SegmentAllocator

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

PR: https://git.openjdk.org/jdk20/pull/95

From alanb at openjdk.org  Wed Jan 11 13:46:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 13:46:11 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <XWeuFtHasOFu41shi9DYvFMVbbTquItYEl6LBTCGebk=.3f2a4334-28b1-4316-bde0-580564cf4547@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <XWeuFtHasOFu41shi9DYvFMVbbTquItYEl6LBTCGebk=.3f2a4334-28b1-4316-bde0-580564cf4547@github.com>
Message-ID: <KZxlLF4HfX9Ve8rnxtlAPs4Vt_yFU46IADLtgVX9_p0=.2bda04be-28d5-4d4c-ab1b-b80e6e56d099@github.com>

On Wed, 11 Jan 2023 11:53:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> I assume this issue has been there for a long time, just not noticed because it would be unusual to specify a width of this magnitude. The switch to using repeat + one insert looks good. Are you okay for tests in this area?

> @AlanBateman This is not a functional bug, only an enhancement to overcome the long times for large, unrealistic widths.
> Consequently, I have no specific tests that measure the timing against some hard-coded limits, if I understand you correctly.

My question wasn't phrased very well, I was really just asking if we have good test coverage for width in the format specifier  so that it would catch any regressions from changes to this code.

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

PR: https://git.openjdk.org/jdk/pull/11939

From jvernee at openjdk.org  Wed Jan 11 13:52:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 13:52:07 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v3]
In-Reply-To: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
Message-ID: <eaC4r4LY6JIt3nne5wn2lxAQj1dHZwn0dpQpX_NrzDE=.4a51ae07-b063-4593-93d1-1d2ecc3d4d99@github.com>

> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

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

  use @link

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/95/files
  - new: https://git.openjdk.org/jdk20/pull/95/files/ab53c5a6..ca3311c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=95&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=95&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/95/head:pull/95

PR: https://git.openjdk.org/jdk20/pull/95

From jvernee at openjdk.org  Wed Jan 11 13:52:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 13:52:10 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v2]
In-Reply-To: <VovCSw6j5nXX2_pbb5H7six1uQM84tKYu3BIW8OvBEQ=.47679063-ca9b-4500-8581-e66345d2ebb6@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
 <7mx3APvsfoJxsVdFI4NdbSeMnTS5bX8KCTC1wucgEjw=.0fda56a2-6794-4cb8-a31a-2d7d5c171599@github.com>
 <VovCSw6j5nXX2_pbb5H7six1uQM84tKYu3BIW8OvBEQ=.47679063-ca9b-4500-8581-e66345d2ebb6@github.com>
Message-ID: <qNXxsLl1MQlYN2z_hmlqJSVNb2pREL1aUNmBE_ADslo=.39d25272-bd47-4884-ad24-2bdfae2ebbae@github.com>

On Wed, 11 Jan 2023 13:33:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mention SegmentAllocator parameter as well
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 306:
> 
>> 304:          * <p>
>> 305:          * A downcall method handle linked with this option will feature an additional {@link MemorySegment}
>> 306:          * parameter directly following the target address, and optional SegmentAllocator parameters.
> 
> use `{@code}` or `{@link}` for SegmentAllocator

Ah, right. Updated

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

PR: https://git.openjdk.org/jdk20/pull/95

From jlaskey at openjdk.org  Wed Jan 11 13:57:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 11 Jan 2023 13:57:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v33]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <rRDJL3Dpa1ratmTaHsu2kpnSAwtZOrPViT8KnZON4Ak=.5907a039-665d-4742-9aa9-6ac492c1827b@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - Requested changes #10
 - Requested changes #9
 - ... and 38 more: https://git.openjdk.org/jdk/compare/87238470...098467f0

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=32
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Wed Jan 11 14:07:53 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 11 Jan 2023 14:07:53 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v34]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <aMzz-RB2a28FYxOS9RQNSfWihrd0oECGc0x7ZInGRzY=.6383a823-1d33-44e6-ae9f-1dcb7e589714@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Update to JDK 21

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/098467f0..57638f97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=32-33

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Wed Jan 11 14:15:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 14:15:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
Message-ID: <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>

On Wed, 11 Jan 2023 00:22:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> So, if the code was be like this:
>> 
>> 
>> ThisEscapeLoop ref11 = this;
>> ThisEscapeLoop ref12 = null;
>> ThisEscapeLoop ref13 = null;
>> ThisEscapeLoop ref14 = null;
>> for (int i = 0; i < 100; i++) {
>>     ref14 = ref13;
>>     ref13 = ref12;
>>     ref12 = ref11;
>>     ThisEscapeLoop ref21 = ref14;
>>     ThisEscapeLoop ref22 = null;
>>     ThisEscapeLoop ref23 = null;
>>     ThisEscapeLoop ref24 = null;
>>     for (int i = 0; i < 100; i++) {
>>         ref24 = ref23;
>>         ref23 = ref22;
>>         ref22 = ref21;
>>         if (ref24 != null)
>>             ref24.mightLeak();
>>     }
>> }
>> 
>> 
>> Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak?
>
> Actually I think it would take 1 + 1 + 3 iterations.
> 
> During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.
> 
> It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.
> 
> However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.

True - probably 3 * 3 can be achieved if this:


    ThisEscapeLoop ref21 = ref14;

Is replaced with   


    ThisEscapeLoop ref21 = this;


In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).

I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).

I suggest one experiment where you:
1. downgrade the warnings to notes (so that they won't make the JDK build fail)
2. enable this Lint everywhere
3. compare JDK `clean images` time w/ and w/o the Lint

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

PR: https://git.openjdk.org/jdk/pull/11874

From lancea at openjdk.org  Wed Jan 11 14:17:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Jan 2023 14:17:15 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v4]
In-Reply-To: <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
 <-aFDK_amcmbOhLES8mG-8lWJy8aHQIKMgc2FgleoMUI=.b1fddeaf-c3f8-454c-80ef-942d633bee5a@github.com>
Message-ID: <girQ7ukQN2mLkZ1KNwPEjdaAVbVPEFBvthQGMaM6Or0=.9444a69f-a35a-45dc-94bd-9165cd8c4d2c@github.com>

On Wed, 11 Jan 2023 08:43:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo and add bug ref

Thank you for the updates Per.  The changes look fine.

At a later date we should additional tests for the the non-null values passed to getAttribute et.al.

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11926

From lancea at openjdk.org  Wed Jan 11 14:17:16 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Jan 2023 14:17:16 GMT
Subject: RFR: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE [v4]
In-Reply-To: <WlZxA4NZY7RaYiT3I1Zs7nZqU3K0rttJMeTwlfa-6bI=.2adb617b-a991-41e4-a919-5e5ea0598e80@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
 <uQsVMsEsbWprC315LIjuCuA20JcAB6ymsIIRAJCgo18=.92cf0733-a314-446a-8e2e-b368f54f5aaa@github.com>
 <31Uf6u2Ivx4P23s-aSTNoGCFCwAL4O3z-wNLocXYqY4=.2eb1215c-4c79-4dbc-a228-fc07079c1927@github.com>
 <WlZxA4NZY7RaYiT3I1Zs7nZqU3K0rttJMeTwlfa-6bI=.2adb617b-a991-41e4-a919-5e5ea0598e80@github.com>
Message-ID: <y9rkIrHOCg0Rs4wnSCgOSRkA18TQNNKLx6Ml0WW0_eU=.3c38f6f8-6b9f-4d0c-8512-29e57d6ff230@github.com>

On Wed, 11 Jan 2023 08:59:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a implementation class in a non-exported package so it's okay.

Fair point

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

PR: https://git.openjdk.org/jdk/pull/11926

From jpai at openjdk.org  Wed Jan 11 14:35:31 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jan 2023 14:35:31 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
Message-ID: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>

Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?

The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.

The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.

A new jtreg test has been added which reproduces the issue and verifies the fix.

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

Commit messages:
 - fix jcheck issue - convert tab to space
 - Alan's input - remove "final" and match the current code style
 - take into account SecurityManager checks
 - 8206890: jlink --endian XXX generates unusable image if endian-ness does not match architecture

Changes: https://git.openjdk.org/jdk/pull/11943/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8206890
  Stats: 260 lines in 5 files changed: 250 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From alanb at openjdk.org  Wed Jan 11 14:35:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 14:35:32 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <XwMS56ZGOct5yo1neI1rA3O4JEmjbc_05axo-5BUZsg=.f5bba37d-7665-4fd7-8e59-bf2351224a1e@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

I hope @JimLaskey or @sundararajana can review this.

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 199:

> 197:      * @throws IOException If any error occurred reading the contents of the image file.
> 198:      */
> 199:     static ByteOrder tryDetectByteOrder(final Path imageFile) throws IOException {

Style-wise I think I would try to keep it consistent with the existing code if you can, meaning the noise/over-use of finals can mostly be removed if you can.

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

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Wed Jan 11 14:35:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jan 2023 14:35:33 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <Fjb-j8fv4anex_kR64SULL367y2DwdNkFvCMiyLzGCM=.bdafd023-7fec-40fc-a1bc-9815fff29c71@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

While running tier testing, one existing test showed that I hadn't taken into account SecurityManager checks in the new code that I had added. I have now fixed that part and pushed an update to the PR.

There's one additional unrelated test failing (`TestMaxCachedBufferSize`) in a odd way and I'll investigate it separately.

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

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Wed Jan 11 14:35:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jan 2023 14:35:35 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <XwMS56ZGOct5yo1neI1rA3O4JEmjbc_05axo-5BUZsg=.f5bba37d-7665-4fd7-8e59-bf2351224a1e@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <XwMS56ZGOct5yo1neI1rA3O4JEmjbc_05axo-5BUZsg=.f5bba37d-7665-4fd7-8e59-bf2351224a1e@github.com>
Message-ID: <4OyyRWT33ztiwsXiMZok7lIA4545c_guO2btA2g0atM=.ac2c3524-c331-44f0-bd27-168090ec7b58@github.com>

On Wed, 11 Jan 2023 13:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 199:
> 
>> 197:      * @throws IOException If any error occurred reading the contents of the image file.
>> 198:      */
>> 199:     static ByteOrder tryDetectByteOrder(final Path imageFile) throws IOException {
> 
> Style-wise I think I would try to keep it consistent with the existing code if you can, meaning the noise/over-use of finals can mostly be removed if you can.

Done. I've updated the PR to remove all the `final` usage from this part of the code and made it consistent with the current code.

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

PR: https://git.openjdk.org/jdk/pull/11943

From fabio19298 at gmail.com  Wed Jan 11 14:39:38 2023
From: fabio19298 at gmail.com (Fabio Romano)
Date: Wed, 11 Jan 2023 15:39:38 +0100
Subject: [PATCH] 8173962: Add API for Deep copy of multi-dimensional arrays
Message-ID: <CAEuo5R7+A5p-ENiww3gADB-GOCk9BHSWU-4ZxBdJXvpf7mMJCg@mail.gmail.com>

Added the methods deepCopyOf(U[] original, Class<? extends T[]> newType)
and deepCopyOf(T[] original), that perform a deep copy of the structure of
multidimensional arrays. Also, added a pre-calculation of the string
builders capacity for toString() of primitive array types, based on the
mold of BitSet.toString() method for pre-calculation of the initial
capacity.

The deep copy is necessary for coping a multiarray that should be assigned
to a field or returned by a getter method, to ensure that the data
structure will not be modified externally of the class.

The pre-calculation of the string builders capacity is an optimization to
reduce the times that builders needs to grow their capacity.

Link to the pull request: https://github.com/openjdk/jdk/pull/11815
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230111/5710e08a/attachment-0001.htm>

From fabio19298 at gmail.com  Wed Jan 11 14:40:16 2023
From: fabio19298 at gmail.com (Fabio Romano)
Date: Wed, 11 Jan 2023 15:40:16 +0100
Subject: [PATCH]: Code optimization for BitSet
Message-ID: <CAEuo5R7hU1eYXMZLKKpYRkwHjiSW+YzFDG8kPdvG62eFGoCarQ@mail.gmail.com>

The cardinality is saved as a field, new method for testing subset relation.
The enanchment is useful for applications that make heavy use of BitSet
objects as sets of integers, and therefore they need to make a lot of calls
to cardinality() method, which actually require linear time in the number
of words in use by the bit set.
This optimization reduces the cost of calling cardinality() to constant
time, as it simply returns the value of the field, and it also try to make
as little effort as possible to update the field, when needed.

Moreover, it has been implemented a new method for testing wheter a bit set
includes another bit set (i.e., the set of true bits of the parameter is a
subset of the true bits of the instance).

Link to the pull request: https://github.com/openjdk/jdk/pull/11837
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230111/06c058df/attachment.htm>

From pminborg at openjdk.org  Wed Jan 11 15:12:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 15:12:19 GMT
Subject: Integrated: 8299864: ZipFileStore#supportsFileAttributeView(String)
 doesn't throw NPE
In-Reply-To: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
References: <jkxpmSeYm9xU3h0bb1wwkSU5R8wzXJwyPZ3FdhDHnKU=.7d052c34-eb29-4f08-b015-5ed0467b5ac6@github.com>
Message-ID: <lk9U1ZqjSldxs5uH1kpnNiux_9swYM2WFFOsCWs0x8k=.f8e743d5-aa6e-4de1-889b-0e9dd11a74e2@github.com>

On Tue, 10 Jan 2023 15:26:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add null-checking for some parameter arguments in `ZipFileStore`.

This pull request has now been integrated.

Changeset: 7d3400b1
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d3400b1cf6befd28af81113b218d0aae60ac05f
Stats:     68 lines in 2 files changed: 45 ins; 1 del; 22 mod

8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE

Reviewed-by: lancea

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

PR: https://git.openjdk.org/jdk/pull/11926

From jvernee at openjdk.org  Wed Jan 11 15:17:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 15:17:14 GMT
Subject: [jdk20] RFR: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well [v3]
In-Reply-To: <eaC4r4LY6JIt3nne5wn2lxAQj1dHZwn0dpQpX_NrzDE=.4a51ae07-b063-4593-93d1-1d2ecc3d4d99@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
 <eaC4r4LY6JIt3nne5wn2lxAQj1dHZwn0dpQpX_NrzDE=.4a51ae07-b063-4593-93d1-1d2ecc3d4d99@github.com>
Message-ID: <5RHJY7X4l96wDs082xTC-ORgUiLN7x-OWpIcIVxfdDE=.74fcd26b-7bfe-410a-88a3-c0293ed2a6d0@github.com>

On Wed, 11 Jan 2023 13:52:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @link

Thanks for the reviews, could you review the CSR as well?

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

PR: https://git.openjdk.org/jdk20/pull/95

From rgiulietti at openjdk.org  Wed Jan 11 15:18:11 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 15:18:11 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <gb9qiZO0yLzP2Ntkp_C7wjW8ZF_dgkDamBEuzSxQr8g=.0eab64d3-7099-4168-8760-ab368b193fd2@github.com>

On Wed, 11 Jan 2023 10:47:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

Since specific tests for padding seem lacking, I'll add some as part of this PR.
Please expect another commit before marking as reviewed.

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

PR: https://git.openjdk.org/jdk/pull/11939

From aturbanov at openjdk.org  Wed Jan 11 15:18:20 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 11 Jan 2023 15:18:20 GMT
Subject: Integrated: 8299835: (jrtfs) Unnecessary null check in
 JrtPath.getAttributes
In-Reply-To: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
References: <u6DLsZWjQmZopoW1a0ddXtJsdoJTxefr_PNY-hW6ZV4=.3a0bff90-9125-4835-8cf4-c18318f2fa49@github.com>
Message-ID: <eW6KCOiIgLKB2PnxMXj1YodVZq-JvxuWSyhMmiZSlYk=.d6a2b6d8-7461-4214-9f5a-5824ed494bd2@github.com>

On Mon, 9 Jan 2023 20:55:14 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `jdk.internal.jrtfs.JrtFileSystem#getFileAttributes` never return `null`
> 
> https://github.com/openjdk/jdk/blob/679e485838881c1364845072af305fb60d95e60a/src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java#L206-L213
> So, no need to check for `null` its result.
> Seems it was copied from ZipPath (name of variable suggests that) - https://github.com/openjdk/jdk/blob/master/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java#L769. But for ZipFileSystem `null` is expected.

This pull request has now been integrated.

Changeset: 4cd87f1b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cd87f1bdab759ab7792afdcf644a6c3d21d51df
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes

Reviewed-by: alanb, lancea

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

PR: https://git.openjdk.org/jdk/pull/11911

From redestad at openjdk.org  Wed Jan 11 15:22:33 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Jan 2023 15:22:33 GMT
Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers
Message-ID: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>

This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.

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

Commit messages:
 - 8299978: Remove MethodHandleNatives.getMembers

Changes: https://git.openjdk.org/jdk/pull/11949/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11949&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299978
  Stats: 172 lines in 4 files changed: 0 ins; 171 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11949.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11949/head:pull/11949

PR: https://git.openjdk.org/jdk/pull/11949

From pminborg at openjdk.org  Wed Jan 11 15:23:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 15:23:17 GMT
Subject: RFR: 8299513: Clean up java.io [v8]
In-Reply-To: <bFe1iX2daV0aoIjNI6_BkTSHNlq_0cfpNszTmpxHhmk=.8a60c623-6973-4658-81d7-c5fa291b675c@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <EjvhhBjFiPnv29NdlRBEHMsq3rttIqHJirKtGqTf1mk=.c2a4f885-6bd6-45b1-bfed-5e9668a1025b@github.com>
 <bFe1iX2daV0aoIjNI6_BkTSHNlq_0cfpNszTmpxHhmk=.8a60c623-6973-4658-81d7-c5fa291b675c@github.com>
Message-ID: <HM81ko5b6bmhydeLsY5rFQvJIjW4PaHhhLIpEQtC9zM=.46d03e71-453b-4426-9e6c-b03ba7ba9fed@github.com>

On Wed, 11 Jan 2023 10:36:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert renaming
>
> src/java.base/share/classes/java/io/DataInputStream.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1994, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Only copyright year is updated in this file?

The previously proposed changes were rolled back. I will revert the year back to 2022.

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

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Wed Jan 11 15:31:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Jan 2023 15:31:22 GMT
Subject: RFR: 8299513: Clean up java.io [v9]
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

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

  Convert field to static and revert copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11848/files
  - new: https://git.openjdk.org/jdk/pull/11848/files/5a4cb55e..b3d115ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11848&range=07-08

  Stats: 8 lines in 2 files changed: 2 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11848/head:pull/11848

PR: https://git.openjdk.org/jdk/pull/11848

From jvernee at openjdk.org  Wed Jan 11 15:38:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 11 Jan 2023 15:38:14 GMT
Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers
In-Reply-To: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
References: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
Message-ID: <CYqWgaoHw-MB3VasIn7fDsfMRoqskbPrhZ8IImsdwYY=.7e0bd169-3a91-47fc-a760-b3eb94adafa2@github.com>

On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11949

From mcimadamore at openjdk.org  Wed Jan 11 16:02:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 16:02:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

More questions. Let's say that we only tracked escaping of direct references to `this`. Do you have any sense of how many "less" warnings would be reported in real code (e.g. JDK) ? What I mean by this - let's say that we don't care about tracking _where_ `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of `this` as a possible issue. Of course you could construct examples (like your tests) in which such a simplistic analysis would be defeated. What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR?

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 16:03:13 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 11 Jan 2023 16:03:13 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <IeUMIhupNBD0BdgWRKtSSz01LX0Hnom-Fo6RLRLoW-4=.d5d9fcbf-9c4d-44c7-ab07-c5a3ad6b38c1@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

I noticed that the baseline had a high variance in the above test results, so I added the warm-up and running time to retest. 

Here are the new results:

baseline:

Benchmark             (length)  Mode  Cnt         Score       Error  Units
NoRepl.testReadAscii         0  avgt    5       209.602 ?     2.982  ns/op
NoRepl.testReadAscii      1024  avgt    5       291.026 ?     0.266  ns/op
NoRepl.testReadAscii      8192  avgt    5       416.418 ?     1.083  ns/op
NoRepl.testReadAscii   1048576  avgt    5     29678.103 ?   119.644  ns/op
NoRepl.testReadAscii  33554432  avgt    5   1136507.598 ?  2597.706  ns/op
NoRepl.testReadUTF8          0  avgt    5       205.729 ?     1.229  ns/op
NoRepl.testReadUTF8       1024  avgt    5      1295.330 ?     4.092  ns/op
NoRepl.testReadUTF8       8192  avgt    5      9352.954 ?   126.249  ns/op
NoRepl.testReadUTF8    1048576  avgt    5   1202516.789 ?  2876.660  ns/op
NoRepl.testReadUTF8   33554432  avgt    5  44475835.218 ? 80173.497  ns/op


This PR:

Benchmark             (length)  Mode  Cnt         Score        Error  Units
NoRepl.testReadAscii         0  avgt    5       212.301 ?      1.002  ns/op
NoRepl.testReadAscii      1024  avgt    5       284.751 ?      1.685  ns/op
NoRepl.testReadAscii      8192  avgt    5       353.243 ?      2.501  ns/op
NoRepl.testReadAscii   1048576  avgt    5     19740.869 ?    137.207  ns/op
NoRepl.testReadAscii  33554432  avgt    5    853450.226 ?   7765.001  ns/op
NoRepl.testReadUTF8          0  avgt    5       200.015 ?      3.930  ns/op
NoRepl.testReadUTF8       1024  avgt    5      1281.397 ?     16.402  ns/op
NoRepl.testReadUTF8       8192  avgt    5      9333.988 ?      9.603  ns/op
NoRepl.testReadUTF8    1048576  avgt    5   1202822.719 ?   3187.910  ns/op
NoRepl.testReadUTF8   33554432  avgt    5  44579793.940 ? 106239.604  ns/op


The conclusion is basically unchanged.

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

PR: https://git.openjdk.org/jdk/pull/11897

From mcimadamore at openjdk.org  Wed Jan 11 16:17:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 16:17:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
Message-ID: <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>

On Wed, 11 Jan 2023 14:12:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Actually I think it would take 1 + 1 + 3 iterations.
>> 
>> During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references.
>> 
>> It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again.
>> 
>> However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code.
>
> True - probably 3 * 3 can be achieved if this:
> 
> 
>     ThisEscapeLoop ref21 = ref14;
> 
> Is replaced with   
> 
> 
>     ThisEscapeLoop ref21 = this;
> 
> 
> In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).
> 
> I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).
> 
> I suggest one experiment where you:
> 1. downgrade the warnings to notes (so that they won't make the JDK build fail)
> 2. enable this Lint everywhere
> 3. compare JDK `clean images` time w/ and w/o the Lint

Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.

If we build a graph of all the assignments, we get:

ref4 <- ref3 <- ref2 <- ref1 <- this

So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.

Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.

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

PR: https://git.openjdk.org/jdk/pull/11874

From naoto at openjdk.org  Wed Jan 11 17:04:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jan 2023 17:04:24 GMT
Subject: [jdk20] RFR: 8299439:
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
In-Reply-To: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>
References: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>
Message-ID: <mjrC--rQusX_igLIEIqHHxQAE-5kkHYiEeiky_HQJdA=.9a52a1e9-1ecd-4cc4-a502-830a4129ba20@github.com>

On Wed, 11 Jan 2023 09:21:18 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 4 Jan 2023 and was reviewed by Naoto Sato, Lance Andersen and Jaikiran Pai.
> 
> Thanks!

Looks good.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/96

From naoto at openjdk.org  Wed Jan 11 17:05:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jan 2023 17:05:25 GMT
Subject: Integrated: 8299571: ZoneRulesProvider.registerProvider() can leave
 inconsistent state on failure
In-Reply-To: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
References: <nMl-WRUXxPJJcdUs0E08iK-nI5siP2kgrwHqT2F8Hwk=.38b4015b-4723-4deb-a12f-d049c13b2fdb@github.com>
Message-ID: <UEorLnpwkI4Zb-2QW0kAI6tXOIVN6u4NBsRmd6rZsz0=.09b008c0-e949-4408-8116-12e004be70e9@github.com>

On Tue, 10 Jan 2023 17:17:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the subject method to recover gracefully on a failed `ZoneRulesProvider` registration.

This pull request has now been integrated.

Changeset: c7716a01
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7716a0101d337ec75ffdbcc3d18058a03c2373f
Stats:     99 lines in 2 files changed: 98 ins; 0 del; 1 mod

8299571: ZoneRulesProvider.registerProvider() can leave inconsistent state on failure

Reviewed-by: iris, rriggs, joehw

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

PR: https://git.openjdk.org/jdk/pull/11928

From duke at openjdk.org  Wed Jan 11 17:17:20 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 11 Jan 2023 17:17:20 GMT
Subject: Integrated: 8299836: Make `user.timezone` system property searchable
In-Reply-To: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
References: <3_RcmdN7PYIEWAdsBYPkvKF_cAHT6yaTSXjrhadUoyA=.adda2062-b37f-4731-bae7-02f1d40f3e24@github.com>
Message-ID: <EK4TpLlCtD-q3bR2RprvMnA1nCBELJ4RyX4ocgs3nA4=.c93746d2-4665-4b64-96e3-9f0765597671@github.com>

On Mon, 9 Jan 2023 23:59:19 GMT, Justin Lu <duke at openjdk.org> wrote:

> The system property _user.timezone_ is specified in the _TimeZone.getDefault()_ and _TimeZone.setDefault()_  methods. The javadoc search box should be able to match on the system property name.
> 
> This change replaces the **@code** tag with the **@systemProperty** tag for instances of _user.timezone_ when appropriate.

This pull request has now been integrated.

Changeset: 437d69a2
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/437d69a220a8615f845013e0b495c5b47d945698
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8299836: Make `user.timezone` system property searchable

Reviewed-by: jpai, naoto

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

PR: https://git.openjdk.org/jdk/pull/11915

From mchung at openjdk.org  Wed Jan 11 17:18:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 11 Jan 2023 17:18:12 GMT
Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers
In-Reply-To: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
References: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
Message-ID: <xs32Cu-SFoLbi9hSR5lBYg936aeCo4OzPa5rcg-Q6NA=.6615b61e-0aab-4872-ad9e-5a1ff80eda98@github.com>

On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11949

From duke at openjdk.org  Wed Jan 11 17:22:20 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 11 Jan 2023 17:22:20 GMT
Subject: Integrated: 8299498: Usage of constructors of primitive wrapper
 classes should be avoided in java.lang API docs
In-Reply-To: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
References: <xemNpGr64mkjvsSSBZCdZbrvSroerWWN8hiiewXOxwc=.d54b0098-329f-4512-9a86-da3507c4b4b0@github.com>
Message-ID: <LiowUQWnHaHix3Zr8VuKEuplo1eqhVsFRomHikRnzsA=.2f423676-fb5d-48af-b49b-3c860fcc349c@github.com>

On Mon, 9 Jan 2023 21:46:49 GMT, Justin Lu <duke at openjdk.org> wrote:

> The javadocs of the following methods used deprecated constructors of the primitive wrapper classes:
> 
> java.lang.ArrayStoreException
> java.lang.Byte.valueOf(String)
> java.lang.Byte.valueOf(String, int)
> java.lang.ClassCastException
> java.lang.Double.compare(double, double)
> java.lang.Float.compare(float, float)
> java.lang.Integer.getInteger(String, int)
> java.lang.Integer.valueOf(String)
> java.lang.Integer.valueOf(String, int)
> java.lang.Long.getLong(String, long)
> java.lang.Long.valueOf(String)
> java.lang.Long.valueOf(String, int)
> java.lang.Short.valueOf(String)
> java.lang.Short.valueOf(String, int) 
> 
> This change replaces the constructors with .valueOf() methods except java.lang.ClassCastException which was already fixed in JDK-8289730

This pull request has now been integrated.

Changeset: d663b5da
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d663b5da10be1f3f33a2729e4b3605fb5e13b4d6
Stats:     22 lines in 7 files changed: 0 ins; 0 del; 22 mod

8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs

Reviewed-by: naoto, darcy, rriggs, mchung, lancea

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

PR: https://git.openjdk.org/jdk/pull/11912

From jwilhelm at openjdk.org  Wed Jan 11 17:56:07 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Jan 2023 17:56:07 GMT
Subject: RFR: Merge jdk20
Message-ID: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299862: OfAddress setter should disallow heap segments
 - 8299849: Revert JDK-8294461: wrong effectively final determination by javac
 - 8299227: host `exif.org` not found in link in doc comment
 - 8299715: IR test: VectorGatherScatterTest.java fails with SVE randomly
 - 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop
 - 8299733: AArch64: "unexpected literal addressing mode" assertion failure with -XX:+PrintC1Statistics
 - 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11952/files
  Stats: 98 lines in 16 files changed: 53 ins; 19 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/11952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11952/head:pull/11952

PR: https://git.openjdk.org/jdk/pull/11952

From duke at openjdk.org  Wed Jan 11 18:05:49 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 11 Jan 2023 18:05:49 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v2]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <X8GY2eiAKsb_7K2V6FAh3CgBZp8U_x69O6BDbUXyNS8=.55112a1f-b13a-4018-b454-9d5e961c6552@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.

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

 - Document inDaylightTime
 - Document setID

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/19bd4fae..415ec9f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From rriggs at openjdk.org  Wed Jan 11 18:39:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Jan 2023 18:39:15 GMT
Subject: [jdk20] RFR: 8299034: Runtime::exec clarification of inherited
 environment
Message-ID: <ts0MSciQEQD5B0ElmI-KXdomAAA6O1UEHAASuqE_P6Q=.ebf4f0da-cdbf-4bdd-9002-e488edbee311@github.com>

The current description of Runtime.exec, ProcessBuilder.start, and ProcessBuilder.startPipeline identifies a minimum set of system dependent environment variables needed to launch a process and allows additional system dependent environment variables to be present in the child. However, it does not acknowledge that the parent's values of the minimum set of system dependent variables may not be appropriate for the child.

The description of the minimum set of system dependent environment variables is extended to allow the parent's values of those environment variables to be overridden in the child.

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

Commit messages:
 - 8299034: Runtime::exec clarification of inherited environment
 - 8299034: Runtime::exec clarification of inherited environment

Changes: https://git.openjdk.org/jdk20/pull/98/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=98&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299034
  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/98.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/98/head:pull/98

PR: https://git.openjdk.org/jdk20/pull/98

From duke at openjdk.org  Wed Jan 11 18:45:18 2023
From: duke at openjdk.org (altrisi)
Date: Wed, 11 Jan 2023 18:45:18 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
Message-ID: <RLAB53C-erT6brOdInDYXTm4wI3dgqIEG_j-FlRSK1I=.e715aae3-1f63-43d7-9a7f-cf8dc84e8e04@github.com>

On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace | with single value in example

Why not just `true` and `false`? Autoboxing handles that.

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

PR: https://git.openjdk.org/jdk/pull/11872

From duke at openjdk.org  Wed Jan 11 18:47:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 18:47:14 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
Message-ID: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>

On Wed, 11 Jan 2023 16:14:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> True - probably 3 * 3 can be achieved if this:
>> 
>> 
>>     ThisEscapeLoop ref21 = ref14;
>> 
>> Is replaced with   
>> 
>> 
>>     ThisEscapeLoop ref21 = this;
>> 
>> 
>> In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24).
>> 
>> I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit).
>> 
>> I suggest one experiment where you:
>> 1. downgrade the warnings to notes (so that they won't make the JDK build fail)
>> 2. enable this Lint everywhere
>> 3. compare JDK `clean images` time w/ and w/o the Lint
>
> Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.
> 
> If we build a graph of all the assignments, we get:
> 
> ref4 <- ref3 <- ref2 <- ref1 <- this
> 
> So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.
> 
> Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.

Good idea. Looks like the difference is in the noise, at least on my Macbook:

Builds of master (jdk-21+3-69-gc6588d5bb3f)
==================================

Build times:

    real	2m24.650s
    user	13m46.727s
    sys	2m33.554s

    real	2m27.224s
    user	13m43.464s
    sys	2m37.251s

    real	2m26.658s
    user	13m42.578s
    sys	2m36.133s

Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
==================================

Modifications:

    - Reverted files in the make/ subdirectory to enable warning
    - Commented out lines 363-382 in ThisEscapeAnalyzer.java
      so no warnings are actually reported

Build times:

    real	2m25.912s
    user	13m45.860s
    sys	2m32.741s

    real	2m27.213s
    user	13m44.830s
    sys	2m36.596s

    real	2m25.756s
    user	13m42.889s
    sys	2m35.659s

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 18:56:21 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 11 Jan 2023 18:56:21 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <RLAB53C-erT6brOdInDYXTm4wI3dgqIEG_j-FlRSK1I=.e715aae3-1f63-43d7-9a7f-cf8dc84e8e04@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
 <RLAB53C-erT6brOdInDYXTm4wI3dgqIEG_j-FlRSK1I=.e715aae3-1f63-43d7-9a7f-cf8dc84e8e04@github.com>
Message-ID: <CFreZRHG771JhaRbyoT33pr_61fgAt-eAOxyXJXss-Q=.d9fa3724-bf3c-4feb-9d74-8a0705bb1a1a@github.com>

On Wed, 11 Jan 2023 18:41:59 GMT, altrisi <duke at openjdk.org> wrote:

> Why not just `true` and `false`? Autoboxing handles that.

That was a topic that was talked about in [8299498](https://github.com/openjdk/jdk/pull/11912). It seemed that there was a consensus from a documentation standpoint that it was more clear to use the wrapper methods/fields (valueOf() or in this case Boolean.TRUE)

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

PR: https://git.openjdk.org/jdk/pull/11872

From vlivanov at openjdk.org  Wed Jan 11 19:09:36 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 11 Jan 2023 19:09:36 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
Message-ID: <_vJ-5zerpDnHng8O_QZ5LEfVb09knfCRIrWfHRB1eTQ=.f01389ce-82e9-4073-86e3-08b70219cf0b@github.com>

On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly lea external address

Before the patch goes in, I'd like to see a plan how the code will be refactored later.

At the very least, I expect `is_string_hashcode`-related logic to go away and the intrinsic logic to be guided solely by a basic type of elements. If not in the initial version, then shortly after as a follow-up enhancement. Another thing I want to see is `VectorizedHashCode` node to go away and replaced with a stub call.

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

Changes requested by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10847

From rgiulietti at openjdk.org  Wed Jan 11 19:11:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 19:11:29 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v2]
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <RU5f2r64mC9PNFOUqPqslePAFK0vjekg-iu2mM8Fy9g=.7efb1a35-acbf-41cb-8ffe-617057416773@github.com>

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

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

  8299677: Formatter.format might take a long time to format an integer or floating-point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11939/files
  - new: https://git.openjdk.org/jdk/pull/11939/files/26e05ca5..e5418829

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=00-01

  Stats: 250 lines in 1 file changed: 250 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11939.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11939/head:pull/11939

PR: https://git.openjdk.org/jdk/pull/11939

From rgiulietti at openjdk.org  Wed Jan 11 19:11:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 19:11:29 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <rRIKaZnYk_uehKloJ-y7JeM4z17B3w1WX44m20k1i0Q=.c1484d5c-060e-4893-9c4a-22caeca94b2c@github.com>

On Wed, 11 Jan 2023 10:47:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

Added straightforward tests for padding.

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

PR: https://git.openjdk.org/jdk/pull/11939

From duke at openjdk.org  Wed Jan 11 19:13:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 19:13:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
Message-ID: <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>

On Wed, 11 Jan 2023 18:44:20 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4.
>> 
>> If we build a graph of all the assignments, we get:
>> 
>> ref4 <- ref3 <- ref2 <- ref1 <- this
>> 
>> So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there.
>> 
>> Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case.
>
> Good idea. Looks like the difference is in the noise, at least on my Macbook:
> 
> Builds of master (jdk-21+3-69-gc6588d5bb3f)
> ==================================
> 
> Build times:
> 
>     real	2m24.650s
>     user	13m46.727s
>     sys	2m33.554s
> 
>     real	2m27.224s
>     user	13m43.464s
>     sys	2m37.251s
> 
>     real	2m26.658s
>     user	13m42.578s
>     sys	2m36.133s
> 
> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
> ==================================
> 
> Modifications:
> 
>     - Reverted files in the make/ subdirectory to enable warning
>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>       so no warnings are actually reported
> 
> Build times:
> 
>     real	2m25.912s
>     user	13m45.860s
>     sys	2m32.741s
> 
>     real	2m27.213s
>     user	13m44.830s
>     sys	2m36.596s
> 
>     real	2m25.756s
>     user	13m42.889s
>     sys	2m35.659s

Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?

Consider this example:

public class ThisEscapeLoop { 
    
    public ThisEscapeLoop() { 
        ThisEscapeLoop ref1 = this;
        ThisEscapeLoop ref2 = null;
        ThisEscapeLoop ref3 = null;
        ThisEscapeLoop ref4 = null;
        for (int i = 0; i < 100; i++) {
            ref4 = this.returnMe(ref3);
            ref3 = ref2;
            ref2 = ref1;
            if (ref4 != null)
                ref4.mightLeak();
        }
    }

    public <T> T returnMe(T x) {
        return x;
    }

    public void mightLeak() {
    }
}

If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

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

PR: https://git.openjdk.org/jdk/pull/11874

From rgiulietti at openjdk.org  Wed Jan 11 19:29:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 19:29:52 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v3]
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <ea6o7y3ZbEB7c912MBkXzmsTtgxfnMLDjauypokpjz0=.5b5cbae3-86c4-4bf6-b047-ba121b728dac@github.com>

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

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

  8299677: Formatter.format might take a long time to format an integer or floating-point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11939/files
  - new: https://git.openjdk.org/jdk/pull/11939/files/e5418829..8c3e3856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=01-02

  Stats: 113 lines in 1 file changed: 112 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11939.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11939/head:pull/11939

PR: https://git.openjdk.org/jdk/pull/11939

From rgiulietti at openjdk.org  Wed Jan 11 19:34:39 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Jan 2023 19:34:39 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

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

  8299677: Formatter.format might take a long time to format an integer or floating-point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11939/files
  - new: https://git.openjdk.org/jdk/pull/11939/files/8c3e3856..275582a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11939.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11939/head:pull/11939

PR: https://git.openjdk.org/jdk/pull/11939

From duke at openjdk.org  Wed Jan 11 19:47:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 19:47:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <jkX4MXwtRWUOJZzkkkg1OpQtZkQ8eVvJgYq0mMze9P4=.edf63f99-3155-4f1a-bb63-d28d88dd0698@github.com>
Message-ID: <tjWnyDfAJ3jkcI_faWMqZLwpffQGr06RXG2OGnlp2cA=.754cd23a-1782-4d80-b32e-a27fd23bba30@github.com>

On Wed, 11 Jan 2023 15:59:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR?

It's a good question. Here are some thoughts...

One meta-goal is that this analysis be conservative. In other words, if your code does NOT generate any warnings, then you should feel confident that there is a high probability that there are no leaks.

This is analogous to how you can be confident that you won't get any `ClassCastExceptions` at runtime if your code doesn't generate any `unchecked` warnings at compile time.

I think this point is generally agreed upon.

If so, then we would want?any simpler analysis to err on the side of generating more false positives rather than more false negatives.

Assuming that, then the question comes down to a trade-off between code complexity vs. rate of false positives.

>From my casual looking over the JDK, the current algorithm generates very few false positives - almost all of the warnings represent actual leaks (I'd be interested in any false positives you do see).
 
(Of course, an irony is that most of these leaks have no real-world effect. For example package-private classes in the JDK (a) have already been debugged long ago, so any intra-package bugs due to 'this' escapes have already been fixed; and (b) are unlikely to be subclassed by anyone. And the ones that have a real-world effect (e.g., `HashSet(Collection)`) can't be fixed because of backward compatibility concerns. So this warning is most useful when writing new code.)

So the current code is clearly "complex enough" already. FWIW that's ~975 lines of code excluding blank lines and comments.

Now to answer your question about a theoretical simpler analysis:

> let's say that we don't care about tracking where `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of this as a possible issue.

I'm not sure I completely understand the semantics. But are you saying that if a constructor invokes a private or static method, then this simpler analysis would always declare a leak?

If that's the case then I think there are a lot of new false positives, because this is common in constructors.

I would then worry that if we dilute the warnings with a bunch of new false positives people are just going to get discouraged and turn the warning off completely.

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Wed Jan 11 20:05:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jan 2023 20:05:22 GMT
Subject: [jdk20] RFR: 8299034: Runtime::exec clarification of inherited
 environment
In-Reply-To: <ts0MSciQEQD5B0ElmI-KXdomAAA6O1UEHAASuqE_P6Q=.ebf4f0da-cdbf-4bdd-9002-e488edbee311@github.com>
References: <ts0MSciQEQD5B0ElmI-KXdomAAA6O1UEHAASuqE_P6Q=.ebf4f0da-cdbf-4bdd-9002-e488edbee311@github.com>
Message-ID: <BKT8kKeIuthBIOgdyDuGlKF4TUUaV4z8lDXeahpxycI=.80a32357-3afb-47de-9824-954b2e797a88@github.com>

On Wed, 11 Jan 2023 18:31:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The current description of Runtime.exec, ProcessBuilder.start, and ProcessBuilder.startPipeline identifies a minimum set of system dependent environment variables needed to launch a process and allows additional system dependent environment variables to be present in the child. However, it does not acknowledge that the parent's values of the minimum set of system dependent variables may not be appropriate for the child.
> 
> The description of the minimum set of system dependent environment variables is extended to allow the parent's values of those environment variables to be overridden in the child.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/98

From darcy at openjdk.org  Wed Jan 11 20:51:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Jan 2023 20:51:17 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <xJ6AcFTseO0APz3UiElSegTmB9XAPdncXTpLvBvDzSk=.3f25a420-18e5-4500-8180-3a09e12b8a75@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

Per the discussion in "Effective Java" on calling overridable methods in a constructor, future refinements of the check under review here could be extended to examine the bodies of clone and readObject methods.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Wed Jan 11 21:04:43 2023
From: duke at openjdk.org (Justin Lu)
Date: Wed, 11 Jan 2023 21:04:43 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v3]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <WTSr_Uzq1Jg99V0JZTcAfSZAtvaL6q2QMTNJiQyVNxw=.ec2a7147-91cf-4abb-a196-734345a29304@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.
> 
> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_

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

 - (c) year for stz
 - Allow STZ inDaylightTime to inherit throws

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/415ec9f4..ae49f170

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From redestad at openjdk.org  Wed Jan 11 21:26:21 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Jan 2023 21:26:21 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
Message-ID: <IA9R4HSf23z74F4AmxwCOx_R3VdOwU4FOUUK1vjGVP4=.88d52ba3-3cdf-46c9-a9e6-0f5a52144448@github.com>

On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly lea external address

I'm not convinced using basic types - with `T_BOOLEAN` for unsigned byte - improves this much. It'd of course be nice with something more canonical than a set of adhoc constants strewn in here to steer this, but maybe we should pass element size and signedness. I think this would be a reasonable cleanup. 

I'd also be willing to spend time rewriting as a stub call if someone could give me some pointers on how to best do that. This might be straightforward and simplify the implementation, but making a stub call could have noticeable overheads for small strings. A this is the common case the stub call overhead *could* be prohibitively expensive. An alternative is to keep the new node but extract the vectorized path as a stub routine and call it from inside the inlined intrinsic - similarly to what's done in `C2_MacroAssembler::string_compare` on aarch64.

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

PR: https://git.openjdk.org/jdk/pull/10847

From mcimadamore at openjdk.org  Wed Jan 11 21:48:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 21:48:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
Message-ID: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>

On Wed, 11 Jan 2023 19:10:04 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>> 
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==================================
>> 
>> Build times:
>> 
>>     real	2m24.650s
>>     user	13m46.727s
>>     sys	2m33.554s
>> 
>>     real	2m27.224s
>>     user	13m43.464s
>>     sys	2m37.251s
>> 
>>     real	2m26.658s
>>     user	13m42.578s
>>     sys	2m36.133s
>> 
>> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
>> ==================================
>> 
>> Modifications:
>> 
>>     - Reverted files in the make/ subdirectory to enable warning
>>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>>       so no warnings are actually reported
>> 
>> Build times:
>> 
>>     real	2m25.912s
>>     user	13m45.860s
>>     sys	2m32.741s
>> 
>>     real	2m27.213s
>>     user	13m44.830s
>>     sys	2m36.596s
>> 
>>     real	2m25.756s
>>     user	13m42.889s
>>     sys	2m35.659s
>
> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
> 
> Consider this example:
> 
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = this.returnMe(ref3);
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public <T> T returnMe(T x) {
>         return x;
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

> Good idea. Looks like the difference is in the noise, at least on my Macbook:
> 
> ```
> Builds of master (jdk-21+3-69-gc6588d5bb3f)
> ==================================
> 
> Build times:
> 
>     real	2m24.650s
>     user	13m46.727s
>     sys	2m33.554s
> 
>     real	2m27.224s
>     user	13m43.464s
>     sys	2m37.251s
> 
>     real	2m26.658s
>     user	13m42.578s
>     sys	2m36.133s
> 
> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
> ==================================
> 
> Modifications:
> 
>     - Reverted files in the make/ subdirectory to enable warning
>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>       so no warnings are actually reported
> 
> Build times:
> 
>     real	2m25.912s
>     user	13m45.860s
>     sys	2m32.741s
> 
>     real	2m27.213s
>     user	13m44.830s
>     sys	2m36.596s
> 
>     real	2m25.756s
>     user	13m42.889s
>     sys	2m35.659s
> ```

Thanks for trying it out - good to know that build time isn't affected.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Wed Jan 11 21:54:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jan 2023 21:54:17 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
Message-ID: <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>

On Wed, 11 Jan 2023 21:45:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
>> 
>> Consider this example:
>> 
>> public class ThisEscapeLoop { 
>>     
>>     public ThisEscapeLoop() { 
>>         ThisEscapeLoop ref1 = this;
>>         ThisEscapeLoop ref2 = null;
>>         ThisEscapeLoop ref3 = null;
>>         ThisEscapeLoop ref4 = null;
>>         for (int i = 0; i < 100; i++) {
>>             ref4 = this.returnMe(ref3);
>>             ref3 = ref2;
>>             ref2 = ref1;
>>             if (ref4 != null)
>>                 ref4.mightLeak();
>>         }
>>     }
>> 
>>     public <T> T returnMe(T x) {
>>         return x;
>>     }
>> 
>>     public void mightLeak() {
>>     }
>> }
>> 
>> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.
>
>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>> 
>> ```
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==================================
>> 
>> Build times:
>> 
>>     real	2m24.650s
>>     user	13m46.727s
>>     sys	2m33.554s
>> 
>>     real	2m27.224s
>>     user	13m43.464s
>>     sys	2m37.251s
>> 
>>     real	2m26.658s
>>     user	13m42.578s
>>     sys	2m36.133s
>> 
>> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8)
>> ==================================
>> 
>> Modifications:
>> 
>>     - Reverted files in the make/ subdirectory to enable warning
>>     - Commented out lines 363-382 in ThisEscapeAnalyzer.java
>>       so no warnings are actually reported
>> 
>> Build times:
>> 
>>     real	2m25.912s
>>     user	13m45.860s
>>     sys	2m32.741s
>> 
>>     real	2m27.213s
>>     user	13m44.830s
>>     sys	2m36.596s
>> 
>>     real	2m25.756s
>>     user	13m42.889s
>>     sys	2m35.659s
>> ```
> 
> Thanks for trying it out - good to know that build time isn't affected.

> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.?
> 
> Consider this example:
> 
> ```java
> public class ThisEscapeLoop { 
>     
>     public ThisEscapeLoop() { 
>         ThisEscapeLoop ref1 = this;
>         ThisEscapeLoop ref2 = null;
>         ThisEscapeLoop ref3 = null;
>         ThisEscapeLoop ref4 = null;
>         for (int i = 0; i < 100; i++) {
>             ref4 = this.returnMe(ref3);
>             ref3 = ref2;
>             ref2 = ref1;
>             if (ref4 != null)
>                 ref4.mightLeak();
>         }
>     }
> 
>     public <T> T returnMe(T x) {
>         return x;
>     }
> 
>     public void mightLeak() {
>     }
> }
> ```
> 
> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak.

So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak (leaving aside heroics to try and chase the method body and see what the body of the method actually does).

And, if the method is static, same story - you are passing `ref3` somewhere else, and `ref3` potentially contains `this`. 

While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect _precisely_ if the leak happens to try to detect if _potentially_ a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is
  a problem where I feel it's easy to get in the land of diminishing returns).

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

PR: https://git.openjdk.org/jdk/pull/11874

From jwilhelm at openjdk.org  Wed Jan 11 21:54:24 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Jan 2023 21:54:24 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>
References: <Yn_7_yZ9O05eJRGO3U4IGvq2a8RDpOZwH_QCIDz8fMc=.b50b927a-bc2f-44ec-972b-658ab79a45ed@github.com>
Message-ID: <ZpBEyPH4e6fccqJ226CbGMlT7q7QtzeKc5uT3V0suec=.e09e9031-c765-4643-81c1-189b53f16efe@github.com>

On Wed, 11 Jan 2023 17:47:27 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 33f3bd8f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33f3bd8fadb26a0f99c6a13474f8676639f91c0c
Stats:     98 lines in 16 files changed: 53 ins; 19 del; 26 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11952

From duke at openjdk.org  Wed Jan 11 22:43:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 11 Jan 2023 22:43:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
Message-ID: <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>

On Wed, 11 Jan 2023 21:51:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak

D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.

> And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.

Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.

In other words, any method (or constructor) in the current compilation unit that can't be overridden is never considered "somewhere else".

> While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect precisely if the leak happens to try to detect if potentially a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is a
  problem where I feel it's easy to get in the land of diminishing returns).

I can only report from my own experience. I thought about this a bit and tried a few different things and what I ended up was the best I could come up with in terms of that trade-off. Of course there was a good bit of intuition and SWAG'ing in that and also a lot of thought experiments.

Of course if you have a clever idea for how to do this in a simpler way that achieves basically the same result, I'm all ears :)

But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).

A lot of my initial ideas were too simple for my taste, because I could easily find real-world false negatives.

An example of "too simple": at first I was not trying to track an outer 'this'. But I found a lot of constructors out there that instantiate nested classes and then do things with them. Without tracking outer 'this' these would all be missed.

To take a random example of that:

public class FileChooserDemo extends JPanel implements ActionListener {
    ...
    public FileChooserDemo() {
        ...
        // create a radio listener to listen to option changes
        OptionListener optionListener = new OptionListener();
 
         // Create options
        openRadioButton = new JRadioButton("Open");
        openRadioButton.setSelected(true);
        openRadioButton.addActionListener(optionListener);  // <- LEAK HERE
        ...
    }

    private class OptionListener implements ActionListener {
        ...
    }
}

That particular leak is (probably) innocuous, but it still qualifies as a leak and should be reported. Note that failing to track an outer 'this' causes false negatives, which are a bigger problem than false positives.

On the flip side, I started out trying to explicitly track field references, but that seemed like more complexity than needed, at least for phase 1, so that was left out.

The "flooding" aspect didn't really worry me because the reference set is "append only" and there is small, finite set of possible references at each scope, so it can't really get that out of hand. Testing indeed shows it's not a problem. By the way recursion also "floods" until convergence, just like looping.

I would have been pleased to find "a much simpler scheme". But the more I thought about those options, the more I came up with easy misses. And after a certain point, it actually became easier to simply "execute" the code by scanning the AST while carrying around a `Set<Ref>` to track possible references. It's really that simple. Instead of trying to be "smart" we just let the code tell us what happens.

Apologies if this is not a very good answer to your question.

In the big picture, the false positive rate is traded-off against code complexity, and we want the best possible trade-off, right?

But how are you defining "complexity"?

If you really mean performance, then I don't see a problem... the JDK build times are essentially unchanged.

If you mean lines of code or whatever, then it doesn't seem inordinate. And the algorithm is more or less just an AST scan, like lots of other examples in the compiler code. So I don't see a problem there either.

Yes, there may be a much simpler way that's just as good, but if I could have thought of it I would have already. Perhaps you or someone else has better insight.

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

PR: https://git.openjdk.org/jdk/pull/11874

From smarks at openjdk.org  Thu Jan 12 00:16:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jan 2023 00:16:16 GMT
Subject: RFR: 8299513: Clean up java.io [v9]
In-Reply-To: <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
Message-ID: <gVa9pZJkvIdaFKHOg8nKHqIYv7v-62Dc9vyTHEADjLc=.d258139b-a143-41cb-b77e-d8d18e4078c0@github.com>

On Wed, 11 Jan 2023 15:31:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert field to static and revert copyright year

Some general comments on this PR. It contains a lot of different changes, all mixed together. Some of the changes have more value than others, but since they're all mixed together it can be hard to tease them apart.

Some changes, like anachronistic array declarations (e.g., `int foo[]` instead of `int[] foo`) clearly need to be done. Fixing constants to have CAPITALIZED_SNAKE_CASE is also fairly straightforward and should be done too.

Some renamings are a bit dubious, e.g. `U` => `UNSAFE` in one case. OK well sure `U` might look like a type variable, but in context it was quite clear that `U` was the Unsafe instance. However, renaming to `UNSAFE` isn't necessarily bad, so maybe this is ok.

Some nested classes had `final` added. I'm not sure of the utility of this. Is there some general rule that "everything that can be declared final should be" ? This isn't quite as bad people who insist on declaring every local variable as final, but it seems to be edging in that direction -- specifically, adding clutter without adding value.

In some cases removing `static final` from constants that are declared in interfaces seems like a step in the wrong directly. Formally, an interface that contains a field initialized to a constant expression is public, static, and final. (JLS 9.3.) I think most people accept that it's not necessary to declare everything (redundantly) public in an interface. But it seems to be conventional to have static and final present on the declaration even though they're arguably redundant as well. I'm not sure why this is nor why static and final aren't treated the same way as public. At least, I don't feel the same way about them.

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

PR: https://git.openjdk.org/jdk/pull/11848

From mcimadamore at openjdk.org  Thu Jan 12 00:18:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 00:18:11 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
Message-ID: <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>

On Wed, 11 Jan 2023 22:40:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> 
> D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.
> 
> > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.
> 
> Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.
> 

So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:

ref1 -> ref2 -> ref3 -> x -> ref4

> But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).

The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be.

I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way.

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

PR: https://git.openjdk.org/jdk/pull/11874

From smarks at openjdk.org  Thu Jan 12 02:00:22 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 12 Jan 2023 02:00:22 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for Entry.setValue
Message-ID: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>

Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.

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

Commit messages:
 - 8038146: Clarify NavigableMap/TreeMap support for Entry.setValue

Changes: https://git.openjdk.org/jdk/pull/11956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8038146
  Stats: 77 lines in 4 files changed: 41 ins; 3 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11956/head:pull/11956

PR: https://git.openjdk.org/jdk/pull/11956

From duke at openjdk.org  Thu Jan 12 02:17:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 02:17:16 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
Message-ID: <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>

On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:

Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references.

>  in order to try and build a mental problem of what the problem that needs to be solved is

Gotcha.

Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning.

So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning.

OK, so where can a 'this' reference go?

Well, here are all of the possible places a Java reference can exist:
1. On the Java stack
    (a) The current 'this' instance
    (b) A method parameter
    (c) A local variable
    (d) A temporary value that is part of the current expression being evaluated
    (e) The return value from a method that just returned
    (f) A caught exception
1. In a field of some object...
    (a) A normal field
    (b) An outer 'this' instance
    (c) Other synthetic field (e.g., captured free variable)
1. As an element in a reference array
1. In native code as a native reference

Those are the only possibilities AFAIK.

So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try?

The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4.

So to think about the overall problem, imagine how you might or might not address all of those cases.

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

PR: https://git.openjdk.org/jdk/pull/11874

From jvernee at openjdk.org  Thu Jan 12 06:52:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Jan 2023 06:52:21 GMT
Subject: [jdk20] Integrated: 8299090: Specify coordinate order for additional
 CaptureCallState parameters on class as well
In-Reply-To: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
References: <CnKBPWTI4T-BnTwVVp9Xibfsm2yENb5xJnYQEqX0Xa0=.61e4ecc5-fdbc-4c14-a25b-30d121e42cf1@github.com>
Message-ID: <AmO2YiFbqqdC_vfopnUS68TNPfLGAB1iZbPLgi8V6cg=.8c4913ab-b572-40a6-93ff-5eb5d113c957@github.com>

On Wed, 11 Jan 2023 02:19:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> A small doc clarification that also specifies where the additional MemorySegment parameter of a downcall method handle linked with the captureCallState option appears in the parameter list, on the CaptureCallState class.

This pull request has now been integrated.

Changeset: 3918f9f5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/3918f9f523521e77bd3820be28d79a4c1d02903c
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8299090: Specify coordinate order for additional CaptureCallState parameters on class as well

Reviewed-by: pminborg, mcimadamore

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

PR: https://git.openjdk.org/jdk20/pull/95

From clanger at openjdk.org  Thu Jan 12 08:03:23 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 12 Jan 2023 08:03:23 GMT
Subject: [jdk20] RFR: 8299439:
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
In-Reply-To: <mjrC--rQusX_igLIEIqHHxQAE-5kkHYiEeiky_HQJdA=.9a52a1e9-1ecd-4cc4-a502-830a4129ba20@github.com>
References: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>
 <mjrC--rQusX_igLIEIqHHxQAE-5kkHYiEeiky_HQJdA=.9a52a1e9-1ecd-4cc4-a502-830a4129ba20@github.com>
Message-ID: <w1CVS6MEf52jym3xOEarm66u6NkDfXVVkdmJV5fxgwg=.0d526991-9ee6-4e63-ab3d-c791d2a7b67b@github.com>

On Wed, 11 Jan 2023 17:01:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Justin Lu on 4 Jan 2023 and was reviewed by Naoto Sato, Lance Andersen and Jaikiran Pai.
>> 
>> Thanks!
>
> Looks good.

Thanks for confirming, @naotoj

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

PR: https://git.openjdk.org/jdk20/pull/96

From clanger at openjdk.org  Thu Jan 12 08:06:20 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 12 Jan 2023 08:06:20 GMT
Subject: [jdk20] Integrated: 8299439:
 java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
In-Reply-To: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>
References: <zxX8gPB9oF_K54z3fevB0_cuR8GvlbzVZHicr9RUOps=.ec0af31b-7e20-4a05-a6b3-83d7cbb5aa4d@github.com>
Message-ID: <o_FV4Y2b2r_HJxJXcQ_0xnyN7wEq4L2gXF8wdWQ9eg4=.076a87af-823f-452d-b982-d0b1d6652c4b@github.com>

On Wed, 11 Jan 2023 09:21:18 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 4 Jan 2023 and was reviewed by Naoto Sato, Lance Andersen and Jaikiran Pai.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 752a3701
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/752a37016f49ef8f2405dd74f96f58f80d606cd3
Stats:     8 lines in 3 files changed: 1 ins; 2 del; 5 mod

8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR

Reviewed-by: naoto
Backport-of: 3b374c0153950ab193f3a188b57d3404b4ce2fe2

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

PR: https://git.openjdk.org/jdk20/pull/96

From pminborg at openjdk.org  Thu Jan 12 08:08:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Jan 2023 08:08:14 GMT
Subject: RFR: 8299513: Clean up java.io [v9]
In-Reply-To: <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
Message-ID: <WJXtHSd0i8fy-vscxCQ0py6ncLBV9N8d9BG_3mDTU50=.9e019952-1053-41c6-a80c-919987b4c91d@github.com>

On Wed, 11 Jan 2023 15:31:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert field to static and revert copyright year

It is easy to fall into the trap "I'll just fix everything I see now that I am here anyway" which it appears I have done in this case. Even though I had the best intentions, I think we should close this PR and replace it with several smaller ones that focus on a specific problem.

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

PR: https://git.openjdk.org/jdk/pull/11848

From duke at openjdk.org  Thu Jan 12 08:21:17 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 12 Jan 2023 08:21:17 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <OAsAgO7rmJ-_nm27oX4wa_ly2OQpgbZkb7VbavSsk4Y=.1f132c73-2a26-41b3-b0ee-2ec13909e58a@github.com>

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

This?PR should?probably also?add the?[`@Override`]?annotation to?overridden?methods in?the?[`ConcurrentHashMap`]?class.

[`@Override`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Override.html
[`ConcurrentHashMap`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html

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

PR: https://git.openjdk.org/jdk/pull/11924

From asotona at openjdk.org  Thu Jan 12 09:11:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Jan 2023 09:11:15 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v7]
In-Reply-To: <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
Message-ID: <eGEdEZySgrApvEtdM33rdWpxHGAt3qcRtgCRpI--NN4=.1c1ee24a-74b3-4116-bc11-2ea1511bde36@github.com>

On Fri, 16 Dec 2022 18:22:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> **This pull request is not intended for immediate integration to JDK mainline.**
>> 
>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removal of Preview.java and TransPatterns.java patch
>    and enabled preview for java.base
>  - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview

Classfile API implementation is now ready for review.

There is one integration obstacle - it heavily uses pattern switch language feature and that is still a preview.

Part of history of this pull request are two different solutions (see https://github.com/openjdk/jdk/pull/10982/commits/c42dc3e4472e6e7b78607bcdbc26d8d09bde0349):
1. enable preview for compilation of java.base (without writing preview minor class versions into the affected classfiles)
2. or patch interim compiler to exclude pattern switch from preview features for JDK compilation

I would prefer to choose one of the options and integrate Classfile API into JDK mainline ASAP, because of many waiting dependences (see [JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) and despite the perspective that pattern switch feature might be finalized soon.

Thanks for your review.

Adam

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

PR: https://git.openjdk.org/jdk/pull/10982

From pminborg at openjdk.org  Thu Jan 12 09:28:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Jan 2023 09:28:46 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap [v2]
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <r07Yd3aYRKApMnk68W58Ck77FyMMvztPy0xbr9mVgjQ=.f2826176-6a41-488c-a732-a84ef8c1c0ad@github.com>

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

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

  Add @Override annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11924/files
  - new: https://git.openjdk.org/jdk/pull/11924/files/feafe91b..91c4862b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=00-01

  Stats: 151 lines in 1 file changed: 150 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11924/head:pull/11924

PR: https://git.openjdk.org/jdk/pull/11924

From mcimadamore at openjdk.org  Thu Jan 12 10:00:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 10:00:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
Message-ID: <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>

On Thu, 12 Jan 2023 02:14:10 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> 
>>> D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold.
>>> 
>>> > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this.
>>> 
>>> Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it.
>>> 
>> 
>> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:
>> 
>> ref1 -> ref2 -> ref3 -> x -> ref4
>> 
>>> But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person).
>> 
>> The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be.
>> 
>> I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way.
>
>> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again:
> 
> Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references.
> 
>>  in order to try and build a mental problem of what the problem that needs to be solved is
> 
> Gotcha.
> 
> Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning.
> 
> So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning.
> 
> OK, so where can a 'this' reference go?
> 
> Well, here are all of the possible places a Java reference can exist:
> 1. On the Java stack
>     (a) The current 'this' instance
>     (b) A method parameter
>     (c) A local variable
>     (d) A temporary value that is part of the current expression being evaluated
>     (e) The return value from a method that just returned
>     (f) A caught exception
> 1. In a field of some object...
>     (a) A normal field
>     (b) An outer 'this' instance
>     (c) Other synthetic field (e.g., captured free variable)
> 1. As an element in a reference array
> 1. In native code as a native reference
> 
> Those are the only possibilities AFAIK.
> 
> So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try?
> 
> The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4.
> 
> So to think about the overall problem, imagine how you might or might not address all of those cases.

> * On the Java stack
>   (a) The current 'this' instance
>   (b) A method parameter
>   (c) A local variable
>   (d) A temporary value that is part of the current expression being evaluated
>   (e) The return value from a method that just returned
>   (f) A caught exception
> 
> * In a field of some object...
>   (a) A normal field
>   (b) An outer 'this' instance
>   (c) Other synthetic field (e.g., captured free variable)
> 
> * As an element in a reference array
> 
> * In native code as a native reference

Thanks for the classification. This is helpful.

I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)?

Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.

When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such).

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

PR: https://git.openjdk.org/jdk/pull/11874

From stsypanov at openjdk.org  Thu Jan 12 11:43:15 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 12 Jan 2023 11:43:15 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
Message-ID: <VMbNtYGyB7fkBUu5jVFELVWCIJP1ipmItNnJOwDyF8o=.9292e46a-18e9-4158-8e62-c239badffa3d@github.com>

On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

src/java.base/share/classes/java/util/Formatter.java line 4600:

> 4598:             // apply zero padding
> 4599:             if (width > sb.length() && Flags.contains(f, Flags.ZERO_PAD)) {
> 4600:                 String zeros = Character.toString(zero).repeat(width - sb.length());

`Character.toString(zero)` could be replaced with `String.valueOf(zero)` saving one more method call

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

PR: https://git.openjdk.org/jdk/pull/11939

From alanb at openjdk.org  Thu Jan 12 12:02:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jan 2023 12:02:16 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
Message-ID: <NjElCNLlfBvuykXSda2JEfElK3ihgOpMI27JkKhyhsE=.318a3d02-5dc2-4832-ba61-f20690b6c8ab@github.com>

On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

Thanks for expanding the tests for this.

test/jdk/java/util/Formatter/Padding.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @run junit Padding

Probably should add a @summary tag to this, maybe a @bug too (I think JDK-4906370 added Formatter in Java 5).

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11939

From ihse at openjdk.org  Thu Jan 12 12:16:18 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:16:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <M5rLDA8SccWTlvv2IaT5nm4enfgYICmjd5cUPWLh6rY=.1933b28a-5a2f-4507-8fda-a44728743516@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

FWIW, the make changes look good. I have nothing to say about the actual lint code itself.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11874

From lancea at openjdk.org  Thu Jan 12 12:25:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 12 Jan 2023 12:25:15 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
Message-ID: <Uz5hitmqqJOyBa4mykIW9V_xr6_jAOchKw8KE5S_Ngs=.cd7060f7-c485-415a-860b-fc9d94732f7f@github.com>

On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

Overall this looks OK.  

Please add either a general comment describing what we are trying to test or a comment for each test method.  As we add new tests,  adding comments for additional clarity will benefit future maintainers

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

PR: https://git.openjdk.org/jdk/pull/11939

From mcimadamore at openjdk.org  Thu Jan 12 12:31:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 12:31:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 163:

> 161:      *  invoked from the target constructor; if empty, we're still in the constructor.
> 162:      */
> 163:     private final ArrayDeque<DiagnosticPosition> callStack = new ArrayDeque<>();

There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things. Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175:

> 173:     private DiagnosticPosition[] pendingWarning;
> 174: 
> 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED

Watch out for "all caps"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:

> 216:         new TreeScanner() {
> 217: 
> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;

On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 220:

> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
> 219:             private JCClassDecl currentClass;
> 220:             private boolean privateOuter;

I don't think this is needed - see below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227:

> 225:                 final boolean privateOuterPrev = this.privateOuter;
> 226:                 final Lint lintPrev = this.lint;
> 227:                 this.lint = this.lint.augment(tree.sym);

general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 230:

> 228:                 try {
> 229:                     this.currentClass = tree;
> 230:                     this.privateOuter |= tree.sym.isAnonymous();

These can be inlined in the check below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270:

> 268:                     final boolean analyzable = this.currentClassIsExternallyExtendable() &&
> 269:                         TreeInfo.isConstructor(tree) &&
> 270:                         !tree.sym.isPrivate() &&

Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:

> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
> 294:                   !this.privateOuter;

Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304:

> 302: 
> 303:             // We are looking for analyzable constructors only
> 304:             final Symbol sym = entry.getKey();

This seems unused. And, if so, perhaps we only need a `Set<MethodInfo>`, not a map.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 348:

> 346:         final Comparator<DiagnosticPosition[]> ordering = (warning1, warning2) -> {
> 347:             for (int index1 = 0, index2 = 0; true; index1++, index2++) {
> 348:                 final boolean end1 = index1 >= warning1.length;

Another stylistic comment - the `final` here is not super helpful. The compiler performs effectively final analysis, so if your locals are only written once, you are good to go - and can even use them inside lambdas. From a documentation perspective it might carry a bit of value, but again, the rest of the javac code generally doesn't do that.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:

> 409:         final boolean referenceExpressionNode;
> 410:         switch (tree.getTag()) {
> 411:         case CASE:

surprised to see `CASE` here - as that's not an expression

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444:

> 442:         if (referenceExpressionNode) {
> 443: 
> 444:             // We treat instance methods as having a "value" equal to their instance

The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:

> 452: 
> 453:             // If the expression type is incompatible with 'this', discard it
> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))

Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 504:

> 502:         // Recurse on method expression
> 503:         this.scan(invoke.meth);
> 504:         final boolean direct = this.refs.remove(ExprRef.direct(this.depth));

Understanding checkpoint. Considering this code:


rec.m()

There are two cases:

* `rec` might be a direct reference to this (e.g. a local)
* `rec` might be an indirect reference to this (a lambda containing `this`)

So the receiver of the method might be direct or indirect. This will then determine how to interpret `this` in the context of that method analysis - e.g. when we see a `JCIdent` for `this`, we create a direct/indirect `ExprRef` based on what the receiver kind was. Correct?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817:

> 815:         // Methods - the "value" of a non-static method is a reference to its instance
> 816:         final Symbol sym = tree.sym;
> 817:         if (sym.kind == MTH) {

This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:

> 873:         // Reference to this?
> 874:         if (tree.name == names._this || tree.name == names._super) {
> 875:             if (this.refs.contains(ThisRef.direct()))

This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900:

> 898:             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
> 899:             final Type methodOwnerType = sym.owner.type;
> 900:             if (this.isSubtype(currentClassType, methodOwnerType)) {

I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:

> 907: 
> 908:             // Check for implicit outer 'this' reference
> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {

Similarly here - look for `Symbol.isEnclosedBy`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1302:

> 1300:      *  In other words, a reference that's sitting on top of the stack.
> 1301:      */
> 1302:     private static class ExprRef extends Ref {

Maybe I'm wrong - but it seems that the only thing we need to track is whether the top of stack (e.g. last evaluated expression) has a direct reference or indirect reference (or none). Do we really need a set for this? (this seems the same as for ThisRef which is used inside method, which can be one of the same three options). While I do see value for tracking which variables are aliases for this (either direct or indirect), it seems like (at least on a superficial look) that expression refs might be replaced by a visitor field/parameter.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1319:

> 1317:     /** A reference from the return value of the current method being "invoked".
> 1318:      */
> 1319:     private static class ReturnRef extends Ref {

Isn't this just an ExprRef? This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

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

PR: https://git.openjdk.org/jdk/pull/11874

From lancea at openjdk.org  Thu Jan 12 12:37:23 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 12 Jan 2023 12:37:23 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
Message-ID: <e4mJmYtaHqfsbAV9BmmBhbQO54CG5Ii-F9dQtmsZGn4=.cdcd29f2-5a87-4789-8493-f13850a80f19@github.com>

On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

test/jdk/java/util/Formatter/Padding.java line 39:

> 37:     class BlankPaddingInt {
> 38: 
> 39:         @Test

Any thought given to using `@MethodSource:` in order to specify a DataProvider? The benefit would be you could catch each failure vs having to address or comment out the assertEquals that is failing

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

PR: https://git.openjdk.org/jdk/pull/11939

From ihse at openjdk.org  Thu Jan 12 12:39:17 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:39:17 GMT
Subject: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]
In-Reply-To: <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
 <sXqsKus-IeF9_9SWAYfuPYp6eqhcIipyX0ddU5lKahQ=.af523391-7b13-41da-abc0-1de5b0a596b9@github.com>
Message-ID: <6XxvrcE23qr4562RGMkFlLgHBdGjGpavFWr6QnGBfDk=.02c5b35c-c540-41da-9ba1-451dac0e1713@github.com>

On Sat, 17 Dec 2022 06:39:48 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete unintended addition of files from previous commit
>   
>   Signed-off-by: Justin King <jcking at google.com>

Marked as reviewed by ihse (Reviewer).

Hi, back from vacation today. Thanks for waiting on my input! This looks good.

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

PR: https://git.openjdk.org/jdk/pull/11604

From ihse at openjdk.org  Thu Jan 12 12:50:20 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:50:20 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v7]
In-Reply-To: <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
Message-ID: <KxjDVaJU_aX3HL9SRr39iw-hBLrlNzq8pLUP_7Yad7I=.c6b0c338-669a-481c-af66-2cc4899cf3a0@github.com>

On Fri, 16 Dec 2022 18:22:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removal of Preview.java and TransPatterns.java patch
>    and enabled preview for java.base
>  - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview

make/modules/java.base/Java.gmk line 28:

> 26: DOCLINT += -Xdoclint:all/protected \
> 27:     '-Xdoclint/package:java.*,javax.*'
> 28: JAVAC_FLAGS += -XDstringConcat=inline

I think it makes more sense to just have a single `JAVAC_FLAGS` assignment line, not one per flag.

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

PR: https://git.openjdk.org/jdk/pull/10982

From ihse at openjdk.org  Thu Jan 12 12:53:17 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Jan 2023 12:53:17 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v7]
In-Reply-To: <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
Message-ID: <TsrfOjqpYAQwypilpIHVQXzRx1h5ywDEO5ZJUjk8p7w=.5f01f55e-16f4-4499-93e3-8852391bcebe@github.com>

On Fri, 16 Dec 2022 18:22:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removal of Preview.java and TransPatterns.java patch
>    and enabled preview for java.base
>  - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview

make/modules/java.base/Java.gmk line 39:

> 37: 
> 38: EXCLUDES += java/lang/doc-files
> 39: EXCLUDES += jdk/classfile/snippet-files

... and the same goes for the `EXCLUDES`. If the line gets longer than 80 chars, split it like the `COPY` line above.

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

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Jan 12 13:04:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 13:04:18 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334:

> 332:         // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor
> 333:         // Foo() invokes this(0), then emitting a warning for Foo() would be redundant.
> 334:         final BiPredicate<DiagnosticPosition[], DiagnosticPosition[]> extendsAsPrefix = (warning1, warning2) -> {

Another strategy would be to give a single warning per leaking constructor.

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

PR: https://git.openjdk.org/jdk/pull/11874

From redestad at openjdk.org  Thu Jan 12 13:43:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Jan 2023 13:43:22 GMT
Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers
In-Reply-To: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
References: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
Message-ID: <tmZ-96IKR7M12oqVR-71zzgMHkPIuI4ChDBKytKBfYc=.ad5b31fe-b485-4b19-af67-35f4dcbfdae4@github.com>

On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.

Thanks for reviewing!

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

PR: https://git.openjdk.org/jdk/pull/11949

From redestad at openjdk.org  Thu Jan 12 13:43:23 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Jan 2023 13:43:23 GMT
Subject: Integrated: 8299978: Remove MethodHandleNatives.getMembers
In-Reply-To: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
References: <EFKAgiR5pR50nK98-ap05-SRI6X2QyDKmMZKgqX42wU=.57e5fc07-6e3a-4d66-b417-180f16e1dd63@github.com>
Message-ID: <kyC9zYzQm-Un3Zg46t8_9EhobDDT2ys2kWnreWrppBE=.9918e93b-0418-436b-a21a-94ae81afd631@github.com>

On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.

This pull request has now been integrated.

Changeset: 48c8fb39
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48c8fb39a74f07335d366a0a3052e3c00634d869
Stats:     172 lines in 4 files changed: 0 ins; 171 del; 1 mod

8299978: Remove MethodHandleNatives.getMembers

Reviewed-by: jvernee, mchung

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

PR: https://git.openjdk.org/jdk/pull/11949

From rriggs at openjdk.org  Thu Jan 12 14:58:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Jan 2023 14:58:31 GMT
Subject: [jdk20] Integrated: 8299034: Runtime::exec clarification of inherited
 environment
In-Reply-To: <ts0MSciQEQD5B0ElmI-KXdomAAA6O1UEHAASuqE_P6Q=.ebf4f0da-cdbf-4bdd-9002-e488edbee311@github.com>
References: <ts0MSciQEQD5B0ElmI-KXdomAAA6O1UEHAASuqE_P6Q=.ebf4f0da-cdbf-4bdd-9002-e488edbee311@github.com>
Message-ID: <bXOtDvVOrv2iALVEtkKBSmdAcO0d6nFe8xBab2S9nEM=.f43753e8-c854-4045-823d-4d4e52d7bbeb@github.com>

On Wed, 11 Jan 2023 18:31:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The current description of Runtime.exec, ProcessBuilder.start, and ProcessBuilder.startPipeline identifies a minimum set of system dependent environment variables needed to launch a process and allows additional system dependent environment variables to be present in the child. However, it does not acknowledge that the parent's values of the minimum set of system dependent variables may not be appropriate for the child.
> 
> The description of the minimum set of system dependent environment variables is extended to allow the parent's values of those environment variables to be overridden in the child.

This pull request has now been integrated.

Changeset: 6a4a8743
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/6a4a8743562bd8f937542cdeb6557b3fe60e9a23
Stats:     6 lines in 2 files changed: 6 ins; 0 del; 0 mod

8299034: Runtime::exec clarification of inherited environment

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk20/pull/98

From duke at openjdk.org  Thu Jan 12 15:02:22 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:02:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
Message-ID: <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>

On Thu, 12 Jan 2023 09:57:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)?

Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. 

An example of how this could happen would be:

public class ThrownThis extends RuntimeException {

    public ThrownThis(Object obj) {
        try {
            this.validate(obj);
        } catch (RuntimeException e) {
            e.mightLeak();  // LEAK HERE
        }
    }

    private void validate(Object obj) {
        if (obj.hashCode() != 123)
            throw this;
    }

    public void mightLeak() {
    }
}

Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.

Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.

As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!

> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.

Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 15:12:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 15:12:56 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
 <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
Message-ID: <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>

On Thu, 12 Jan 2023 14:59:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> * On the Java stack
>>>   (a) The current 'this' instance
>>>   (b) A method parameter
>>>   (c) A local variable
>>>   (d) A temporary value that is part of the current expression being evaluated
>>>   (e) The return value from a method that just returned
>>>   (f) A caught exception
>>> 
>>> * In a field of some object...
>>>   (a) A normal field
>>>   (b) An outer 'this' instance
>>>   (c) Other synthetic field (e.g., captured free variable)
>>> 
>>> * As an element in a reference array
>>> 
>>> * In native code as a native reference
>> 
>> Thanks for the classification. This is helpful.
>> 
>> I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)?
>> 
>> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
>> 
>> When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such).
>
>> I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)?
> 
> Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. 
> 
> An example of how this could happen would be:
> 
> public class ThrownThis extends RuntimeException {
> 
>     public ThrownThis(Object obj) {
>         try {
>             this.validate(obj);
>         } catch (RuntimeException e) {
>             e.mightLeak();  // LEAK HERE
>         }
>     }
> 
>     private void validate(Object obj) {
>         if (obj.hashCode() != 123)
>             throw this;
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.
> 
> Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.
> 
> As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!
> 
>> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
> 
> Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

> Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it.
> 
> An example of how this could happen would be:
> 
> ```java
> public class ThrownThis extends RuntimeException {
> 
>     public ThrownThis(Object obj) {
>         try {
>             this.validate(obj);
>         } catch (RuntimeException e) {
>             e.mightLeak();  // LEAK HERE
>         }
>     }
> 
>     private void validate(Object obj) {
>         if (obj.hashCode() != 123)
>             throw this;
>     }
> 
>     public void mightLeak() {
>     }
> }
> ```
> 
Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception.

Question - shouldn't we conclude that `this` leak when we see `throw this` ? E.g. what if the constructor did not have a `catch` (or if the catch was of a different type) ?
> Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible.
> 
> Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble.
> 
> As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss!
> 
> > Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies.
> 
> Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 15:19:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:19:44 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <PWUpnB72y0RJmSv_2fTWPwtHxWfD_vbDK0Xo96H8cWo=.4e62955d-7a89-4f8f-9032-42cba96a8628@github.com>
Message-ID: <i7A6Abb4ofaGhdVFwfMMRfnW3m6sxTj7NovAlduTbm0=.1e93c191-bafa-4b37-9ec4-12e6532a745c@github.com>

On Thu, 12 Jan 2023 13:01:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334:
> 
>> 332:         // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor
>> 333:         // Foo() invokes this(0), then emitting a warning for Foo() would be redundant.
>> 334:         final BiPredicate<DiagnosticPosition[], DiagnosticPosition[]> extendsAsPrefix = (warning1, warning2) -> {
> 
> Another strategy would be to give a single warning per leaking constructor.

We already impose a limit of at most one warning per constructor.

But for this limit what is technically meant by "per constructor" is "At most one warning per constructor, assuming that constructor is the one being analyzed (i.e., the one invoked by the subclass and not via `this()`)."

So that limitation doesn't stop a constructor from generating the same warning multiple times due to it being invoked indirectly by other constructors via `this()`. Those duplicate warnings are what the code above eliminates.

So this code only generates one warning, and it's reported for the second constructor:

public class DupWarn1 {

    public DupWarn1() {
        this(0);
    }

    public DupWarn1(int x) {
        this.mightLeak();
    }

    public void mightLeak() {
    }
}

DupWarn1.java:8: warning: [this-escape] possible 'this' escape before subclass is fully initialized
        this.mightLeak();
                      ^

This is appropriate. The leak is really in the second constructor; the first constructor has nothing to do with it. Reporting a leak for both constructors would be redundant.

An interesting side question: Is it possible to come up with an example where constructor A has a 'this' leak, and some other constructor B invokes `this()` to delegate to A, but when B delegates to A the leak occurs differently, or not at all?

Because of the "flood" analysis, and the fact that you can't pass 'this' references to `this()` or `super()` (these are static contexts), I don't think it's possible.

So in fact the deduplication will always apply whenever `this()` is involved.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 15:29:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 15:29:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v5]
In-Reply-To: <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com>
 <MT9d3Bc2PtEsXrSfNpKY81udhQFt2v7kpuozhdJaOAk=.f3fd2c30-3d34-4019-8e30-f6d4c83ff505@github.com>
 <HTwpvhqSRv7eZY_rWOoTLKadDGSyhE_O3NOwbfwBISI=.622357d4-a738-4d02-a9dd-085a1594865c@github.com>
 <CqVrTNenQADAVd-0J3CNaGze8JROSYlwWgSfU185wWA=.5f296496-de6e-466b-b349-c50e11e8571c@github.com>
 <uWpRvvhg7NoJgZBNfN1MZKWzqmZghtLRcHomu1_m2aY=.2dd7002f-a0de-4cf6-ac6f-bdd66a1274bd@github.com>
 <Xfu3oB46y3mnUo7pzzEQ2OBjI5j6681sepVhoww7-sY=.366a8d34-6c0a-4c43-93eb-1af13826ade0@github.com>
 <z6eLSSNdqo0xSBeEVwlXtXRpdKtv4xy6HdaGe0o_Buo=.378b082d-7f91-4839-8598-5310ffd4feba@github.com>
 <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com>
 <ZD_nNF2a-fVIa8TFkMz1IzUp-sQiNPCdDDQATtITuNg=.8cbd8a86-3827-41cc-809d-47aec2efea8b@github.com>
 <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI
 FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com>
 <AThOSlZGTaIj7ogPCa3JY4TmP1CEIwD67Z9xKxhfk9E=.4c13c2b7-98d2-4815-a804-8b90cf83a489@github.com>
 <BEEj6RKWYNwjEEJ2s6db7O6ih65YUwJuPgMMNffg93Y=.25db64c4-ecdb-44b1-be12-7cf21376bc1b@github.com>
 <Z1YrthZISaALPMxL1F5GnGEdE7xgmw1cUY-O4ogt1DQ=.3c8554be-1739-4a1a-b4f5-4bde0e0c1a2b@github.com>
 <NsEcde65vTzRWfOo9UVogBDQNaoKIRnguLx3Y2IN2a4=.8005b605-5aa6-42b3-b4f7-9396a98081cf@github.com>
 <Cq9llhpGlvwFe1IYfakr-bd1POmSCTDfQ1kPFeTJQVI=.9048fd23-9fff-4941-8d51-e249f920783f@github.com>
 <Y1uRe5qwe5DMX5bi82veVOrQnP4JcLL94ZYLInWq9Is=.7973d572-e8ee-4b6c-bdd6-6ff9a488231a@github.com>
 <G-1dQGlxNC0tMTi8ScMEdlxRBaK1ghCnUZw0X88GkiA=.748a82f4-8848-49cb-b6dc-54ebb30caa7e@github.com>
Message-ID: <Tppxs2q5PpvfPZpAwGXNJHXLoXvsF5sgr2__feG7tsM=.37059060-38f7-4e0e-8c27-58a7b7d586d4@github.com>

On Thu, 12 Jan 2023 15:10:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception.

Yes - although that example doesn't compile (oops!). Just replace `catch (RuntimeException e)` with `catch (ThrownThis e)` and it should.

> Question - shouldn't we conclude that this leak when we see throw this ? E.g. what if the constructor did not have a catch (or if the catch was of a different type) ?

A thorough analysis would evaluate whether the exception was caught or not. But you're right - since we're not doing a thorough analysis, we should immediately declare a leak anytime we see `throw x` where `x` is a possible direct or indirect reference. Of course, this scenario should be unlikely in normal code.

I will add a check for that.

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

PR: https://git.openjdk.org/jdk/pull/11874

From rgiulietti at openjdk.org  Thu Jan 12 15:31:03 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Jan 2023 15:31:03 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v5]
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

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

  8299677: Formatter.format might take a long time to format an integer or floating-point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11939/files
  - new: https://git.openjdk.org/jdk/pull/11939/files/275582a9..56c8f550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11939&range=03-04

  Stats: 382 lines in 2 files changed: 57 ins; 106 del; 219 mod
  Patch: https://git.openjdk.org/jdk/pull/11939.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11939/head:pull/11939

PR: https://git.openjdk.org/jdk/pull/11939

From rgiulietti at openjdk.org  Thu Jan 12 15:32:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Jan 2023 15:32:21 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
Message-ID: <xbGVqN2NsonSqbxCCEfU4hgFAMPg4BUJO2d7AdYrDpE=.6ab34db4-62e1-458f-ae61-1bbe0c7102ea@github.com>

On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

All concerns were addressed, I hope.

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

PR: https://git.openjdk.org/jdk/pull/11939

From jcking at openjdk.org  Thu Jan 12 15:53:29 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 12 Jan 2023 15:53:29 GMT
Subject: Integrated: JDK-8298448: UndefinedBehaviorSanitizer
In-Reply-To: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
References: <Zefs0uFQKpD2-WZJ0ukOW-0ytJ5y1kGnuOtJTVImOLM=.5c20bf55-c2fe-47bc-9f41-ab2d693a4545@github.com>
Message-ID: <3tusl2zauf-vf5mQInQFrqKgrYNizNK38xe_vUNMW3U=.e0775b27-1c7c-4645-86bb-47fcc8f73983@github.com>

On Fri, 9 Dec 2022 06:53:31 GMT, Justin King <jcking at openjdk.org> wrote:

> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.

This pull request has now been integrated.

Changeset: 7a85d95e
Author:    Justin King <jcking at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a85d95e828283d57e1df0344be454626470675d
Stats:     114 lines in 6 files changed: 108 ins; 1 del; 5 mod

8298448: UndefinedBehaviorSanitizer

Reviewed-by: erikj, ihse

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

PR: https://git.openjdk.org/jdk/pull/11604

From duke at openjdk.org  Thu Jan 12 16:06:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:06:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <nAV8hmaFOM_k77iuhmz3YoAd88Qq0pwb1YFInECVrWU=.fd7105ab-2c10-4372-a18b-daf13e1b0891@github.com>

On Thu, 12 Jan 2023 10:18:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:
> 
>> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
>> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
>> 294:                   !this.privateOuter;
> 
> Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe

Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class.

Example:

$ cat PrivateOuter.java 
public class PrivateOuter {
    private static class Inner1 {
        static class Inner2 {
        }
    }
}
$ javap -v PrivateOuter$Inner1$Inner2
Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class
  Last modified Jan 12, 2023; size 408 bytes
  SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c
  Compiled from "PrivateOuter.java"
class PrivateOuter$Inner1$Inner2
  minor version: 0
  major version: 63
  flags: (0x0020) ACC_SUPER
  this_class: #7                          // PrivateOuter$Inner1$Inner2
  super_class: #2                         // java/lang/Object
  ...


So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 16:24:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:24:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>

On Thu, 12 Jan 2023 10:25:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:
> 
>> 216:         new TreeScanner() {
>> 217: 
>> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
> 
> On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.

Two things...

We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing.

For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove.

But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation.

I will make these updates.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304:
> 
>> 302: 
>> 303:             // We are looking for analyzable constructors only
>> 304:             final Symbol sym = entry.getKey();
> 
> This seems unused. And, if so, perhaps we only need a `Set<MethodInfo>`, not a map.

Thanks, you're right, the map keys are not used here. I'll clean up the loop.

But we still need a map, not a set, because the map is used elsewhere.

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

PR: https://git.openjdk.org/jdk/pull/11874

From stsypanov at openjdk.org  Thu Jan 12 16:28:13 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 12 Jan 2023 16:28:13 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v5]
In-Reply-To: <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
Message-ID: <jFYKB8q_Clno9ZbyMf9Pwie5ZX1SXHdRdWggOXZMcL0=.de011036-5495-4a3b-aaa6-e1f3cb41bdf8@github.com>

On Thu, 12 Jan 2023 15:31:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

Marked as reviewed by stsypanov (Author).

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

PR: https://git.openjdk.org/jdk/pull/11939

From duke at openjdk.org  Thu Jan 12 16:31:21 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:31:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <ELxQd5w_bHMh8ktW6Ce_gtGB8oMhpxruvG8MffRhEp4=.de3c9800-c167-4c16-ac93-7267cb3619d0@github.com>

On Thu, 12 Jan 2023 10:32:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect?

A static factory method will not create a subclassed instance, so there's no 'this' escape problem.

But I admit I completely missed factory methods as a potential thing to worry about.

Is it possible for a leak to be missed due to the use of a factory method?

Hmm. I can't immediately think of how, but if you can come up with an example please share.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 16:46:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 16:46:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
Message-ID: <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>

On Thu, 12 Jan 2023 16:20:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218:
>> 
>>> 216:         new TreeScanner() {
>>> 217: 
>>> 218:             private Lint lint = ThisEscapeAnalyzer.this.lint;
>> 
>> On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider.
>
> Two things...
> 
> We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing.
> 
> For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove.
> 
> But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation.
> 
> I will make these updates.

Yep - I guess there's a general theme of "where do we want the warnings to be reported". My general feeling is that reporting a warning on the constructor might be enough - but I see that you try to generate a warning in the exact spot where the leakage happens - which I'm not sure if it's ok, or too clever.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270:
>> 
>>> 268:                     final boolean analyzable = this.currentClassIsExternallyExtendable() &&
>>> 269:                         TreeInfo.isConstructor(tree) &&
>>> 270:                         !tree.sym.isPrivate() &&
>> 
>> Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect?
>
>> If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect?
> 
> A static factory method will not create a subclassed instance, so there's no 'this' escape problem.
> 
> But I admit I completely missed factory methods as a potential thing to worry about.
> 
> Is it possible for a leak to be missed due to the use of a factory method?
> 
> Hmm. I can't immediately think of how, but if you can come up with an example please share.

I guess what I'm thinking about:

class Foo {
    private Foo() {
        m(this);
    }
    
    public void m() { ... } // overridable
    
    static Foo makeFoo() { return new Foo(); }
}

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294:
>> 
>>> 292:                   !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) &&
>>> 293:                   !(this.currentClass.sym.owner.kind == MTH) &&
>>> 294:                   !this.privateOuter;
>> 
>> Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe
>
> Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class.
> 
> Example:
> 
> $ cat PrivateOuter.java 
> public class PrivateOuter {
>     private static class Inner1 {
>         static class Inner2 {
>         }
>     }
> }
> $ javap -v PrivateOuter$Inner1$Inner2
> Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class
>   Last modified Jan 12, 2023; size 408 bytes
>   SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c
>   Compiled from "PrivateOuter.java"
> class PrivateOuter$Inner1$Inner2
>   minor version: 0
>   major version: 63
>   flags: (0x0020) ACC_SUPER
>   this_class: #7                          // PrivateOuter$Inner1$Inner2
>   super_class: #2                         // java/lang/Object
>   ...
> 
> 
> So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for.

D'oh - missed the `|=` - so this keeps updating...

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 16:55:39 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 16:55:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <mYo4j7HX3pMUvpNwVh0Ym-_ZCS39PYrnRP7iP68PmRo=.77ca8af4-38ed-424f-990e-52e3f6ed33f2@github.com>

On Thu, 12 Jan 2023 10:48:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227:
> 
>> 225:                 final boolean privateOuterPrev = this.privateOuter;
>> 226:                 final Lint lintPrev = this.lint;
>> 227:                 this.lint = this.lint.augment(tree.sym);
> 
> general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz`

OK. I will reluctantly remove...

`<PointlessRantDoNotRead>`
> Why on earth wouldn't you want to make it clear which one of N outer classes a field comes from, and that it's a field, and not a variable declared somewhere off screen??
> 
> IMHO omitting 'this' qualifiers is effectively accepting the grave offense of code obfuscation in exchange for a tiny smidgen of brevity.
>
> It's definitely made it harder for me to read and understand the compiler, with all the levels of nesting it has.
> 
`</PointlessRantDoNotRead>`

I readily admit I'm probably in the minority on this and anyway it's a bikeshed thing so there's no point in debating it.

I will go with the flow :) though I feel a little sorry for the next person who has to read this code.

> From a documentation perspective it might carry a bit of value

Yes, that's the purpose - the `final` is for the human viewer, not the compiler. Just trying to be helpful to the next person.

But you're right it's inconsistent so I'll remove.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 17:16:34 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:16:34 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>

On Thu, 12 Jan 2023 10:56:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:
> 
>> 409:         final boolean referenceExpressionNode;
>> 410:         switch (tree.getTag()) {
>> 411:         case CASE:
> 
> surprised to see `CASE` here - as that's not an expression

I put it there because of switch expressions and `yeild`... ?

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

PR: https://git.openjdk.org/jdk/pull/11874

From naoto at openjdk.org  Thu Jan 12 17:19:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jan 2023 17:19:33 GMT
Subject: RFR: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows
Message-ID: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>

Fixing a regression caused by the fix to [JDK-8298971](https://bugs.openjdk.org/browse/JDK-8298971). The previous fix lacked the native part change on Windows.

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

Commit messages:
 - 8300010: UnsatisfiedLinkError on calling System.console().readPassword() on Windows

Changes: https://git.openjdk.org/jdk/pull/11973/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11973&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300010
  Stats: 81 lines in 2 files changed: 55 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11973.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11973/head:pull/11973

PR: https://git.openjdk.org/jdk/pull/11973

From mcimadamore at openjdk.org  Thu Jan 12 17:43:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 17:43:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
Message-ID: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>

On Thu, 12 Jan 2023 17:13:55 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411:
>> 
>>> 409:         final boolean referenceExpressionNode;
>>> 410:         switch (tree.getTag()) {
>>> 411:         case CASE:
>> 
>> surprised to see `CASE` here - as that's not an expression
>
> I put it there because of switch expressions and `yeild`... ?

Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE?

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:
>> 
>>> 452: 
>>> 453:             // If the expression type is incompatible with 'this', discard it
>>> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
>> 
>> Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?
>
> No because (for example) what if you cast?
> 
> The thing you're casting might be compatible, but after the cast it might become incompatible.

Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy:


interface A { }
class B {
     B() {
          A a = (A)this;
          ...
      }
 }
 class C extends B implements A { }
 ```

Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).

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

PR: https://git.openjdk.org/jdk/pull/11874

From vromero at openjdk.org  Thu Jan 12 17:43:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Jan 2023 17:43:26 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
Message-ID: <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>

On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use the more appropriate Type comparison method Types.isSameType().
>  - Add some more comments to clarify how the analysis works.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200:

> 198: //
> 199: 
> 200:     public void analyzeTree(Env<AttrContext> env) {

nit: this method could be removed in favor of the overloaded version below

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204:

> 202:     }
> 203: 
> 204:     public void analyzeTree(Env<AttrContext> env, JCTree tree) {

nit: `env` parameter doesn't seem to be used could be dropped I think

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 17:43:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:43:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>

On Thu, 12 Jan 2023 11:09:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444:
> 
>> 442:         if (referenceExpressionNode) {
>> 443: 
>> 444:             // We treat instance methods as having a "value" equal to their instance
> 
> The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined"

Agreed - will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454:
> 
>> 452: 
>> 453:             // If the expression type is incompatible with 'this', discard it
>> 454:             if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
> 
> Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch?

No because (for example) what if you cast?

The thing you're casting might be compatible, but after the cast it might become incompatible.

> This will then determine how to interpret this in the context of that method analysis - e.g. when we see a JCIdent for this, we create a direct/indirect ExprRef based on what the receiver kind was. Correct?

Yes, exactly.

When we "invoke" a method, we "preload" the set of current references that the method is going to have when it starts. That "preload" step includes any references from (a) the method receiver (non-static methods only) and (b) method parameters.

To the extent the method receiver has a direct/indirect reference, that turns into a direct/indirect `ThisRef` during method execution. You can see this happen in the very next lines after what you quoted. But of course the method invocation (the "apply") could have been applied to any arbitrary expression as the receiver.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817:
> 
>> 815:         // Methods - the "value" of a non-static method is a reference to its instance
>> 816:         final Symbol sym = tree.sym;
>> 817:         if (sym.kind == MTH) {
> 
> This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it.

Yes but see previous comment regarding casting.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:
> 
>> 873:         // Reference to this?
>> 874:         if (tree.name == names._this || tree.name == names._super) {
>> 875:             if (this.refs.contains(ThisRef.direct()))
> 
> This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).

The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.

When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.

In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).

Regarding the optimization you mention, in light of the above I'm not sure it would still work.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 17:53:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 17:53:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>

On Thu, 12 Jan 2023 12:15:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175:
> 
>> 173:     private DiagnosticPosition[] pendingWarning;
>> 174: 
>> 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED
> 
> Watch out for "all caps"

Will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900:
> 
>> 898:             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>> 899:             final Type methodOwnerType = sym.owner.type;
>> 900:             if (this.isSubtype(currentClassType, methodOwnerType)) {
> 
> I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass`

Hmm, I tried using `Symbol.isSubclass()` but it caused test failures. Obviously I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:
> 
>> 907: 
>> 908:             // Check for implicit outer 'this' reference
>> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
> 
> Similarly here - look for `Symbol.isEnclosedBy`

Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 18:00:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:00:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <fgNy_jMv_g-0_VgfhgCf2JVUJjfCoqum2cmC55cRwFQ=.d1dbfa25-3790-48e0-bbd0-e4a5af2d8ed8@github.com>

On Thu, 12 Jan 2023 12:17:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things.

I think that would be more confusing, because they're really two different animals.

Scopes only have meaning within a single method. They simply serve to bracket the lifetimes of `VarRef` references, following Java curly brace scope. When you "invoke" a method, you put aside the current stack of scopes and start over with an empty scope stack. They don't bridge between methods.

Call stacks are just a list of method+code position therein, and they exist outside of any single method. They have nothing to do with Java scopes defined by curly braces.

> Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears.

That's another way to skin the same cat... in fact I had a design like that before but then realized it was a lot simpler to just carry around one `RefSet`.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 18:09:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:09:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <tHD8s5avHxuK-kI1PNds3iq8b29x0QuOkQiz1Brxtq0=.6d21f5e2-8866-43fb-92eb-155d2f2ca58b@github.com>

On Thu, 12 Jan 2023 12:26:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Do we really need a set for this?

There are surely other ways to model things. But I got myself really confused trying to build more complicated models.

What I ended up with is this simple model that works:
* There is a set of `Ref` subclasses that model the various types of 'this' references possible: `OuterRef`, `ExprRef`, etc.
* There is a singleton `this.refs`, which just is a `Set<Ref>`, containing the 'this' references that are alive at the current moment
* As we "execute" code, all we need to do is update the `this.refs` based on what the current bit of code does

E.g....

When a variable is assigned a value that has a reference, we add a `VarRef` for that variable.

When we leave a scope, we remove any `Ref`'s that are no longer in scope.

Before executing a method, we add `Ref`'s for the method receiver and parameter.

When we return from a non-void method, we convert any `ReturnRef` into a `ExprRef`.

Etc.

THAT I can understand.

I don't see converting the above into a bitmap or whatever as worth the additional complexity. We're not programming in perl here.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 18:16:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:16:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <JQTEa2D1hzzMeKiAytv_7Qf16MMo4lNHl8VrmbX_V4o=.2d76542b-9bc3-42ef-a466-0cf5e8533028@github.com>
Message-ID: <1r69eKftXv6ZlGQP76mNrfgbldbDcMxhnyVOQ8oUV7U=.8facaf51-1f7e-486a-912e-a9a5912b7d88@github.com>

On Thu, 12 Jan 2023 17:39:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use the more appropriate Type comparison method Types.isSameType().
>>  - Add some more comments to clarify how the analysis works.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200:
> 
>> 198: //
>> 199: 
>> 200:     public void analyzeTree(Env<AttrContext> env) {
> 
> nit: this method could be removed in favor of the overloaded version below

Thanks - will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204:
> 
>> 202:     }
>> 203: 
>> 204:     public void analyzeTree(Env<AttrContext> env, JCTree tree) {
> 
> nit: `env` parameter doesn't seem to be used could be dropped I think

Thanks - will fix.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 18:16:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:16:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
Message-ID: <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>

On Thu, 12 Jan 2023 17:48:37 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909:
>> 
>>> 907: 
>>> 908:             // Check for implicit outer 'this' reference
>>> 909:             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>> 
>> Similarly here - look for `Symbol.isEnclosedBy`
>
> Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?

I can't seem to be able to run tests - I get failures in the build:


* For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 18:16:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:16:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
Message-ID: <DwYRtG4qsOtzZBk93m54shMuGu2slfVgQD_DTz-XHXk=.84e50496-fcc5-43f6-92fa-590d458a40cd@github.com>

On Thu, 12 Jan 2023 12:28:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

Yes, a method return value that represents a reference is an `ExprRef` just before the `return` is actually executed, but then it turns into a `ReturnRef`.

A `ReturnRef` is really just a yellow sticky note that reminds us "Hey whenever you finish 'executing' this method, remember that there is a reference in its return value".

> This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth).

Exactly.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 18:21:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:21:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
Message-ID: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>

On Thu, 12 Jan 2023 18:11:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch?
>
> I can't seem to be able to run tests - I get failures in the build:
> 
> 
> * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:

This patch:


diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
index 1c89328a388..7c3f0293edc 100644
--- a/make/test/BuildMicrobenchmark.gmk
+++ b/make/test/BuildMicrobenchmark.gmk
@@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
     TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
     SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
     INCLUDE_FILES := indify/Indify.java, \
-    DISABLED_WARNINGS := rawtypes serial options, \
+    DISABLED_WARNINGS := this-escape rawtypes serial options, \
     BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
     JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
 ))
@@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
     TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
     SMALL_JAVA := false, \
     CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
-    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
+    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
     SRC := $(MICROBENCHMARK_SRC), \
     BIN := $(MICROBENCHMARK_CLASSES), \
     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index 9d35c2fbc0a..4e2b1e558e7 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             // Check for implicit 'this' reference
             final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
             final Type methodOwnerType = sym.owner.type;
+            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
             if (this.isSubtype(currentClassType, methodOwnerType)) {
                 if (this.refs.contains(ThisRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
@@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // Check for implicit outer 'this' reference
+            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
             if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));


Fixes the build failure.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 18:40:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 18:40:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
Message-ID: <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>

On Thu, 12 Jan 2023 16:40:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I guess what I'm thinking about:

No leak is possible in that example.
* `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
* Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 18:43:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:43:21 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
Message-ID: <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>

On Thu, 12 Jan 2023 18:18:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I can't seem to be able to run tests - I get failures in the build:
>> 
>> 
>> * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch:
>
> This patch:
> 
> 
> diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
> index 1c89328a388..7c3f0293edc 100644
> --- a/make/test/BuildMicrobenchmark.gmk
> +++ b/make/test/BuildMicrobenchmark.gmk
> @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
>      TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
>      SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
>      INCLUDE_FILES := indify/Indify.java, \
> -    DISABLED_WARNINGS := rawtypes serial options, \
> +    DISABLED_WARNINGS := this-escape rawtypes serial options, \
>      BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
>      JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
>  ))
> @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
>      TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>      SMALL_JAVA := false, \
>      CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
> -    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
> +    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
>      SRC := $(MICROBENCHMARK_SRC), \
>      BIN := $(MICROBENCHMARK_CLASSES), \
>      JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> index 9d35c2fbc0a..4e2b1e558e7 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              // Check for implicit 'this' reference
>              final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>              final Type methodOwnerType = sym.owner.type;
> +            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
>              if (this.isSubtype(currentClassType, methodOwnerType)) {
>                  if (this.refs.contains(ThisRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // Check for implicit outer 'this' reference
> +            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
>              if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> 
> 
> Fixes the build failure.

This patch passes all tests:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index 9d35c2fbc0a..e755c54d0c8 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // If the expression type is incompatible with 'this', discard it
-            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
+            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
                 this.refs.remove(ExprRef.direct(this.depth));
         }
     }
@@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
         if (explicitOuterThis != null) {
             this.scan(explicitOuterThis);
             this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
-        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
+        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
             if (this.refs.contains(ThisRef.direct()))
                 outerRefs.add(OuterRef.direct());
             if (this.refs.contains(ThisRef.indirect()))
@@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
         // Explicit outer 'this' reference?
         final Type selectedType = this.types.erasure(tree.selected.type);
         if (selectedType.hasTag(CLASS)) {
-            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
             if (tree.name == this.names._this &&
-                this.types.hasOuterClass(currentClassType, selectedClassType)) {
+                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
                 if (this.refs.contains(OuterRef.indirect()))
@@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             final MethodSymbol sym = (MethodSymbol)tree.sym;
 
             // Check for implicit 'this' reference
-            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
-            final Type methodOwnerType = sym.owner.type;
-            if (this.isSubtype(currentClassType, methodOwnerType)) {
+            if (methodClass.sym.isSubClass(sym.owner, types)) {
                 if (this.refs.contains(ThisRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));
                 if (this.refs.contains(ThisRef.indirect()))
@@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
             }
 
             // Check for implicit outer 'this' reference
-            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
+            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
                 if (this.refs.contains(OuterRef.direct()))
                     this.refs.add(ExprRef.direct(this.depth));


Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 

Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 18:51:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 18:51:33 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
Message-ID: <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>

On Thu, 12 Jan 2023 18:37:06 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I guess what I'm thinking about:
>> 
>> class Foo {
>>     private Foo() {
>>         m(this);
>>     }
>>     
>>     public void m() { ... } // overridable
>>     
>>     static Foo makeFoo() { return new Foo(); }
>> }
>
>> I guess what I'm thinking about:
> 
> No leak is possible in that example.
> * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
> * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private

but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?

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

PR: https://git.openjdk.org/jdk/pull/11874

From bhuang at openjdk.org  Thu Jan 12 18:58:49 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 12 Jan 2023 18:58:49 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups [v4]
In-Reply-To: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
Message-ID: <MfXRt9m373Knyx1uWt20egQLztwsaDX1Fq1wwiWlSE4=.27eb3d70-ed88-4dd8-8e3b-d00a2445a457@github.com>

> This task is created to update the manual test groups.

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

  Removed performance tests from the jdk_core_manual group as they have been covered in the client-atr test groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10864/files
  - new: https://git.openjdk.org/jdk/pull/10864/files/9006f137..bd2b50a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864

PR: https://git.openjdk.org/jdk/pull/10864

From duke at openjdk.org  Thu Jan 12 19:04:22 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:04:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
Message-ID: <mnzreiQ4ic41rCo5WRuC5WzyAVWb58ofih-n7PDjb3w=.9d9d8237-5b64-4e8a-9f3a-bc915d6504ea@github.com>

On Thu, 12 Jan 2023 17:29:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I put it there because of switch expressions and `yeild`... ?
>
> Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE?

It's just an artifact of the way switch expressions are handled:

    @Override
    public void visitSwitchExpression(JCSwitchExpression tree) {
        visitScoped(tree, true, t -> {
            scan(t.selector);
            refs.discardExprs(depth);
            RefSet<ExprRef> combinedRefs = new RefSet<>();
            for (List<JCCase> cases = t.cases; cases.nonEmpty(); cases = cases.tail) {
                scan(cases.head);
                combinedRefs.addAll(refs.removeExprs(depth));
            }
            refs.addAll(combinedRefs);
        });
    }

    @Override
    public void visitCase(JCCase tree) {
        scan(tree.stats);          // no need to scan labels
    }

After scanning a switch expression case, the `yield`'ed value will be on the top of the stack.

Then `visitCase` does NOT remove it, so that it can be picked up and removed by `visitSwitchExpression()`.

But this can be cleaned up a little bit, by having `visitSwitchExpression()` not delegate to `visitCase()` but rather iterate through the case statements itself directly. Then we can remove the `CASE` as you suggest.

Also I realized we need to handle `yield`'ed values like `return` values, i.e., collect and remember them until the entire case is complete.

I'll fix.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 19:04:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 19:04:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
Message-ID: <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>

On Thu, 12 Jan 2023 17:33:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875:
>> 
>>> 873:         // Reference to this?
>>> 874:         if (tree.name == names._this || tree.name == names._super) {
>>> 875:             if (this.refs.contains(ThisRef.direct()))
>> 
>> This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere).
>
> The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.
> 
> When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.
> 
> In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).
> 
> Regarding the optimization you mention, in light of the above I'm not sure it would still work.

My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 

There is also this bit in `visitReference`:


case SUPER:
            if (this.refs.contains(ThisRef.direct()))
                receiverRefs.add(ThisRef.direct());
            if (this.refs.contains(ThisRef.indirect()))
                receiverRefs.add(ThisRef.indirect());
            break;


But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.

The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:

* the set of variables that can point to this, whether directly or indirectly (this is truly a set)
* whether the current context has a direct or indirect this (this seems more a flag to me)
* whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)

When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

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

PR: https://git.openjdk.org/jdk/pull/11874

From eirbjo at gmail.com  Thu Jan 12 19:05:27 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 12 Jan 2023 20:05:27 +0100
Subject: ZipFile.isSignatureRelated returns true for files in META-INF
 subdirectories
In-Reply-To: <CA+pBWhs9EpASb6JGpcy5x2H4ToRZoALkhv1oJFe0Sw4qExB6dA@mail.gmail.com>
References: <CA+pBWhs9EpASb6JGpcy5x2H4ToRZoALkhv1oJFe0Sw4qExB6dA@mail.gmail.com>
Message-ID: <CA+pBWhvOdw5pXEUCdPOXA-7ho0pFjceVYf33LA=0aAD9qPQr8A@mail.gmail.com>

>
> ZipFile.isSignatureRelated currently returns true for paths such as the
> following:
>
>
> META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
>

I found a couple more call sites of SignatureFileVerifier.isBlockOrSF which
incorrectly treat [SF,DSA,RSA,EC] files as signature related even when they
reside in subdirectories of META-INF/:

o JarVerifier.beginEntry incorrectly sets up verification
o JarSigner.sign0 incorrectly identifies a jar as already signed, even when
it is not

I have made a draft PR which updates these call sites to require files to
reside directly in META-INF/ before they are considered signature related:

https://github.com/openjdk/jdk/pull/11976

The PR includes a new test which verifies that subdirectory signature files
are indeed ignored by the updated code

Feedback on this PR is welcome!

A few questions:
>
> 1: Where Is the exact location of signature related files specified?
>

I'm assuming the JAR File Specification is the normative source here [1]


> 2: Is the current behaviour indeed incorrect?
>

The spec says: "Note that if such files are located in META-INF
subdirectories, they are not considered signature-related"


> 3: Should ZipFile.isSignatureRelated be updated such that it only matches
> signature related files which reside exactly in "META-INF/" ?
>

I guess there is a risk that jar files may exist which are signed with
signature files in subdirectories. If such files exist, they are not
produced with jarsigner and they are not according to the spec.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230112/8efb2da9/attachment.htm>

From darcy at openjdk.org  Thu Jan 12 19:08:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 12 Jan 2023 19:08:18 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v5]
In-Reply-To: <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
Message-ID: <fZNtS8nbTYl4IpgLSpu977loU8eBKAEDYhR93B455E8=.1d15f087-7ac1-4871-bafb-4c062f569cfd@github.com>

On Thu, 12 Jan 2023 15:31:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11939

From duke at openjdk.org  Thu Jan 12 19:15:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:15:20 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
Message-ID: <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>

On Thu, 12 Jan 2023 17:40:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).

Ah, I see what you mean.

Here's a more complete example:

public class CastLeak {

    public CastLeak() {
        ((CastLeak)(Runnable)this).mightLeak();
    }

    public void mightLeak() {
    }
}

That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated.

So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above.

So I still think it's worth doing.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 19:20:57 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 19:20:57 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone
Message-ID: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>

This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.

Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

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

Commit messages:
 - Replace <pre> blocks with @snippet

Changes: https://git.openjdk.org/jdk/pull/11955/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300011
  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11955/head:pull/11955

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Thu Jan 12 19:23:13 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 19:23:13 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
Message-ID: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>

In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 

_TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
can't determine the time zone from java.home and user.region properties,
it returns GMT._ 

This change updates the code to get rid of the no longer needed Try Catch

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

Commit messages:
 - Remove local variable javaHome
 - Indentation
 - Remove try catch block

Changes: https://git.openjdk.org/jdk/pull/11951/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11951&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299865
  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11951.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11951/head:pull/11951

PR: https://git.openjdk.org/jdk/pull/11951

From naoto at openjdk.org  Thu Jan 12 19:23:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jan 2023 19:23:15 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <UP6hwYC8vkfG5PLBAmfh9WvfG6wxGTFDmjKfc2e-GkY=.1f451156-597f-4d50-bd8f-a24f5753f407@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

src/java.base/share/classes/java/util/TimeZone.java line 678:

> 676:         if (zoneID == null || zoneID.isEmpty()) {
> 677:             String javaHome = StaticProperty.javaHome();
> 678:                 zoneID = getSystemTimeZoneID(javaHome);

Nit: align the indentation. Also, `javaHome` variable can be eliminated.

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

PR: https://git.openjdk.org/jdk/pull/11951

From duke at openjdk.org  Thu Jan 12 19:23:15 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 19:23:15 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <UP6hwYC8vkfG5PLBAmfh9WvfG6wxGTFDmjKfc2e-GkY=.1f451156-597f-4d50-bd8f-a24f5753f407@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
 <UP6hwYC8vkfG5PLBAmfh9WvfG6wxGTFDmjKfc2e-GkY=.1f451156-597f-4d50-bd8f-a24f5753f407@github.com>
Message-ID: <8veMF3P9ExIr0pdVkfsYzDx2-K4iE9zwT1rTNswTi6c=.2b39d282-48fc-4b66-beb5-d6ba1a979135@github.com>

On Wed, 11 Jan 2023 17:34:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
>> 
>> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
>> can't determine the time zone from java.home and user.region properties,
>> it returns GMT._ 
>> 
>> This change updates the code to get rid of the no longer needed Try Catch
>
> src/java.base/share/classes/java/util/TimeZone.java line 678:
> 
>> 676:         if (zoneID == null || zoneID.isEmpty()) {
>> 677:             String javaHome = StaticProperty.javaHome();
>> 678:                 zoneID = getSystemTimeZoneID(javaHome);
> 
> Nit: align the indentation. Also, `javaHome` variable can be eliminated.

Thanks for catching that, fixed

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

PR: https://git.openjdk.org/jdk/pull/11951

From rgiulietti at openjdk.org  Thu Jan 12 19:24:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Jan 2023 19:24:26 GMT
Subject: Integrated: 8299677: Formatter.format might take a long time to format
 an integer or floating-point
In-Reply-To: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
Message-ID: <GJ7zBubP03kLbrpdlM6GEl_P-hm-dlJxgcxdRBqqyWQ=.848aade8-d774-495e-beef-2357191555bd@github.com>

On Wed, 11 Jan 2023 10:47:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.

This pull request has now been integrated.

Changeset: 33412c10
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33412c102ce799ff2de3512df77e6e07d76acd36
Stats:     318 lines in 2 files changed: 313 ins; 1 del; 4 mod

8299677: Formatter.format might take a long time to format an integer or floating-point

Reviewed-by: alanb, stsypanov, darcy

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

PR: https://git.openjdk.org/jdk/pull/11939

From lancea at openjdk.org  Thu Jan 12 19:27:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 12 Jan 2023 19:27:15 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <9zP42-oN27_bWEhcS9XgaYCS7Tu5JpkOJID6Lr4HhJA=.45f7aad2-d0d9-4fe6-9cea-fecf260d394d@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11951

From duke at openjdk.org  Thu Jan 12 19:27:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 19:27:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
 <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
Message-ID: <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>

On Thu, 12 Jan 2023 18:40:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch:
>> 
>> 
>> diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
>> index 1c89328a388..7c3f0293edc 100644
>> --- a/make/test/BuildMicrobenchmark.gmk
>> +++ b/make/test/BuildMicrobenchmark.gmk
>> @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \
>>      TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \
>>      SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \
>>      INCLUDE_FILES := indify/Indify.java, \
>> -    DISABLED_WARNINGS := rawtypes serial options, \
>> +    DISABLED_WARNINGS := this-escape rawtypes serial options, \
>>      BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \
>>      JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \
>>  ))
>> @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
>>      TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>>      SMALL_JAVA := false, \
>>      CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
>> -    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
>> +    DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \
>>      SRC := $(MICROBENCHMARK_SRC), \
>>      BIN := $(MICROBENCHMARK_CLASSES), \
>>      JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> index 9d35c2fbc0a..4e2b1e558e7 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              // Check for implicit 'this' reference
>>              final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>>              final Type methodOwnerType = sym.owner.type;
>> +            //if (currentClassType.tsym.isSubClass(sym.owner, types)) {
>>              if (this.isSubtype(currentClassType, methodOwnerType)) {
>>                  if (this.refs.contains(ThisRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // Check for implicit outer 'this' reference
>> +            // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) {
>>              if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> 
>> 
>> Fixes the build failure.
>
> This patch passes all tests:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> index 9d35c2fbc0a..e755c54d0c8 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
> @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // If the expression type is incompatible with 'this', discard it
> -            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
> +            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
>                  this.refs.remove(ExprRef.direct(this.depth));
>          }
>      }
> @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>          if (explicitOuterThis != null) {
>              this.scan(explicitOuterThis);
>              this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
> -        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
> +        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
>              if (this.refs.contains(ThisRef.direct()))
>                  outerRefs.add(OuterRef.direct());
>              if (this.refs.contains(ThisRef.indirect()))
> @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
>          // Explicit outer 'this' reference?
>          final Type selectedType = this.types.erasure(tree.selected.type);
>          if (selectedType.hasTag(CLASS)) {
> -            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
>              if (tree.name == this.names._this &&
> -                this.types.hasOuterClass(currentClassType, selectedClassType)) {
> +                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
>                  if (this.refs.contains(OuterRef.indirect()))
> @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              final MethodSymbol sym = (MethodSymbol)tree.sym;
>  
>              // Check for implicit 'this' reference
> -            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
> -            final Type methodOwnerType = sym.owner.type;
> -            if (this.isSubtype(currentClassType, methodOwnerType)) {
> +            if (methodClass.sym.isSubClass(sym.owner, types)) {
>                  if (this.refs.contains(ThisRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
>                  if (this.refs.contains(ThisRef.indirect()))
> @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>              }
>  
>              // Check for implicit outer 'this' reference
> -            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
> +            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
>                  if (this.refs.contains(OuterRef.direct()))
>                      this.refs.add(ExprRef.direct(this.depth));
> 
> 
> Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 
> 
> Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.

Weird. I don't get that build failure.

Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building.

I will add the `DISABLED_WARNINGS` in any case.

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

PR: https://git.openjdk.org/jdk/pull/11874

From iris at openjdk.org  Thu Jan 12 19:52:19 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 12 Jan 2023 19:52:19 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <0k0gAQddym_D3rnjCqnKueOjn1-WWUMcl79VsAMizpg=.22ecfbd7-760a-446f-9ad2-16deb952ad12@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11951

From jwilhelm at openjdk.org  Thu Jan 12 21:06:19 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 12 Jan 2023 21:06:19 GMT
Subject: RFR: Merge jdk20
Message-ID: <g6WWWsg1YtNOQQeFjqeUXBAM10ZM6wCSszRA0jPpgR0=.6491c80c-066b-44aa-892c-b2a15a4a5d01@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle
 - 8299034: Runtime::exec clarification of inherited environment
 - 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
 - 8299090: Specify coordinate order for additional CaptureCallState parameters on class as well

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/11979/files
  Stats: 12 lines in 3 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11979/head:pull/11979

PR: https://git.openjdk.org/jdk/pull/11979

From duke at openjdk.org  Thu Jan 12 21:07:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:07:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
Message-ID: <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>

On Thu, 12 Jan 2023 18:48:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I guess what I'm thinking about:
>> 
>> No leak is possible in that example.
>> * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden
>> * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private
>
> but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?

Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.

We only care about bugs where a superclass and subclass are in separate compilation units.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 21:07:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:07:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <HeXkWGu5fgyW6A9Jm2h3iylOary4wkYTPEcwEYaigzs=.3941421d-e1dc-489c-afef-a116faa5a592@github.com>
 <OlSYF58dAKzpCOTvsW0Z3ABoFiMrzXbkxiVBPrO0Huo=.069bfdc8-e2d3-470f-b6bf-945e3a1e9e8f@github.com>
 <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com>
 <H5V8WGugbzMju7YhCvJlbks3UYFt4968R2xBT2gDy2E=.4d938252-59a9-4424-ace2-d62d9ec58388@github.com>
 <cssouTFgoltPdZIh3eFqQvVsIji6eDVyCe6jSw_eFUQ=.726f3cb9-3d71-448c-8f41-5f122c72c272@github.com>
Message-ID: <S64E1MdWn5ot_6NEsqBBIlT5X9Fqw7HjtRnpsfv9Hds=.38f15307-7535-4840-960d-1e9e3b225989@github.com>

On Thu, 12 Jan 2023 19:24:50 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch passes all tests:
>> 
>> 
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> index 9d35c2fbc0a..e755c54d0c8 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // If the expression type is incompatible with 'this', discard it
>> -            if (type != null && !this.isSubtype(this.targetClass.sym.type, type))
>> +            if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types))
>>                  this.refs.remove(ExprRef.direct(this.depth));
>>          }
>>      }
>> @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>          if (explicitOuterThis != null) {
>>              this.scan(explicitOuterThis);
>>              this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct)));
>> -        } else if (this.types.hasOuterClass(type, this.methodClass.type)) {
>> +        } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) {
>>              if (this.refs.contains(ThisRef.direct()))
>>                  outerRefs.add(OuterRef.direct());
>>              if (this.refs.contains(ThisRef.indirect()))
>> @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>          // Explicit outer 'this' reference?
>>          final Type selectedType = this.types.erasure(tree.selected.type);
>>          if (selectedType.hasTag(CLASS)) {
>> -            final Type.ClassType selectedClassType = (Type.ClassType)selectedType;
>>              if (tree.name == this.names._this &&
>> -                this.types.hasOuterClass(currentClassType, selectedClassType)) {
>> +                currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>>                  if (this.refs.contains(OuterRef.indirect()))
>> @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              final MethodSymbol sym = (MethodSymbol)tree.sym;
>>  
>>              // Check for implicit 'this' reference
>> -            final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type;
>> -            final Type methodOwnerType = sym.owner.type;
>> -            if (this.isSubtype(currentClassType, methodOwnerType)) {
>> +            if (methodClass.sym.isSubClass(sym.owner, types)) {
>>                  if (this.refs.contains(ThisRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>>                  if (this.refs.contains(ThisRef.indirect()))
>> @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner {
>>              }
>>  
>>              // Check for implicit outer 'this' reference
>> -            if (this.types.hasOuterClass(currentClassType, methodOwnerType)) {
>> +            if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) {
>>                  if (this.refs.contains(OuterRef.direct()))
>>                      this.refs.add(ExprRef.direct(this.depth));
>> 
>> 
>> Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. 
>> 
>> Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client.
>
> Weird. I don't get that build failure.
> 
> Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building.
> 
> I will add the `DISABLED_WARNINGS` in any case.

Thanks for the patch!

The semantics of `hasOuterClass()` returns false if A and B are the same class, while `isEnclosedBy()` returns true if A and B are the same class.

However, I don't think it would actually matter in practice...

Regardless, I'll add the extra equality comparison and apply your patch and also the suggestions to integrate `isExplicitThisReference()` and eliminate `hasOuterClass()`.

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

PR: https://git.openjdk.org/jdk/pull/11874

From naoto at openjdk.org  Thu Jan 12 21:11:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jan 2023 21:11:15 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone
In-Reply-To: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
Message-ID: <rc9nun7vC7MWa6PrWlUaOwTj7_UgDIFpBaEO8RXaRsI=.6dee0f65-c747-4873-8c39-1452c9f6140f@github.com>

On Wed, 11 Jan 2023 23:41:46 GMT, Justin Lu <duke at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
> 
> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

src/java.base/share/classes/java/util/TimeZone.java line 313:

> 311:      * <p>This method is equivalent to:
> 312:      * {@snippet lang=java :
> 313:      * getDisplayName(false, LONG, // @link substring="LONG" target="#LONG"

You could move those `@link` directives above the code and concatenate them with ":", e.g,

    * // @link substring="LONG" target="#LONG" :
    * getDisplayName(false, LONG,

so that the line won't be very long.

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

PR: https://git.openjdk.org/jdk/pull/11955

From naoto at openjdk.org  Thu Jan 12 21:12:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jan 2023 21:12:16 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <8M2nApE-R5oNE0Nnm7dBJTpnvpiGCXkOGsw4gj3DKWU=.c596eb78-e34b-4bd0-9755-5dc0dd21e029@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11951

From duke at openjdk.org  Thu Jan 12 21:30:00 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 21:30:00 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v2]
In-Reply-To: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
Message-ID: <mLqrPk0UJpRm98JGsFQT1f-0KrK7CCSRPkSWYeaEQHM=.0208c5de-df82-49f5-a768-6fa1b5552fe9@github.com>

> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
> 
> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

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

  Move link to separate lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11955/files
  - new: https://git.openjdk.org/jdk/pull/11955/files/dae09b0b..70d8fa86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=00-01

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11955/head:pull/11955

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Thu Jan 12 21:30:03 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 21:30:03 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v2]
In-Reply-To: <rc9nun7vC7MWa6PrWlUaOwTj7_UgDIFpBaEO8RXaRsI=.6dee0f65-c747-4873-8c39-1452c9f6140f@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <rc9nun7vC7MWa6PrWlUaOwTj7_UgDIFpBaEO8RXaRsI=.6dee0f65-c747-4873-8c39-1452c9f6140f@github.com>
Message-ID: <IVjJszOKICLUlk85cazdZc_FBQoiTomiQKCW2D8V48o=.24c76418-209b-4fc6-ad1f-ac547888a55a@github.com>

On Thu, 12 Jan 2023 21:08:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move link to separate lines
>
> src/java.base/share/classes/java/util/TimeZone.java line 313:
> 
>> 311:      * <p>This method is equivalent to:
>> 312:      * {@snippet lang=java :
>> 313:      * getDisplayName(false, LONG, // @link substring="LONG" target="#LONG"
> 
> You could move those `@link` directives above the code and concatenate them with ":", e.g,
> 
>     * // @link substring="LONG" target="#LONG" :
>     * getDisplayName(false, LONG,
> 
> so that the line won't be very long.

Did not realize that could be done, made the fix, thank you

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Thu Jan 12 21:31:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 12 Jan 2023 21:31:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
 <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
Message-ID: <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>

On Thu, 12 Jan 2023 19:01:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method.
>> 
>> When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set.
>> 
>> In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question).
>> 
>> Regarding the optimization you mention, in light of the above I'm not sure it would still work.
>
> My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 
> 
> There is also this bit in `visitReference`:
> 
> 
> case SUPER:
>             if (this.refs.contains(ThisRef.direct()))
>                 receiverRefs.add(ThisRef.direct());
>             if (this.refs.contains(ThisRef.indirect()))
>                 receiverRefs.add(ThisRef.indirect());
>             break;
> 
> 
> But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.
> 
> The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:
> 
> * the set of variables that can point to this, whether directly or indirectly (this is truly a set)
> * whether the current context has a direct or indirect this (this seems more a flag to me)
> * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)
> 
> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field.

There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things.

The benefit is the simplicity of being able to think of the data model as "just a set of references".

For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this:


    @Override
    public void visitReturn(JCReturn tree) {
        scan(tree.expr);
        refs.replaceExprs(depth, ReturnRef::new);
    }


But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code:

            if (refs.contains(ThisRef.direct()))
                outerRefs.add(OuterRef.direct());
            if (refs.contains(ThisRef.indirect()))
                outerRefs.add(OuterRef.indirect());

with something like this:

            refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);


I will go through and refactor to do that and clean things up a little more.

> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.

Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Thu Jan 12 21:47:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Jan 2023 21:47:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <B8My4cqEflONOlWc75umJqxNRJrd0uFM6jHCF090Ln4=.85355133-7fc5-4afa-b7c5-f41242aee038@github.com>
 <Q9_WG6FXdZ8vKHvpaxQgB7bqSMmgr5B3K6ontsX2tYc=.98807ef6-c1a7-4cd8-8acf-4f79ed623ccb@github.com>
 <bQRip8YkoGXxKbaNcn026jlLR73JRl_-hX_UgGDSaBg=.73075c3e-1dbf-41d2-ae3b-275bf36b668f@github.com>
Message-ID: <gxDMb8M-9X-WeqGLdm-RDbtxmeE4TvAQdJ-AHDIwGGU=.9bf4bd87-8467-4d06-877f-55486fefccb9@github.com>

On Thu, 12 Jan 2023 21:28:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). 
>> 
>> There is also this bit in `visitReference`:
>> 
>> 
>> case SUPER:
>>             if (this.refs.contains(ThisRef.direct()))
>>                 receiverRefs.add(ThisRef.direct());
>>             if (this.refs.contains(ThisRef.indirect()))
>>                 receiverRefs.add(ThisRef.indirect());
>>             break;
>> 
>> 
>> But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation.
>> 
>> The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects:
>> 
>> * the set of variables that can point to this, whether directly or indirectly (this is truly a set)
>> * whether the current context has a direct or indirect this (this seems more a flag to me)
>> * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set)
>> 
>> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.
>
> I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field.
> 
> There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things.
> 
> The benefit is the simplicity of being able to think of the data model as "just a set of references".
> 
> For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this:
> 
> 
>     @Override
>     public void visitReturn(JCReturn tree) {
>         scan(tree.expr);
>         refs.replaceExprs(depth, ReturnRef::new);
>     }
> 
> 
> But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code:
> 
>             if (refs.contains(ThisRef.direct()))
>                 outerRefs.add(OuterRef.direct());
>             if (refs.contains(ThisRef.indirect()))
>                 outerRefs.add(OuterRef.indirect());
> 
> with something like this:
> 
>             refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);
> 
> 
> I will go through and refactor to do that and clean things up a little more.
> 
>> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me.
> 
> Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0.

> ```java
> ```java
>  if (refs.contains(ThisRef.direct()))
>                 outerRefs.add(OuterRef.direct());
>             if (refs.contains(ThisRef.indirect()))
>                 outerRefs.add(OuterRef.indirect());
> ```
> 
> 
>     
>       
>     
> 
>       
>     
> 
>     
>   
> with something like this:
> ```java
>             refs.mapInto(outerRefs, ThisRef.class, OuterRef::new);
> ```
> ```

This sounds like a good idea, that idiom is quite widespread, so it should help avoiding repetition.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Thu Jan 12 21:50:27 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 21:50:27 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v2]
In-Reply-To: <mLqrPk0UJpRm98JGsFQT1f-0KrK7CCSRPkSWYeaEQHM=.0208c5de-df82-49f5-a768-6fa1b5552fe9@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <mLqrPk0UJpRm98JGsFQT1f-0KrK7CCSRPkSWYeaEQHM=.0208c5de-df82-49f5-a768-6fa1b5552fe9@github.com>
Message-ID: <rhY1VYhxT_OZCf_IW18AM3peQrLusOeFKVczt-7hBG0=.f784876d-e333-42e4-8456-54de35c6cee9@github.com>

On Thu, 12 Jan 2023 21:30:00 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move link to separate lines

src/java.base/share/classes/java/util/TimeZone.java line 66:

> 64:  * U.S. Pacific Time zone is "America/Los_Angeles". So, you can get a
> 65:  * U.S. Pacific Time {@code TimeZone} object with:
> 66:  * <blockquote><pre>

@naotoj <blockquote> actually adds indentation for the contents contained within. So I will be reverting the removal of those tags to prevent visual change.

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Thu Jan 12 22:21:39 2023
From: duke at openjdk.org (Justin Lu)
Date: Thu, 12 Jan 2023 22:21:39 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v3]
In-Reply-To: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
Message-ID: <_LpPahUcrOJBUoPu5QdmtxbHDZVAztRIgBMn1P__PBA=.3cde4d95-f8fd-4a9e-9f22-89792bf8b7d6@github.com>

> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
> 
> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

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

  Re-add blockquotes (indendation)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11955/files
  - new: https://git.openjdk.org/jdk/pull/11955/files/70d8fa86..a2f57899

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=01-02

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11955/head:pull/11955

PR: https://git.openjdk.org/jdk/pull/11955

From jwilhelm at openjdk.org  Thu Jan 12 22:28:23 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 12 Jan 2023 22:28:23 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <g6WWWsg1YtNOQQeFjqeUXBAM10ZM6wCSszRA0jPpgR0=.6491c80c-066b-44aa-892c-b2a15a4a5d01@github.com>
References: <g6WWWsg1YtNOQQeFjqeUXBAM10ZM6wCSszRA0jPpgR0=.6491c80c-066b-44aa-892c-b2a15a4a5d01@github.com>
Message-ID: <fiie3J4z7tNNStwoM3zoD8sDmBRQCsR3apUiKbVlPmI=.c820f0f1-5ca5-4fbd-9ebc-319525f8b78b@github.com>

On Thu, 12 Jan 2023 20:57:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 98870472
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98870472282a76be14acb2dfba483c97359dabba
Stats:     12 lines in 3 files changed: 10 ins; 0 del; 2 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11979

From lancea at openjdk.org  Fri Jan 13 04:02:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jan 2023 04:02:54 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v3]
In-Reply-To: <_LpPahUcrOJBUoPu5QdmtxbHDZVAztRIgBMn1P__PBA=.3cde4d95-f8fd-4a9e-9f22-89792bf8b7d6@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <_LpPahUcrOJBUoPu5QdmtxbHDZVAztRIgBMn1P__PBA=.3cde4d95-f8fd-4a9e-9f22-89792bf8b7d6@github.com>
Message-ID: <3IGruJQbv_8Ab_r43p7RRLMk-UBMPI1KrYfkQZh7a6A=.4b56cb51-1530-4b58-8f26-115f0936b26e@github.com>

On Thu, 12 Jan 2023 22:21:39 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add blockquotes (indendation)

Marked as reviewed by lancea (Reviewer).

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Fri Jan 13 04:03:25 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 04:03:25 GMT
Subject: RFR: 8300077: Refactor code examples to use @snippet in
 java.text.ChoiceFormat
Message-ID: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

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

Commit messages:
 - Use snippets

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

PR: https://git.openjdk.org/jdk/pull/11981

From duke at openjdk.org  Fri Jan 13 04:04:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 04:04:36 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:

 - Fix bug where all but the last yeild statement were being ignored.
 - Add method RefSet.mapInto() and use to refactor/clean up.
 - Fix possible assertion failure when handling if statements.
 - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
   
   Suggested-by:   mcimadamore
 - Add comment regarding limitations of expresison type filtering.
 - Add a few more DISABLED_WARNINGS to unbreak build.
 - Clean up handling of switch expressions a bit.
 - Remove unused method variant of analyzeTree().
 - Avoid all caps in comments.
 - Clarify confusing comment.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/6e96a7d7..edf3c3f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=06-07

  Stats: 540 lines in 8 files changed: 120 ins; 92 del; 328 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Fri Jan 13 04:04:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 04:04:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
Message-ID: <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>

On Thu, 12 Jan 2023 19:12:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy:
>> 
>> 
>> interface A { }
>> class B {
>>      B() {
>>           A a = (A)this;
>>           ...
>>       }
>>  }
>>  class C extends B implements A { }
>>  ```
>> 
>> Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).
>
>> But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated).
> 
> Ah, I see what you mean.
> 
> Here's a more complete example:
> 
> public class CastLeak {
> 
>     public CastLeak() {
>         ((CastLeak)(Runnable)this).mightLeak();
>     }
> 
>     public void mightLeak() {
>     }
> }
> 
> That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated.
> 
> So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above.
> 
> So I still think it's worth doing.

Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 04:04:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 04:04:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
 <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
Message-ID: <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>

On Thu, 12 Jan 2023 21:47:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>  Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern.

You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science.

> I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.

That's a nice idea... thanks. I'll play around with it some.

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

PR: https://git.openjdk.org/jdk/pull/11874

From Alan.Bateman at oracle.com  Fri Jan 13 08:32:06 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jan 2023 08:32:06 +0000
Subject: ZipFile.isSignatureRelated returns true for files in META-INF
 subdirectories
In-Reply-To: <CA+pBWhs9EpASb6JGpcy5x2H4ToRZoALkhv1oJFe0Sw4qExB6dA@mail.gmail.com>
References: <CA+pBWhs9EpASb6JGpcy5x2H4ToRZoALkhv1oJFe0Sw4qExB6dA@mail.gmail.com>
Message-ID: <018e02d9-4d16-65ca-a7b0-c085c01af67b@oracle.com>


Forwarding to security-dev as that is where issues around signed JARs 
are usually discussed.

-Alan.


On 10/01/2023 17:00, Eirik Bj?rsn?s wrote:
> Hi,
>
> ZipFile.isSignatureRelated currently returns true for paths such as 
> the following:
>
> META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
>
> While this path does start?with "META-INF/" and ends with ".DSA", 
> the?file does not live in the META-INF/ directory _directly_, but 
> rather several directories below.
>
> This causes such .DSA files to be incorrectly (?) included in the 
> verification of META-INF/MANIFEST.MF in JarFile.initializeVerifier, 
> which then fails with:
>
>     Exception in thread "main" java.lang.SecurityException: Invalid
>     signature file digest for Manifest main attributes
>     at
>     java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340)
>     at
>     java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282)
>     at
>     java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327)
>     at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
>     at
>     java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760)
>     at
>     java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058)
>     at
>     java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72)
>     at
>     java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883)
>     at
>     java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848)
>     at
>     java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>     at
>     java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>     at
>     java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>     at
>     java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>     at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) 
>
>
> A few questions:
>
> 1: Where Is the exact location of signature related files specified?
>
> 2: Is the current behaviour indeed incorrect?
>
> 3: Should ZipFile.isSignatureRelated be updated such that it only 
> matches signature related files which reside?exactly in "META-INF/" ?
>
> The context for this is that I'm making a fat jar Maven plugin which 
> embeds dependency jars by "unpacking" them into subdirectories of 
> META-INF/libraries/.
>
> Cheers,
> Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230113/fe979f16/attachment.htm>

From aturbanov at openjdk.org  Fri Jan 13 10:10:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 13 Jan 2023 10:10:12 GMT
Subject: RFR: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <3R5cDUNJVzWo-d6OQ_7Aa0WVsIQhytAz4Ne-hbTROs8=.ba6501f2-19f4-4241-ba7f-12b7396a957b@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

Marked as reviewed by aturbanov (Committer).

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

PR: https://git.openjdk.org/jdk/pull/11951

From mcimadamore at openjdk.org  Fri Jan 13 11:01:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:01:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
Message-ID: <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>

On Thu, 12 Jan 2023 21:04:09 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo?
>
> Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.
> 
> We only care about bugs where a superclass and subclass are in separate compilation units.

So, to clarify, in this case:


import java.util.*;

class B {
    final Object ref;

     private B(Object ref) {
          Foo.consume(this);
          this.ref = ref;
      }
 }


Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!

That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.

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

PR: https://git.openjdk.org/jdk/pull/11874

From lancea at openjdk.org  Fri Jan 13 11:04:18 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jan 2023 11:04:18 GMT
Subject: RFR: 8300077: Refactor code examples to use @snippet in
 java.text.ChoiceFormat
In-Reply-To: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
References: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
Message-ID: <1XWPxLF9LGdfBlAAscA0OuBfdcqOvCRn_hv8qOG0C8g=.2ddb4a2e-7c24-40db-8b1c-acaa20187aaa@github.com>

On Thu, 12 Jan 2023 22:31:24 GMT, Justin Lu <duke at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11981

From lancea at openjdk.org  Fri Jan 13 11:10:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jan 2023 11:10:15 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v3]
In-Reply-To: <_LpPahUcrOJBUoPu5QdmtxbHDZVAztRIgBMn1P__PBA=.3cde4d95-f8fd-4a9e-9f22-89792bf8b7d6@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <_LpPahUcrOJBUoPu5QdmtxbHDZVAztRIgBMn1P__PBA=.3cde4d95-f8fd-4a9e-9f22-89792bf8b7d6@github.com>
Message-ID: <Rl7g5qxLgEjBG3yu0Hxpky7uRB10P3xGdgR-oSN2z5Y=.43effdd2-6ec1-4d00-ac7b-4e2b07bd7f84@github.com>

On Thu, 12 Jan 2023 22:21:39 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add blockquotes (indendation)

src/java.base/share/classes/java/util/TimeZone.java line 319:

> 317:      * getDisplayName(false, LONG,
> 318:      *                // @link substring="Locale.Category.DISPLAY" target="Locale.Category#DISPLAY" :
> 319:      *                Locale.getDefault(Locale.Category.DISPLAY))

One thought here as I look at this again and now that this is a snippet is that we should probably add the trailing `;` to the code examples...

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

PR: https://git.openjdk.org/jdk/pull/11955

From mcimadamore at openjdk.org  Fri Jan 13 11:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:11:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
Message-ID: <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0rNFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>

On Fri, 13 Jan 2023 11:05:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> So, to clarify, in this case:
>> 
>> 
>> import java.util.*;
>> 
>> class B {
>>     final Object ref;
>> 
>>      private B(Object ref) {
>>           Foo.consume(this);
>>           this.ref = ref;
>>       }
>>  }
>> 
>> 
>> Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!
>> 
>> That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.
>
> Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:
> 
> 
>     this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
> 
> 
> Which indeed aligns well with what this PR is doing. So that's ok.

Something seems to be up with the lint description for this-escape - compare this:


  serial               Warn about Serializable classes that do not have a serialVersionUID field. 
                         Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.

with this:


  this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
such a method would execute before the subclass constructor completes its initialization.


Indentation seems to be missing, which causes readability issues in the `--help-lint` output.

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

PR: https://git.openjdk.org/jdk/pull/11874

From mcimadamore at openjdk.org  Fri Jan 13 11:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 11:11:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
Message-ID: <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>

On Fri, 13 Jan 2023 10:58:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal.
>> 
>> We only care about bugs where a superclass and subclass are in separate compilation units.
>
> So, to clarify, in this case:
> 
> 
> import java.util.*;
> 
> class B {
>     final Object ref;
> 
>      private B(Object ref) {
>           Foo.consume(this);
>           this.ref = ref;
>       }
>  }
> 
> 
> Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized!
> 
> That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok.

Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:


    this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;


Which indeed aligns well with what this PR is doing. So that's ok.

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

PR: https://git.openjdk.org/jdk/pull/11874

From jvernee at openjdk.org  Fri Jan 13 11:33:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Jan 2023 11:33:14 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
Message-ID: <xbM07GsK0sQfAD0K2zEuZFG8-lDnHjjNQ71ahGbA08s=.723105ba-82e7-43a1-af14-aa137d24d086@github.com>

On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix callArranger

Excellent. No Comments.

I am running some sanity testing on our CI, and will approve when it comes back green.

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

PR: https://git.openjdk.org/jdk/pull/11004

From vromero at openjdk.org  Fri Jan 13 12:45:34 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 12:45:34 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:

> 514:         Name name = TreeInfo.name(invoke.meth);
> 515:         if (name == names._super) {
> 516:             scanInitializers();

it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan 13 14:15:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jan 2023 14:15:13 GMT
Subject: RFR: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows
In-Reply-To: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
References: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
Message-ID: <fS_6tjRDWhk-NszWvZO1eNpCux1U6aheKVdf94gS7eU=.fe920127-7af9-43d8-8628-d4b7f7fbd331@github.com>

On Thu, 12 Jan 2023 17:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to [JDK-8298971](https://bugs.openjdk.org/browse/JDK-8298971). The previous fix lacked the native part change on Windows.

I think we should try to have a cleaner separation between these native methods. If JdkConsoleImpl_echo is changed to call GetStdHandle(STD_INPUT_HANDLE) then it would avoid needing Console_md to export java_io_Console_hStdIn. It would mean the static fields in Console_md could be removed too.

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

PR: https://git.openjdk.org/jdk/pull/11973

From vromero at openjdk.org  Fri Jan 13 14:34:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 14:34:40 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <RTLJlnoc5Po9tb0cF1F9mACGYYNWpE1GKfebO5GL1xU=.e7518803-becd-4864-9576-49836d9118dd@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533:

> 531:         if (sym != null &&
> 532:             sym.owner.kind == TYP &&
> 533:             ((ClassSymbol)sym.owner).fullname == names.java_lang_Object &&

nit: in general we use another idiom for this in the compiler:

sym.owner.type.tsym == syms.objectType.tsym

where `syms` is an instance of: `com.sun.tools.javac.code.Symtab`

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan 13 15:07:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jan 2023 15:07:27 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for
 Entry.setValue
In-Reply-To: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
Message-ID: <oKstKPktbEWt6y9o9hK8_6tmxPQS05r3_XonT6Obu4c=.e60ce581-43cf-45f3-afb0-e737877fac71@github.com>

On Thu, 12 Jan 2023 01:50:51 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.

src/java.base/share/classes/java/util/Map.java line 405:

> 403:      * {@link Iterator} or implicitly via the enhanced {@code for} statement. This connection
> 404:      * to the backing map is valid <i>only</i> during iteration of the entry-set view. During
> 405:      * the iteration, if supported by the backing map, a change to a Entry's value via

"a Entry's value" -> "an Entry's value" or "the value of an Entry" ?

src/java.base/share/classes/java/util/Map.java line 421:

> 419:      * {@link Set#toArray toArray} overloads,
> 420:      * or by copying the entry-set view into another collection. It is unspecified whether
> 421:      * the Entry instances thus obtained are connected to the underlying map, whether

It might be a bit clear if tweaked to "whether the obtained Entry instances are connected".

src/java.base/share/classes/java/util/NavigableMap.java line 80:

> 78:  * return {@link Map.Entry} instances that represent snapshots of mappings as
> 79:  * of the time of the call, and they do <em>not</em> support mutation of the
> 80:  * underlying map via the optional {@link Map.Entry#setValue setValue} method.

I think it would be a bit more readable to put to break after "as of the time of the call", either a full stop or "; they".  Same thing in TreeMap.

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

PR: https://git.openjdk.org/jdk/pull/11956

From duke at openjdk.org  Fri Jan 13 15:11:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:11:48 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0rNFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
Message-ID: <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>

On Fri, 13 Jan 2023 11:08:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this:
>> 
>> 
>>     this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
>> 
>> 
>> Which indeed aligns well with what this PR is doing. So that's ok.
>
> Something seems to be up with the lint description for this-escape - compare this:
> 
> 
>   serial               Warn about Serializable classes that do not have a serialVersionUID field. 
>                          Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.
> 
> with this:
> 
> 
>   this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
> such a method would execute before the subclass constructor completes its initialization.
> 
> 
> Indentation seems to be missing, which causes readability issues in the `--help-lint` output.

> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...

Yes - and this very question did come up in the discussions around this warning (see amber-dev).

The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".

But I think it's still an interesting question. Maybe experience will provide more guidance over time.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 15:11:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:11:49 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
Message-ID: <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>

On Fri, 13 Jan 2023 15:08:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Something seems to be up with the lint description for this-escape - compare this:
>> 
>> 
>>   serial               Warn about Serializable classes that do not have a serialVersionUID field. 
>>                          Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces.
>> 
>> with this:
>> 
>> 
>>   this-escape          Warn when a constructor invokes a method that could be overriden in a subclass;
>> such a method would execute before the subclass constructor completes its initialization.
>> 
>> 
>> Indentation seems to be missing, which causes readability issues in the `--help-lint` output.
>
>> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...
> 
> Yes - and this very question did come up in the discussions around this warning (see amber-dev).
> 
> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".
> 
> But I think it's still an interesting question. Maybe experience will provide more guidance over time.

> Something seems to be up with the lint description for this-escape - compare this:

Oops, will fix - thanks.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 15:16:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 15:16:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
Message-ID: <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>

On Fri, 13 Jan 2023 12:42:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
>> 
>>  - Fix bug where all but the last yeild statement were being ignored.
>>  - Add method RefSet.mapInto() and use to refactor/clean up.
>>  - Fix possible assertion failure when handling if statements.
>>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>>    
>>    Suggested-by:   mcimadamore
>>  - Add comment regarding limitations of expresison type filtering.
>>  - Add a few more DISABLED_WARNINGS to unbreak build.
>>  - Clean up handling of switch expressions a bit.
>>  - Remove unused method variant of analyzeTree().
>>  - Avoid all caps in comments.
>>  - Clarify confusing comment.
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:
> 
>> 514:         Name name = TreeInfo.name(invoke.meth);
>> 515:         if (name == names._super) {
>> 516:             scanInitializers();
> 
> it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class

Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.

I'm happy to fix this if you think it is necessary though.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533:
> 
>> 531:         if (sym != null &&
>> 532:             sym.owner.kind == TYP &&
>> 533:             ((ClassSymbol)sym.owner).fullname == names.java_lang_Object &&
> 
> nit: in general we use another idiom for this in the compiler:
> 
> sym.owner.type.tsym == syms.objectType.tsym
> 
> where `syms` is an instance of: `com.sun.tools.javac.code.Symtab`

Thanks - will fix.

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

PR: https://git.openjdk.org/jdk/pull/11874

From alanb at openjdk.org  Fri Jan 13 16:01:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jan 2023 16:01:15 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <RpnJ3L0WIG0bPOZgyp_EmzNMFZjFsfdDfpMoirm5m5A=.ddeaba6d-3230-43cb-bed8-23f975b34234@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

I'm in two minds on whether this should be "fixed" in libjimage. I'm wondering if libjimage should continue to use native order and we instead explore having jlink determine the endianness at link time for the target platform - this might be looking at some property in the packaged module for java.base (java.base.jmod). @JimLaskey Do you have any opinion on this?

For the image reader used by jrtfs then I think it has to work with both as the file system could be created with java.home set in the env to a run-time image for a complete different platform.

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

PR: https://git.openjdk.org/jdk/pull/11943

From mcimadamore at openjdk.org  Fri Jan 13 16:09:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Jan 2023 16:09:37 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
 <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
Message-ID: <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>

On Fri, 13 Jan 2023 15:08:59 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>>> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well...
>> 
>> Yes - and this very question did come up in the discussions around this warning (see amber-dev).
>> 
>> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself".
>> 
>> But I think it's still an interesting question. Maybe experience will provide more guidance over time.
>
>> Something seems to be up with the lint description for this-escape - compare this:
> 
> Oops, will fix - thanks.

> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files

Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)".

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

PR: https://git.openjdk.org/jdk/pull/11874

From vromero at openjdk.org  Fri Jan 13 16:15:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 16:15:32 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
Message-ID: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>

On Fri, 13 Jan 2023 15:14:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516:
>> 
>>> 514:         Name name = TreeInfo.name(invoke.meth);
>>> 515:         if (name == names._super) {
>>> 516:             scanInitializers();
>> 
>> it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class
>
> Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.
> 
> I'm happy to fix this if you think it is necessary though.

I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 16:23:39 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 16:23:39 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com>
 <bvN2tIeLmTuwok1sU-NDcL3oGtrowClZ-QPfLBawiE8=.12d61ae2-1eec-4be2-94ad-33df0dc164c2@github.com>
 <lhiyroxe4g7UI1tTIHkyn_-Mtv5A4Bi-fuZLQVS0yz8=.dcca2807-b62f-4648-8cd3-dad99898f981@github.com>
 <SFu_DMFYI_f5aATNiIMU0PFol3MQOa2eEiJDp7Wh4yY=.29da0374-2bee-47c3-a4a9-22ce845b82d7@github.com>
 <aVas3clwOho0PkkceEl3Ln9IvgkhaSdnZxhsBkEfMzc=.878755a9-3ed2-4d90-a6b3-f7ba7bd0d318@github.com>
 <SaaVYD-4_VVc5MjQ4qDYSobqdka_TYfBXKTIpPW0QwU=.d970e181-f3c9-4712-b19f-b63bfc67eeac@github.com>
 <w3dOEMwp8dm79cQzma_obHcEf9cs5wjAQASB_B94iwM=.caf9c686-425f-4426-bcee-c8216f17d382@github.com>
 <iymqtQuj4_LpboWmdGSD5GgmOeHEz-Mmv0r
 NFcWLrO0=.4cbd3fee-9f08-40be-b635-5636ac8efb4d@github.com>
 <OPxQigxTl_ro8RswIJw4V5dcKAt_XQyA3LlmHEamz_k=.7470afce-9a31-4035-a4e2-dd455772581c@github.com>
 <q7WClEuAxTknvj0OzHu2zSJJpE5I6F70Lq-lTqI5JgA=.172745fa-d90e-443d-9610-eed503083e96@github.com>
 <lpEkr6P1eaApuYtQ0CjthLuRbDx9E2BUAIXJMxY72M0=.c17e2502-ff07-4060-8522-a2a16319d36f@github.com>
Message-ID: <Akt3DizRh5iGdAOTS3OSZ-K_cRKSY8d9znHwl8A6-G4=.5bd7d83b-3b0e-434f-94d2-f852ec7595e3@github.com>

On Fri, 13 Jan 2023 16:06:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Something seems to be up with the lint description for this-escape - compare this:
>> 
>> Oops, will fix - thanks.
>
>> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files
> 
> Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)".

Oops, you're right, I answered the wrong question so to speak.

The "must involve a subclass" requirement is another dimension on which a "boundary" was declared. This was also part of the original discussion.

So yes the requirement is: "requires involvement of a subclass" **AND** "that subclass lives in a separate compilation unit".

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 16:23:42 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 16:23:42 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
Message-ID: <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>

On Fri, 13 Jan 2023 16:12:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy.
>> 
>> I'm happy to fix this if you think it is necessary though.
>
> I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration

Sounds good - thanks.

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

PR: https://git.openjdk.org/jdk/pull/11874

From iris at openjdk.org  Fri Jan 13 17:05:24 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Jan 2023 17:05:24 GMT
Subject: RFR: 8300077: Refactor code examples to use @snippet in
 java.text.ChoiceFormat
In-Reply-To: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
References: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
Message-ID: <o4RC6PV16IlMz45zRxQrniVydDBhSTSWirdPTaT9GEk=.96650dee-0e23-4c74-b5fa-47117d4ceef0@github.com>

On Thu, 12 Jan 2023 22:31:24 GMT, Justin Lu <duke at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11981

From vromero at openjdk.org  Fri Jan 13 17:38:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 17:38:27 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
Message-ID: <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>

On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
> 
>  - Fix bug where all but the last yeild statement were being ignored.
>  - Add method RefSet.mapInto() and use to refactor/clean up.
>  - Fix possible assertion failure when handling if statements.
>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>    
>    Suggested-by:   mcimadamore
>  - Add comment regarding limitations of expresison type filtering.
>  - Add a few more DISABLED_WARNINGS to unbreak build.
>  - Clean up handling of switch expressions a bit.
>  - Remove unused method variant of analyzeTree().
>  - Avoid all caps in comments.
>  - Clarify confusing comment.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:

> 683: 
> 684:     @Override
> 685:     public void visitDoLoop(JCDoWhileLoop tree) {

I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 17:45:51 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 17:45:51 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v4]
In-Reply-To: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
Message-ID: <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>

> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
> 
> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

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

  Add trailing ; to code examples

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11955/files
  - new: https://git.openjdk.org/jdk/pull/11955/files/a2f57899..1e9fee12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11955&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11955.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11955/head:pull/11955

PR: https://git.openjdk.org/jdk/pull/11955

From naoto at openjdk.org  Fri Jan 13 17:50:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 17:50:20 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v4]
In-Reply-To: <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
Message-ID: <jWQRsHKi-TRgUozKgE0d7RldPCz_pRCGeUc7_bbyJ5A=.c9d1443d-3380-4ecf-9660-214e2d4a1e0f@github.com>

On Fri, 13 Jan 2023 17:45:51 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add trailing ; to code examples

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11955

From naoto at openjdk.org  Fri Jan 13 17:51:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 17:51:19 GMT
Subject: RFR: 8300077: Refactor code examples to use @snippet in
 java.text.ChoiceFormat
In-Reply-To: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
References: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
Message-ID: <w8VjSNoKHrqBQjYLwI0ea9gNEOKrVu7Ga9D8uHf9hg0=.5ce7ce95-7d26-4c07-98e8-1b4e517f1fbd@github.com>

On Thu, 12 Jan 2023 22:31:24 GMT, Justin Lu <duke at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11981

From duke at openjdk.org  Fri Jan 13 17:52:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 17:52:31 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
Message-ID: <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>

On Fri, 13 Jan 2023 17:35:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision:
>> 
>>  - Fix bug where all but the last yeild statement were being ignored.
>>  - Add method RefSet.mapInto() and use to refactor/clean up.
>>  - Fix possible assertion failure when handling if statements.
>>  - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff.
>>    
>>    Suggested-by:   mcimadamore
>>  - Add comment regarding limitations of expresison type filtering.
>>  - Add a few more DISABLED_WARNINGS to unbreak build.
>>  - Clean up handling of switch expressions a bit.
>>  - Remove unused method variant of analyzeTree().
>>  - Avoid all caps in comments.
>>  - Clarify confusing comment.
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:
> 
>> 683: 
>> 684:     @Override
>> 685:     public void visitDoLoop(JCDoWhileLoop tree) {
> 
> I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document

Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree).

The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening.

Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more.

Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives.

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

PR: https://git.openjdk.org/jdk/pull/11874

From lancea at openjdk.org  Fri Jan 13 17:50:23 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Jan 2023 17:50:23 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v4]
In-Reply-To: <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
Message-ID: <kME0JyEMG6bnkoItwGa7oamtZXRmW4wyD0ZxvL-mhZM=.f1d9efe8-f529-4afa-bae3-05d7474d1294@github.com>

On Fri, 13 Jan 2023 17:45:51 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add trailing ; to code examples

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Fri Jan 13 18:17:21 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 18:17:21 GMT
Subject: Integrated: 8299865: Unnecessary NullPointerException catch in
 java.util.TimeZone#setDefaultZone
In-Reply-To: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
References: <BfJSeDqqqu_f882MZS9Ek4d8bkyHNqsE8BfkX68URW4=.470eb773-2284-41f2-856b-6c517d9fd662@github.com>
Message-ID: <ieIt6u8LPz0d8YaF9ZRdwXTnByjHhA1xS9JWXkwx4_8=.fd44d8c3-5c5e-4884-9b6e-90732c738937@github.com>

On Wed, 11 Jan 2023 17:12:39 GMT, Justin Lu <duke at openjdk.org> wrote:

> In [JDK-4368016](https://bugs.openjdk.org/browse/JDK-4368016) **TimeZone.setDefaultZone()** was updated so that 
> 
> _TimeZone.java [will] not cause an NPE. If getSystemTimeZoneID()
> can't determine the time zone from java.home and user.region properties,
> it returns GMT._ 
> 
> This change updates the code to get rid of the no longer needed Try Catch

This pull request has now been integrated.

Changeset: 500b45e1
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/500b45e12dccc254e2d1cbd9513653ae939ef349
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8299865: Unnecessary NullPointerException catch in java.util.TimeZone#setDefaultZone

Reviewed-by: lancea, iris, naoto, aturbanov

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

PR: https://git.openjdk.org/jdk/pull/11951

From iris at openjdk.org  Fri Jan 13 18:27:32 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Jan 2023 18:27:32 GMT
Subject: RFR: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone [v4]
In-Reply-To: <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
 <V1IPdg8SDi-3hnil0r1Fq0XcTcUqd0b0QcjNO7yvQEQ=.04b4382d-92e4-4e6a-9082-8651a97dbc1f@github.com>
Message-ID: <_n1cga2Z7vG6iHD3P5vFzOnOL7Fsk956KG1B51AwtSc=.59403f74-386e-4d78-a5d4-6f8e312fc587@github.com>

On Fri, 13 Jan 2023 17:45:51 GMT, Justin Lu <duke at openjdk.org> wrote:

>> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
>> 
>> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add trailing ; to code examples

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Fri Jan 13 19:09:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 19:09:54 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Use more idiomatic test for java.lang.Object.
 - Revert 27cb30129; the error was actually fixed in edf3c3f51.
 - Fix formatting issue with the "this-escape" --help-lint description.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/edf3c3f5..ae37ff7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=07-08

  Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From naoto at openjdk.org  Fri Jan 13 19:18:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 19:18:46 GMT
Subject: RFR: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows [v2]
In-Reply-To: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
References: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
Message-ID: <Xmv1EhUq7gm4w0I_Z_R2xZ0NunHO1gHGu8tmTv8Y_MM=.ebbdf949-c78f-4be3-b1aa-e6c897bfba9f@github.com>

> Fixing a regression caused by the fix to [JDK-8298971](https://bugs.openjdk.org/browse/JDK-8298971). The previous fix lacked the native part change on Windows.

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

  Avoid sharing stdin handle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11973/files
  - new: https://git.openjdk.org/jdk/pull/11973/files/ee2ac0e7..7b8e41db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11973&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11973&range=00-01

  Stats: 19 lines in 2 files changed: 6 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11973.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11973/head:pull/11973

PR: https://git.openjdk.org/jdk/pull/11973

From vromero at openjdk.org  Fri Jan 13 19:20:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 19:20:29 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <wxT3bVsXu8ROOdCWs6975IjcpTAKUB_5tPlycMAzBR0=.5230d005-2c21-44b5-84cb-f440b4837cc9@github.com>
 <ZXer0jyh2vZo7gyCQZUJX-I2zzF6MpPhUCFeFaVj75o=.d0971f3f-8fc5-40e2-8e07-3b476bb2c55c@github.com>
Message-ID: <9xqxePs8UvBJIyPMojy6Bjbl7h3VguJcIwjFhbPr_78=.5ed61dac-21e7-4214-8faf-85f5612f5b46@github.com>

On Fri, 13 Jan 2023 17:49:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685:
>> 
>>> 683: 
>>> 684:     @Override
>>> 685:     public void visitDoLoop(JCDoWhileLoop tree) {
>> 
>> I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document
>
> Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree).
> 
> The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening.
> 
> Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more.
> 
> Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives.

yep I agree

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

PR: https://git.openjdk.org/jdk/pull/11874

From naoto at openjdk.org  Fri Jan 13 19:34:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 19:34:15 GMT
Subject: RFR: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows
In-Reply-To: <fS_6tjRDWhk-NszWvZO1eNpCux1U6aheKVdf94gS7eU=.fe920127-7af9-43d8-8628-d4b7f7fbd331@github.com>
References: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
 <fS_6tjRDWhk-NszWvZO1eNpCux1U6aheKVdf94gS7eU=.fe920127-7af9-43d8-8628-d4b7f7fbd331@github.com>
Message-ID: <LxijysCzASjisbGYQRNqI0GsgWkz5cID6nsi5R2E9mI=.2d5e0329-b170-4b1d-9032-a93397d856ee@github.com>

On Fri, 13 Jan 2023 14:12:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should try to have a cleaner separation between these native methods. If JdkConsoleImpl_echo is changed to call GetStdHandle(STD_INPUT_HANDLE) then it would avoid needing Console_md to export java_io_Console_hStdIn. It would mean the static fields in Console_md could be removed too.

Thanks, Alan. Modified the code not to share the handles.

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

PR: https://git.openjdk.org/jdk/pull/11973

From vromero at openjdk.org  Fri Jan 13 20:19:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 20:19:53 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
Message-ID: <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>

On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use more idiomatic test for java.lang.Object.
>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>  - Fix formatting issue with the "this-escape" --help-lint description.

test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8:

> 6:  */
> 7: 
> 8: public class ThisEscapeBasic {

I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files.

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

PR: https://git.openjdk.org/jdk/pull/11874

From vromero at openjdk.org  Fri Jan 13 20:24:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 20:24:46 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
Message-ID: <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>

On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use more idiomatic test for java.lang.Object.
>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>  - Fix formatting issue with the "this-escape" --help-lint description.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:

> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
> 1087:         visitScoped(tree, false, t -> {
> 1088:             while (true) {

I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 20:56:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 13 Jan 2023 20:56:19 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories
Message-ID: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>

Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.

The mentioned call sites needs updates to check and ignore such files.

A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

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

Commit messages:
 - Merge branch 'master' into signature-related-subdirs
 - Files residing in subdirectories of META-INF/ should not be treated as signature related

Changes: https://git.openjdk.org/jdk/pull/11976/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300140
  Stats: 235 lines in 5 files changed: 227 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Fri Jan 13 21:14:45 2023
From: duke at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 21:14:45 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v4]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <_iB1IUdoG1MkqcP1CA2RNHfva_kL-bnC7sYI-lMwgYU=.63baa4cd-b372-4202-a8c8-050c61a32cc1@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.
> 
> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_

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

  Change @ throws to account for external subclassing of TimeZone

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/ae49f170..a8059d50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/11888

From duke at openjdk.org  Fri Jan 13 21:23:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:23:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <CodWhrjrsXJw6ibUoeqFzUfN-D7ME9Czwq4NTCGPuW0=.5de7c798-3820-4266-abaf-7d614cbf1b25@github.com>
Message-ID: <dQ-a4bBPdZfPNchKmqNSTVi_MwWV8XHC8toQ5Os8MR8=.fbfb559d-5ba6-4f14-8ec3-5eb1fab8215b@github.com>

On Fri, 13 Jan 2023 20:16:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use more idiomatic test for java.lang.Object.
>>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>>  - Fix formatting issue with the "this-escape" --help-lint description.
>
> test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8:
> 
>> 6:  */
>> 7: 
>> 8: public class ThisEscapeBasic {
> 
> I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files.

I really don't have any informed opinion on this. I can see arguments both ways... putting all you eggs in one basket can be seen alternately as foolhardy or highly efficient :)

FWIW in the past I've had problems with trying to combine multiples tests that generate errors into one file. The compiler seems to like to bail out early when it sees errors. I guess that experience was working subconsciously.

Of course that doesn't apply here as these are all warnings. And a bunch of separate files make the test run slower.

So I agree with you - I'll consolidate them.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 21:31:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:31:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
Message-ID: <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>

On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use more idiomatic test for java.lang.Object.
>>  - Revert 27cb30129; the error was actually fixed in edf3c3f51.
>>  - Fix formatting issue with the "this-escape" --help-lint description.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:
> 
>> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>> 1087:         visitScoped(tree, false, t -> {
>> 1088:             while (true) {
> 
> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times

The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.

That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).

If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Jan 13 21:36:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 21:36:30 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
 <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
Message-ID: <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>

On Fri, 13 Jan 2023 16:20:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration
>
> Sounds good - thanks.

Ah. I just realized that we need to do it your way because of the following bug:

Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor.

Then the leak for the field will never be reported because we never get to it.

I'll fix.

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

PR: https://git.openjdk.org/jdk/pull/11874

From darcy at openjdk.org  Fri Jan 13 21:52:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jan 2023 21:52:55 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
Message-ID: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>

With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

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

Commit messages:
 - JDK-8300133: Use generalized see and link tags in core libs

Changes: https://git.openjdk.org/jdk/pull/12000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300133
  Stats: 107 lines in 10 files changed: 0 ins; 19 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/12000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12000/head:pull/12000

PR: https://git.openjdk.org/jdk/pull/12000

From jlu at openjdk.org  Fri Jan 13 21:55:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 21:55:01 GMT
Subject: [jdk20] RFR: 8299498: Usage of constructors of primitive wrapper
 classes should be avoided in java.lang API docs
Message-ID: <R0fjJrupa8Lpzz8u2rY9VJcPCL5Xz9H-8riCLtn7BNM=.3ae2c226-cd79-4cd4-be4c-d66384417107@github.com>

This pull request contains a backport of commit [d663b5da](https://github.com/openjdk/jdk/commit/d663b5da10be1f3f33a2729e4b3605fb5e13b4d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 11 Jan 2023 and was reviewed by Naoto Sato, Joe Darcy, Roger Riggs, Mandy Chung and Lance Andersen.

Thank you

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

Commit messages:
 - Backport d663b5da10be1f3f33a2729e4b3605fb5e13b4d6

Changes: https://git.openjdk.org/jdk20/pull/104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299498
  Stats: 22 lines in 7 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk20/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/104/head:pull/104

PR: https://git.openjdk.org/jdk20/pull/104

From jlu at openjdk.org  Fri Jan 13 21:58:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 21:58:03 GMT
Subject: RFR: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
Message-ID: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

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

Commit messages:
 - Switch code blocks with snippet

Changes: https://git.openjdk.org/jdk/pull/12001/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300093
  Stats: 24 lines in 1 file changed: 12 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12001.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12001/head:pull/12001

PR: https://git.openjdk.org/jdk/pull/12001

From jlu at openjdk.org  Fri Jan 13 21:58:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 21:58:17 GMT
Subject: [jdk20] RFR: 8299501: Usage of constructors of primitive wrapper
 classes should be avoided in java.util API docs
Message-ID: <3_RtXlpQJNoxcHJs2g4dkDSlcJicGaVqB_tk51KnsDg=.55660d51-d85c-47d7-b739-925e4f760e3e@github.com>

This pull request contains a backport of commit [f36f1354](https://github.com/openjdk/jdk/commit/f36f1354c63a500c70ae51a9c2b2d21ad55cfa77) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Naoto Sato and Lance Andersen.

Thanks!

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

Commit messages:
 - Backport f36f1354c63a500c70ae51a9c2b2d21ad55cfa77

Changes: https://git.openjdk.org/jdk20/pull/105/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299501
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk20/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/105/head:pull/105

PR: https://git.openjdk.org/jdk20/pull/105

From jlu at openjdk.org  Fri Jan 13 22:02:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 22:02:23 GMT
Subject: [jdk20] RFR: 8299500: Usage of constructors of primitive wrapper
 classes should be avoided in java.text API docs
Message-ID: <eJNK4npxdoYsuyAseyxGVcmqsYwx_QTMeRB0vZ8DCGk=.f8da33dc-ca5f-4c90-9b23-4bd65c966d75@github.com>

This pull request contains a backport of commit [cd10c727](https://github.com/openjdk/jdk/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Naoto Sato and Lance Andersen.

Thanks!

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

Commit messages:
 - Backport cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6

Changes: https://git.openjdk.org/jdk20/pull/106/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299500
  Stats: 8 lines in 2 files changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk20/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/106/head:pull/106

PR: https://git.openjdk.org/jdk20/pull/106

From vromero at openjdk.org  Fri Jan 13 22:04:03 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Jan 2023 22:04:03 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v8]
In-Reply-To: <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <wjraXnWh0Caba54H7j9YY9UKErXq_9wKElOgsvI8nuc=.0c42b361-a0eb-4c0f-a456-ce82c17237cf@github.com>
 <UiXxkJII_OrkCKyMYxiZWUQ2iiLwjcrAByp_b4_vZv0=.a0fe5083-5e0c-444a-b1ee-703608294bff@github.com>
 <RxcA0c13Q-Eh6cX1sjxDxaht8zI3Su8pIEkPSETbiTY=.cacec2de-8f7a-48d1-81f8-f6dca591e9ec@github.com>
 <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com>
 <ZrdBJxwqM9KOsvWVdX6dHDpHYcrvk8CPcc7qi5TJiPM=.b1881ed0-3613-45fb-af82-468e64040796@github.com>
 <LsUhJCqzH-_ufn6NlYb8oplhN6Q2lv1mzCQfnUNqDMg=.d29ca327-2d18-447b-af4e-95dcc9d16236@github.com>
Message-ID: <1ylDnjbWJwdsJP-dVL1zthfhVHZbcOgnC3gxgNuKBZk=.6367e3b4-18ae-4232-b43a-c469e58f9a2d@github.com>

On Fri, 13 Jan 2023 21:33:02 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Sounds good - thanks.
>
> Ah. I just realized that we need to do it your way because of the following bug:
> 
> Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor.
> 
> Then the leak for the field will never be reported because we never get to it.
> 
> I'll fix.

yep, right in that case that leak wouldn't be reported

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

PR: https://git.openjdk.org/jdk/pull/11874

From jlu at openjdk.org  Fri Jan 13 22:08:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 22:08:41 GMT
Subject: [jdk20] RFR: 8299502: Usage of constructors of primitive wrapper
 classes should be avoided in javax.xml API docs
Message-ID: <3SyY8LxQ3jqhhYcxz2izD1vcibmE0-6mawFkORm6co0=.f4d805ac-fd6a-4655-b126-343ef6607d2d@github.com>

This pull request contains a backport of commit [b8852f65](https://github.com/openjdk/jdk/commit/b8852f65a0adcb9ee5693bb6727a0668aa9808bf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Joe Wang, Naoto Sato and Lance Andersen.

Thanks!

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

Commit messages:
 - Backport b8852f65a0adcb9ee5693bb6727a0668aa9808bf

Changes: https://git.openjdk.org/jdk20/pull/107/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299502
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/107.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/107/head:pull/107

PR: https://git.openjdk.org/jdk20/pull/107

From iris at openjdk.org  Fri Jan 13 22:11:00 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Jan 2023 22:11:00 GMT
Subject: RFR: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
In-Reply-To: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
References: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
Message-ID: <wLbZPeSyXQXDErYCc2TtM7kSueKe4QBHa65V96LC2Ww=.53d696ee-bc4e-467f-91a5-cd5de9747e2f@github.com>

On Fri, 13 Jan 2023 21:47:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12001

From iris at openjdk.org  Fri Jan 13 22:15:07 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Jan 2023 22:15:07 GMT
Subject: [jdk20] RFR: 8299500: Usage of constructors of primitive wrapper
 classes should be avoided in java.text API docs
In-Reply-To: <eJNK4npxdoYsuyAseyxGVcmqsYwx_QTMeRB0vZ8DCGk=.f8da33dc-ca5f-4c90-9b23-4bd65c966d75@github.com>
References: <eJNK4npxdoYsuyAseyxGVcmqsYwx_QTMeRB0vZ8DCGk=.f8da33dc-ca5f-4c90-9b23-4bd65c966d75@github.com>
Message-ID: <SvgKzlU3UecX4hlj8GFe7p_BXkCHzc_vHfQKfuSeMgY=.f9a887d2-0f7f-443e-827f-d8c985d5410f@github.com>

On Fri, 13 Jan 2023 21:53:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This pull request contains a backport of commit [cd10c727](https://github.com/openjdk/jdk/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Naoto Sato and Lance Andersen.
> 
> Thanks!

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/106

From jjg at openjdk.org  Fri Jan 13 22:33:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 13 Jan 2023 22:33:13 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
In-Reply-To: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
Message-ID: <GL3iQNQ868XqguVyGBQXvoNlfUJ5QXfFLUeaDtUcmyo=.cd2265cc-f6e1-4947-97db-d2b350d1ede6@github.com>

On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

Nice to see all those `<a href="{@docRoot}/..."` references go away.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12000

From weijun at openjdk.org  Fri Jan 13 22:40:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Jan 2023 22:40:12 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>

On Thu, 12 Jan 2023 18:44:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Just some comments before the end of week.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1748:

> 1746:                 .isBlockOrSF(new String(name, off, len, UTF_8.INSTANCE)
> 1747:                     .toUpperCase(Locale.ENGLISH)));
> 1748: 

How about updating `SignatureFileVerifier.isBlockOrSF` so that it only returns true for files inside `META-INF/`. This way it's consistent to this method.

src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 980:

> 978:      * Returns true iff the entry resides directly in the META-INF/ directory
> 979:      */
> 980:     private boolean isInMetaInf(ZipEntry ze) {

Maybe move this method and the one in `JarVerifier` to a common place like `sun.security.util.SignatureFileVerifier`?

test/jdk/java/util/jar/JarFile/VerifyUnrelatedSignatureFiles.java line 61:

> 59:         File j = createJarFile();
> 60:         File s = signJarFile(j, "signed");
> 61:         File m = moveSignatureRelated(s);

Try sign it again to a different file. Let's see if the moved files are also signed.

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

PR: https://git.openjdk.org/jdk/pull/11976

From naoto at openjdk.org  Fri Jan 13 22:41:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 22:41:12 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
In-Reply-To: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
Message-ID: <AnFmzaFhCPqbDlhKqw1PFBszKd2dOzIfHg_w4msphqo=.a69cd439-29c0-49bf-b87e-ac1b02501603@github.com>

On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

src/java.base/share/classes/java/util/ResourceBundle.java line 270:

> 268:  * are packaged in a JAR file.  Resource bundle only JAR file can be readily
> 269:  * deployed as an {@linkplain java.lang.module.ModuleFinder##automatic-modules
> 270:  * automatic module1}.  For example, if the JAR file contains the

Typo: extra `1`

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

PR: https://git.openjdk.org/jdk/pull/12000

From mchung at openjdk.org  Fri Jan 13 22:46:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 13 Jan 2023 22:46:10 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
In-Reply-To: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
Message-ID: <i1LCnsYL9CNeIelNI5_eP4EuEVJk6B-FoBYzdmfE_jo=.a379409a-b6c4-42d7-849c-e325b34f581a@github.com>

On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

src/java.base/share/classes/java/util/ResourceBundle.java line 270:

> 268:  * are packaged in a JAR file.  Resource bundle only JAR file can be readily
> 269:  * deployed as an {@linkplain java.lang.module.ModuleFinder##automatic-modules
> 270:  * automatic module1}.  For example, if the JAR file contains the

typo : `module1`?

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

PR: https://git.openjdk.org/jdk/pull/12000

From duke at openjdk.org  Fri Jan 13 22:48:59 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 13 Jan 2023 22:48:59 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Fix bug where field initializer warnings could be incorrectly suppressed.
 - Consolidate all the unit tests that generate warnings into one.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/ae37ff7c..0b06dc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=08-09

  Stats: 1454 lines in 35 files changed: 658 ins; 762 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From darcy at openjdk.org  Fri Jan 13 22:54:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jan 2023 22:54:47 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
Message-ID: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>

> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

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

  Fix typo found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12000/files
  - new: https://git.openjdk.org/jdk/pull/12000/files/aa623f2a..0e4d4e4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12000&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12000

From mchung at openjdk.org  Fri Jan 13 22:54:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 13 Jan 2023 22:54:47 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
Message-ID: <1y-NxkBIqDQ4RlBuXC7czlGB-jsPd3m8jNrPD9-wzUk=.9eb0f9d7-a9cc-4791-88c8-b3253ea97607@github.com>

On Fri, 13 Jan 2023 22:50:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12000

From naoto at openjdk.org  Fri Jan 13 22:54:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Jan 2023 22:54:47 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
Message-ID: <0TIQXjqLz5hGjV--Pr4KjUIloBfbXIRlXf5j9EK4TnA=.970794a6-fc1e-4b6b-a82a-9e886abd0111@github.com>

On Fri, 13 Jan 2023 22:50:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

Changes in `ResoruceBundle` look good.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12000

From darcy at openjdk.org  Fri Jan 13 22:54:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jan 2023 22:54:48 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <AnFmzaFhCPqbDlhKqw1PFBszKd2dOzIfHg_w4msphqo=.a69cd439-29c0-49bf-b87e-ac1b02501603@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <AnFmzaFhCPqbDlhKqw1PFBszKd2dOzIfHg_w4msphqo=.a69cd439-29c0-49bf-b87e-ac1b02501603@github.com>
Message-ID: <eKt9806kMYaKXmUlFI27gbptmClaz4e5Cffz8ITt3NM=.d0d988fa-44b2-4993-bec2-eb446f45cd49@github.com>

On Fri, 13 Jan 2023 22:38:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo found in code review.
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 270:
> 
>> 268:  * are packaged in a JAR file.  Resource bundle only JAR file can be readily
>> 269:  * deployed as an {@linkplain java.lang.module.ModuleFinder##automatic-modules
>> 270:  * automatic module1}.  For example, if the JAR file contains the
> 
> Typo: extra `1`

Doh! Thanks; fixed in next push.

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

PR: https://git.openjdk.org/jdk/pull/12000

From dcubed at openjdk.org  Fri Jan 13 23:00:07 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jan 2023 23:00:07 GMT
Subject: [jdk20] Integrated: 8300141: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
Message-ID: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>

Trivial fixes to ProblemList some tests:
[JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
[JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
[JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp

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

Commit messages:
 - 8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp
 - 8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
 - 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC

Changes: https://git.openjdk.org/jdk20/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300141
  Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/103/head:pull/103

PR: https://git.openjdk.org/jdk20/pull/103

From mikael at openjdk.org  Fri Jan 13 23:00:08 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 13 Jan 2023 23:00:08 GMT
Subject: [jdk20] Integrated: 8300141: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
In-Reply-To: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>
References: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>
Message-ID: <7AUdT4EWvKE50d01wgyXV4mxlJIUE5wcfTq2dJFYNuY=.28cc5164-f733-490a-a534-633d840fab5c@github.com>

On Fri, 13 Jan 2023 21:25:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList some tests:
> [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
> [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
> [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/103

From dcubed at openjdk.org  Fri Jan 13 23:00:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jan 2023 23:00:08 GMT
Subject: [jdk20] Integrated: 8300141: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
In-Reply-To: <7AUdT4EWvKE50d01wgyXV4mxlJIUE5wcfTq2dJFYNuY=.28cc5164-f733-490a-a534-633d840fab5c@github.com>
References: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>
 <7AUdT4EWvKE50d01wgyXV4mxlJIUE5wcfTq2dJFYNuY=.28cc5164-f733-490a-a534-633d840fab5c@github.com>
Message-ID: <JVWdrzqOptLIz3s1Lr2zKkPlX41st9TAhyk7H9xNaeQ=.ff27e898-948e-4698-a644-17085cf922b9@github.com>

On Fri, 13 Jan 2023 22:43:09 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Trivial fixes to ProblemList some tests:
>> [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
>> [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
>> [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk20/pull/103

From dcubed at openjdk.org  Fri Jan 13 23:00:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jan 2023 23:00:09 GMT
Subject: [jdk20] Integrated: 8300141: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
In-Reply-To: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>
References: <d0w8K9vIOUE7UtVQz5xPeaWw3nHrQ4ndwMX9aAORc6k=.957cbfc0-c080-467d-912b-9ac90165a8cc@github.com>
Message-ID: <JcO1cI5xycmPym-Gy-QPvVKe8jJOkuaSN4e9GBdMp4g=.1d0ef535-8e64-4319-8eca-98785d9f68e5@github.com>

On Fri, 13 Jan 2023 21:25:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList some tests:
> [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
> [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
> [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp

This pull request has now been integrated.

Changeset: bc498f87
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/bc498f87f7037c37ad9c2a101fee5e39ae6bfda1
Stats:     5 lines in 3 files changed: 3 ins; 0 del; 2 mod

8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC
8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp

Reviewed-by: mikael

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

PR: https://git.openjdk.org/jdk20/pull/103

From jlu at openjdk.org  Fri Jan 13 23:17:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 23:17:10 GMT
Subject: [jdk20] Integrated: 8299498: Usage of constructors of primitive
 wrapper classes should be avoided in java.lang API docs
In-Reply-To: <R0fjJrupa8Lpzz8u2rY9VJcPCL5Xz9H-8riCLtn7BNM=.3ae2c226-cd79-4cd4-be4c-d66384417107@github.com>
References: <R0fjJrupa8Lpzz8u2rY9VJcPCL5Xz9H-8riCLtn7BNM=.3ae2c226-cd79-4cd4-be4c-d66384417107@github.com>
Message-ID: <uCiHUGq-1C9k7VxfglprFWn7Un3CsohH2EhQEn67EpM=.c48732e4-efc7-408f-ba2d-e27596f01112@github.com>

On Fri, 13 Jan 2023 21:44:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This pull request contains a backport of commit [d663b5da](https://github.com/openjdk/jdk/commit/d663b5da10be1f3f33a2729e4b3605fb5e13b4d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 11 Jan 2023 and was reviewed by Naoto Sato, Joe Darcy, Roger Riggs, Mandy Chung and Lance Andersen.
> 
> Thank you

This pull request has now been integrated.

Changeset: ab7f43f0
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/ab7f43f0801eeb6b0514f5e8241404c13c04269d
Stats:     22 lines in 7 files changed: 0 ins; 0 del; 22 mod

8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs

Backport-of: d663b5da10be1f3f33a2729e4b3605fb5e13b4d6

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

PR: https://git.openjdk.org/jdk20/pull/104

From jlu at openjdk.org  Fri Jan 13 23:19:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 23:19:12 GMT
Subject: [jdk20] Integrated: 8299501: Usage of constructors of primitive
 wrapper classes should be avoided in java.util API docs
In-Reply-To: <3_RtXlpQJNoxcHJs2g4dkDSlcJicGaVqB_tk51KnsDg=.55660d51-d85c-47d7-b739-925e4f760e3e@github.com>
References: <3_RtXlpQJNoxcHJs2g4dkDSlcJicGaVqB_tk51KnsDg=.55660d51-d85c-47d7-b739-925e4f760e3e@github.com>
Message-ID: <Dv82Qgn9RCVbB8K0Ga-NRtcFK76QgJagbFUQRIXygcQ=.fb8f4b10-a739-4f73-94ac-11791468172e@github.com>

On Fri, 13 Jan 2023 21:50:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This pull request contains a backport of commit [f36f1354](https://github.com/openjdk/jdk/commit/f36f1354c63a500c70ae51a9c2b2d21ad55cfa77) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Naoto Sato and Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 628266af
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/628266af60b054903fccd1582972acb2c998f1d4
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs

Backport-of: f36f1354c63a500c70ae51a9c2b2d21ad55cfa77

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

PR: https://git.openjdk.org/jdk20/pull/105

From jlu at openjdk.org  Fri Jan 13 23:20:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 23:20:11 GMT
Subject: [jdk20] Integrated: 8299500: Usage of constructors of primitive
 wrapper classes should be avoided in java.text API docs
In-Reply-To: <eJNK4npxdoYsuyAseyxGVcmqsYwx_QTMeRB0vZ8DCGk=.f8da33dc-ca5f-4c90-9b23-4bd65c966d75@github.com>
References: <eJNK4npxdoYsuyAseyxGVcmqsYwx_QTMeRB0vZ8DCGk=.f8da33dc-ca5f-4c90-9b23-4bd65c966d75@github.com>
Message-ID: <N8kWCXr4KyBN9SvX2fk2LKwl5geOMJBsu4zgBurnpA4=.b6c807ca-81e0-484d-9fce-86b20a35088c@github.com>

On Fri, 13 Jan 2023 21:53:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This pull request contains a backport of commit [cd10c727](https://github.com/openjdk/jdk/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Naoto Sato and Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 98eae6da
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/98eae6dade075c6e58ad0379d0b3b38b75836994
Stats:     8 lines in 2 files changed: 0 ins; 1 del; 7 mod

8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs

Reviewed-by: iris
Backport-of: cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6

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

PR: https://git.openjdk.org/jdk20/pull/106

From jlu at openjdk.org  Fri Jan 13 23:22:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Jan 2023 23:22:11 GMT
Subject: [jdk20] Integrated: 8299502: Usage of constructors of primitive
 wrapper classes should be avoided in javax.xml API docs
In-Reply-To: <3SyY8LxQ3jqhhYcxz2izD1vcibmE0-6mawFkORm6co0=.f4d805ac-fd6a-4655-b126-343ef6607d2d@github.com>
References: <3SyY8LxQ3jqhhYcxz2izD1vcibmE0-6mawFkORm6co0=.f4d805ac-fd6a-4655-b126-343ef6607d2d@github.com>
Message-ID: <T2a1z9MtwA4DXNoUt0CSpvRW0ikZR8yfODoXxiYbaVY=.f4ce303f-ec40-4737-8861-c87cf4ce9d12@github.com>

On Fri, 13 Jan 2023 22:00:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This pull request contains a backport of commit [b8852f65](https://github.com/openjdk/jdk/commit/b8852f65a0adcb9ee5693bb6727a0668aa9808bf) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 9 Jan 2023 and was reviewed by Joe Wang, Naoto Sato and Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 87865e0e
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/87865e0eb8af6a23263494f3397ee01c7eccb1b8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs

Backport-of: b8852f65a0adcb9ee5693bb6727a0668aa9808bf

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

PR: https://git.openjdk.org/jdk20/pull/107

From duke at openjdk.org  Sat Jan 14 01:57:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 14 Jan 2023 01:57:32 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v7]
In-Reply-To: <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <jifmx2sv9puE_sqDgPRaFXJTzjl2dw3DY-9SuVxSVF8=.71f8e556-a319-4c3d-b3ed-77ab3cfe9d43@github.com>
 <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com>
 <GsSPuxe0ie3biMMwvqKOIyZ5k_oewT3iDke9xRxVE0s=.ac8be66f-537d-4ecf-b3d7-05eb91d271cc@github.com>
 <Ig5EdKTlYvkBQ3LAgeAiXCZpSKkUept3Ch8tW7RAO78=.5b361b5a-8df9-41b2-b78c-7580acacd939@github.com>
 <db_e6O3GAPZPRU1kJGawP19tAb-DmiNduGa51LCD4VE=.1b70448a-7b9b-4d99-9828-e3186c13a73c@github.com>
 <Piegj-aQWN-4MPZoB-zt1IW9Jp_OPCDfFvvpOVdGDkI=.74995898-e2c1-42c7-8362-408668a49561@github.com>
 <w3FeW11M6pr-DOmW1v_4Doa9t52s55Pedi5fnOOarbc=.aa10dd51-0ff0-40ad-977e-7091fea00d4e@github.com>
Message-ID: <xUWBWB697H5u_kP4Wc3YFEVltggLUgqef3nf6qksjzM=.eb97c793-0249-453a-bfa8-b660b2176cbf@github.com>

On Fri, 13 Jan 2023 00:57:14 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.
>
>>  Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern.
> 
> You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science.
> 
>> I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it.
> 
> That's a nice idea... thanks. I'll play around with it some.

I was curious how much of a difference this type filtering makes, so I built the JDK with and without it.

The results were identical except for one case:

package java.lang.invoke;
...
public abstract sealed class CallSite permits ConstantCallSite, MutableCallSite, VolatileCallSite {
...
    CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
        this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook
        ConstantCallSite selfCCS = (ConstantCallSite) this;
        MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
        setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target
        UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
    }

When we do type filtering, `(ConstantCallSite) this` causes the 'this' reference to be discarded so no leak is reported on the next line for `invokeWithArguments(selfCCS)`. Just a side note, there is also a leak on the next line because final method `setTargetNormal()` invokes `MethodHandleNatives.setCallSiteTargetNormal(this, newTarget)`, so a leak does get reported anyway even with type filtering.

When type filtering is disabled, we report a leak at `invokeWithArguments(selfCCS)` - which is accurate.

So what did we learn?

First it looks like type filtering has very minimal effect. I think this is because it requires some version of two casts in a row in and out of type compatibility, and this is probably very rare.

But looking at the one data point we do have, the type filtering did in fact cause a false negative.

And when building the entire JDK, it causes zero net new false positives.

So to me this is evidence that we should just remove the type filtering altogether...

@vicente-romero-oracle your thoughts?

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

PR: https://git.openjdk.org/jdk/pull/11874

From smarks at openjdk.org  Sat Jan 14 03:45:10 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 14 Jan 2023 03:45:10 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for
 Entry.setValue
In-Reply-To: <oKstKPktbEWt6y9o9hK8_6tmxPQS05r3_XonT6Obu4c=.e60ce581-43cf-45f3-afb0-e737877fac71@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
 <oKstKPktbEWt6y9o9hK8_6tmxPQS05r3_XonT6Obu4c=.e60ce581-43cf-45f3-afb0-e737877fac71@github.com>
Message-ID: <-xELIuVSFyKIY6DkSH87vbe-wCRSuE6zyRNpX30LpIM=.20e295d9-6474-42fe-b40f-f5bd92e0604e@github.com>

On Fri, 13 Jan 2023 15:02:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.
>
> src/java.base/share/classes/java/util/Map.java line 405:
> 
>> 403:      * {@link Iterator} or implicitly via the enhanced {@code for} statement. This connection
>> 404:      * to the backing map is valid <i>only</i> during iteration of the entry-set view. During
>> 405:      * the iteration, if supported by the backing map, a change to a Entry's value via
> 
> "a Entry's value" -> "an Entry's value" or "the value of an Entry" ?

Changed to "an Entry's Value".

> src/java.base/share/classes/java/util/NavigableMap.java line 80:
> 
>> 78:  * return {@link Map.Entry} instances that represent snapshots of mappings as
>> 79:  * of the time of the call, and they do <em>not</em> support mutation of the
>> 80:  * underlying map via the optional {@link Map.Entry#setValue setValue} method.
> 
> I think it would be a bit more readable to put to break after "as of the time of the call", either a full stop or "; they".  Same thing in TreeMap.

Done.

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

PR: https://git.openjdk.org/jdk/pull/11956

From smarks at openjdk.org  Sat Jan 14 03:49:11 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 14 Jan 2023 03:49:11 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for
 Entry.setValue
In-Reply-To: <oKstKPktbEWt6y9o9hK8_6tmxPQS05r3_XonT6Obu4c=.e60ce581-43cf-45f3-afb0-e737877fac71@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
 <oKstKPktbEWt6y9o9hK8_6tmxPQS05r3_XonT6Obu4c=.e60ce581-43cf-45f3-afb0-e737877fac71@github.com>
Message-ID: <3Vx16hDGBCR4lUGHYR9guuYHxTveWs_m4yx81NN2ePQ=.8d7cedd9-faaf-47b3-be8a-48f18f73cd87@github.com>

On Fri, 13 Jan 2023 15:04:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.
>
> src/java.base/share/classes/java/util/Map.java line 421:
> 
>> 419:      * {@link Set#toArray toArray} overloads,
>> 420:      * or by copying the entry-set view into another collection. It is unspecified whether
>> 421:      * the Entry instances thus obtained are connected to the underlying map, whether
> 
> It might be a bit clearer if tweaked to "whether the obtained Entry instances are connected".

OK. I also tweaked a bit of wording nearby, including changing "extracted" to "obtained" at the start of this paragraph in order to strengthen the connection to this clause.

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

PR: https://git.openjdk.org/jdk/pull/11956

From smarks at openjdk.org  Sat Jan 14 03:56:33 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 14 Jan 2023 03:56:33 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for
 Entry.setValue [v2]
In-Reply-To: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
Message-ID: <lPhKYWfmQfSG27tZitJPu1DYQMtMQQ4fhqRQyUGDwak=.fbe883c0-859a-44a9-b41a-c2ac140c493b@github.com>

> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.

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

  Updates from Alan.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11956/files
  - new: https://git.openjdk.org/jdk/pull/11956/files/5934dd01..8828110b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11956&range=00-01

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11956/head:pull/11956

PR: https://git.openjdk.org/jdk/pull/11956

From alanb at openjdk.org  Sat Jan 14 08:15:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Jan 2023 08:15:09 GMT
Subject: RFR: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows [v2]
In-Reply-To: <Xmv1EhUq7gm4w0I_Z_R2xZ0NunHO1gHGu8tmTv8Y_MM=.ebbdf949-c78f-4be3-b1aa-e6c897bfba9f@github.com>
References: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
 <Xmv1EhUq7gm4w0I_Z_R2xZ0NunHO1gHGu8tmTv8Y_MM=.ebbdf949-c78f-4be3-b1aa-e6c897bfba9f@github.com>
Message-ID: <bEMzKh04tlKVojL0CqyRClN-1b_Esb9AE9XPSLuBYPI=.d7a59859-17e0-4c04-b2a7-262d753adcaa@github.com>

On Fri, 13 Jan 2023 19:18:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing a regression caused by the fix to [JDK-8298971](https://bugs.openjdk.org/browse/JDK-8298971). The previous fix lacked the native part change on Windows.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid sharing stdin handle

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11973

From alanb at openjdk.org  Sat Jan 14 08:40:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Jan 2023 08:40:10 GMT
Subject: RFR: 8038146: Clarify NavigableMap/TreeMap support for
 Entry.setValue [v2]
In-Reply-To: <lPhKYWfmQfSG27tZitJPu1DYQMtMQQ4fhqRQyUGDwak=.fbe883c0-859a-44a9-b41a-c2ac140c493b@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
 <lPhKYWfmQfSG27tZitJPu1DYQMtMQQ4fhqRQyUGDwak=.fbe883c0-859a-44a9-b41a-c2ac140c493b@github.com>
Message-ID: <paftGYE7xCxG7tU3Se5KE0rN8QuBhkqdifMRs7jTPoY=.a0b7d698-d018-424b-a660-87ec8e79c69c@github.com>

On Sat, 14 Jan 2023 03:56:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates from Alan.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11956

From jvernee at openjdk.org  Sat Jan 14 10:23:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 14 Jan 2023 10:23:10 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
Message-ID: <vV6yIgG-Q4EKobuFlIAYZ8mndQ9VsKHTPRoqA0Mlxtw=.cdf8dcdf-f081-45c0-aecc-c9475a756595@github.com>

On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix callArranger

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11004

From duke at openjdk.org  Sat Jan 14 12:05:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 14 Jan 2023 12:05:10 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories
In-Reply-To: <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
Message-ID: <UCsro35XQhSOoB-nQEfp_JJ2JlxbkMzBHJOSlK0XmkA=.5911e2e8-b406-43eb-92c1-3d4bb5bd5306@github.com>

On Fri, 13 Jan 2023 22:31:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
>> 
>> The mentioned call sites needs updates to check and ignore such files.
>> 
>> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1748:
> 
>> 1746:                 .isBlockOrSF(new String(name, off, len, UTF_8.INSTANCE)
>> 1747:                     .toUpperCase(Locale.ENGLISH)));
>> 1748: 
> 
> How about updating `SignatureFileVerifier.isBlockOrSF` so that it only returns true for files inside `META-INF/`. This way it's consistent to this method.

I started there, but ran into some problems:

SignatureFileVerifier.isSigningRelated calls isBlockOrSF, but it removes the "META-INF/" prefix from the path first. So we can't assume that input to isBlockOrSF is the full path.

I could update SignatureFileVerifier.isSigningRelated to send the full path, but we still have another problem:

JarSigner.sign0 puts META-INF/ files in a vector, such that it can output them first. We want to update this method such that it outputs only files which live directly in META-INF/ first. So we still need to check for "directness" outside isBlockOrSF.

isBlockOrSF has 8 call sites, most of them in security sensitive and tricky code. In the end, I felt safer leaving isBlockOrSF alone and just fix the bug-relevant call sites instead. Also, being a new contributor to security-dev, I wanted to keep the PR relatively simple and easy to review.

WDYT?

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

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sat Jan 14 12:17:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 14 Jan 2023 12:17:09 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories
In-Reply-To: <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
Message-ID: <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>

On Fri, 13 Jan 2023 22:36:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
>> 
>> The mentioned call sites needs updates to check and ignore such files.
>> 
>> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.
>
> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 980:
> 
>> 978:      * Returns true iff the entry resides directly in the META-INF/ directory
>> 979:      */
>> 980:     private boolean isInMetaInf(ZipEntry ze) {
> 
> Maybe move this method and the one in `JarVerifier` to a common place like `sun.security.util.SignatureFileVerifier`?

This duplicated check annoyed me also, but the existing checks have different behavior:

- JarVerifier.beginEntry normalizes the path to uppercase, them checks that it starts with "META-INF/" or "/META-INF/"
- JarSigner.sign0 does not normalize to uppercase , then checks that the path starts with "META-INF/"

Introducing a common method would need change behaviour of one of these methods. This change of behaviour would not be relevant to the bug being fixed in this PR.

Since I'm cautious of changing behaviour, I decided to keep the two methods.

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

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sat Jan 14 13:21:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 14 Jan 2023 13:21:43 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v2]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <1bc5eaRMn8lxh_J9-83_9C8gKpMY47JaJUc-t3REtEQ=.b55308cd-46e3-4595-b229-e6f6eb62cc8b@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos 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:

 - Check that non-signature related .SF, .RSA files are treated as regular (non signature related) files during signing
 - Merge branch 'master' into signature-related-subdirs
 - Simplify comment by removing a negative and changing "these paths" to "this path"
 - Use @modules tags instead of explicit --add-exports args
 - Merge branch 'master' into signature-related-subdirs
 - Files residing in subdirectories of META-INF/ should not be treated as signature related

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/342b3c20..828e083c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=00-01

  Stats: 738 lines in 32 files changed: 484 ins; 86 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sat Jan 14 13:21:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 14 Jan 2023 13:21:43 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v2]
In-Reply-To: <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
Message-ID: <svOLKLcH7IMWPV8vw7zs___cH_fdkCq_Ov2fNPRuwzE=.bca897ad-5379-403c-bc8b-9747fd6665ac@github.com>

On Fri, 13 Jan 2023 22:36:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Eirik Bjorsnos 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:
>> 
>>  - Check that non-signature related .SF, .RSA files are treated as regular (non signature related) files during signing
>>  - Merge branch 'master' into signature-related-subdirs
>>  - Simplify comment by removing a negative and changing "these paths" to "this path"
>>  - Use @modules tags instead of explicit --add-exports args
>>  - Merge branch 'master' into signature-related-subdirs
>>  - Files residing in subdirectories of META-INF/ should not be treated as signature related
>
> test/jdk/java/util/jar/JarFile/VerifyUnrelatedSignatureFiles.java line 61:
> 
>> 59:         File j = createJarFile();
>> 60:         File s = signJarFile(j, "signed");
>> 61:         File m = moveSignatureRelated(s);
> 
> Try sign it again to a different file. Let's see if the moved files are also signed.

Nice, I added a check which verifies that a JAR containing non signature related files is signed as expected

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

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sat Jan 14 13:33:15 2023
From: duke at openjdk.org (altrisi)
Date: Sat, 14 Jan 2023 13:33:15 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
Message-ID: <sZI6HH2lGme97QbgF7a9wrquqwvuWq7p13-tHUo3-9Y=.ead702ed-0004-457a-837b-3280caad9e4d@github.com>

On Fri, 6 Jan 2023 21:59:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Removed constructors of primitive wrapper classes (deprecated for removal) in _javax.xml.stream.XMLOutputFactory_ 
>> 
>> Replaced with Boolean static fields: Boolean.TRUE and Boolean.FALSE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace | with single value in example

I'd say in there it makes more sense given the method is used when you want a wrapper, and therefore explicitly converting it helps documentation, but here it's just setting a property, where I don't think it helps anything, just decreases readability as it seems like there may be a reason to call it explicitly with a wrapper and not a simple `true`/`false`.

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

PR: https://git.openjdk.org/jdk/pull/11872

From jiefu at openjdk.org  Sat Jan 14 14:35:00 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 14 Jan 2023 14:35:00 GMT
Subject: RFR: 8300169: Build failure with clang-15
Message-ID: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>

Hi all,

Please review the fix for the build failure with clang-15.

1. -Wbitwise-instead-of-logical

   1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
   2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
   3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings


2. -Wdeprecated-non-prototype (all the warnings are disabled)

   1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
      It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.

   2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings

   3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings


3. -Wdeprecated-builtins

   Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings

   Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202

4. -Wgnu-folding-constant

   Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings


Thanks.
Best regards,
Jie

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

Commit messages:
 - 8300169: Build failure with clang-15

Changes: https://git.openjdk.org/jdk/pull/12005/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12005&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300169
  Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12005.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12005/head:pull/12005

PR: https://git.openjdk.org/jdk/pull/12005

From kcr at openjdk.org  Sat Jan 14 15:06:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 14 Jan 2023 15:06:09 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191:

> 189: #define hb_int_max(T) hb_int_max<T>::value
> 190: 
> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__)

Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.

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

PR: https://git.openjdk.org/jdk/pull/12005

From jlu at openjdk.org  Sat Jan 14 20:39:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 14 Jan 2023 20:39:13 GMT
Subject: RFR: 8299502: Usage of constructors of primitive wrapper classes
 should be avoided in javax.xml API docs [v2]
In-Reply-To: <sZI6HH2lGme97QbgF7a9wrquqwvuWq7p13-tHUo3-9Y=.ead702ed-0004-457a-837b-3280caad9e4d@github.com>
References: <p-K5Imum5HBn5lmRCAYEYIoeExUmCxW5fOBX_Sttex4=.d23222be-8de5-4fdf-b10f-242aa7350fdf@github.com>
 <aS2OywZ3MlAsml_7X03riyGzACdZeWBCW4BqImRqUzY=.3418d0dc-4c9a-46f0-9130-10c6202cfc3f@github.com>
 <sZI6HH2lGme97QbgF7a9wrquqwvuWq7p13-tHUo3-9Y=.ead702ed-0004-457a-837b-3280caad9e4d@github.com>
Message-ID: <QUJ9oOfQA20cIoHtEgzD7dEDhLXFT8GrQqrQyFutFRE=.5f26fe83-f11c-4647-920b-64b1a460def1@github.com>

On Sat, 14 Jan 2023 13:30:05 GMT, altrisi <duke at openjdk.org> wrote:

> I'd say in there it makes more sense given the method is used when you want a wrapper, and therefore explicitly converting it helps documentation, but here it's just setting a property, where I don't think it helps anything, just decreases readability as it seems like there may be a reason to call it explicitly with a wrapper and not a simple `true`/`false`.

In `setProperty(String name, Object value)`, the method is expecting `value` to be an Object. Like the other methods, it is a matter of passing the wrapper class or letting the primitive auto box. Passing true or false would have auto boxed boolean to Boolean. 

The original statement before my change passed a Boolean, the consensus from the other PR was to pass the wrapper class, setProperty() is expecting `value` to be an Object, and the implementation of setProperty() casts `value` to be Boolean regardless. Those are the reasons why I picked the wrapper over the primitive. 

I think an argument can be made for either way, and I don't necessarily believe one way is right or wrong, hope that helped.

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

PR: https://git.openjdk.org/jdk/pull/11872

From jiefu at openjdk.org  Sun Jan 15 01:59:11 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 15 Jan 2023 01:59:11 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
Message-ID: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>

On Sat, 14 Jan 2023 15:03:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.

Thanks @kevinrushforth for your review.

Yes, it had been fixed in the upstream and I just follow it.
Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .

Or did you mean we had to sync the whole harfbuzz with the upstream?
If so, I would suggest doing it in a separate PR.
What do you think?
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/12005

From tvaleev at openjdk.org  Sun Jan 15 07:52:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 15 Jan 2023 07:52:53 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v4]
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

Tagir F. Valeev 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 four additional commits since the last revision:

 - Copyright year and @since tag updated
 - Fixes according to review
   
   1. Reduce duplication in tests
   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
   3. Simplify documentation for shuffle(List, Random) to avoid duplication.
 - Remove Random -> ThreadLocalRandom change
 - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10520/files
  - new: https://git.openjdk.org/jdk/pull/10520/files/127e44ca..7b4486f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=02-03

  Stats: 419299 lines in 6034 files changed: 213412 ins; 139135 del; 66752 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sun Jan 15 07:55:09 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 15 Jan 2023 07:55:09 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <Uj8JtPgxcXBK_e4fcEmp-bUdEnMY4YptyHai5u_vA2M=.6c0e4ca0-cae0-4adc-b188-9b3caf1a8156@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
 <YWO2wTB2miEbk3Hdp7kx_ZlHysy43gInAP1YyGkerWM=.5c260521-0048-4c86-98bb-ea2ef9d5904c@github.com>
 <Uj8JtPgxcXBK_e4fcEmp-bUdEnMY4YptyHai5u_vA2M=.6c0e4ca0-cae0-4adc-b188-9b3caf1a8156@github.com>
Message-ID: <Ffj6vr22dKXltbTC0S15ef9KSQv0APCFFf3h19dhUDQ=.9f3e530f-ae8e-4206-b59c-d0bd7516d1f8@github.com>

On Wed, 4 Jan 2023 21:32:17 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> A gentle ping: please review the change and the CSR. Thanks.
>
> @amaembo a couple comments on the test.
> 
> The test should probably have `@key randomness` added to it.
> 
> On 2022-10-28, @bplb wrote:
>> jdk.test.lib.RandomFactory can be used to generate a reproducible sequence of random numbers. An example of its use may be seen for example in java/nio/file/Files/CopyAndMove.java
> 
> This bit of the test library is useful if the test is testing a random subset of the state space. It prints out the random seed on each run so that if one of the test cases fails, it's possible to reproduce it by supplying the same seed. However, it's restricted to Random and SplittableRandom, and we want to test something like Xoshiro256PlusPlus that is a RandomGenerator but not a Random. So maybe this test library can't be applied. However, take a look and see if you think it might be useful to use it.

@stuart-marks thank you! I've updated PR (only since and copyright year) and CSR. Also rebased the change, though probably I should not? Hopefully, it's not very harmful.

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

PR: https://git.openjdk.org/jdk/pull/10520

From duke at openjdk.org  Sun Jan 15 09:00:15 2023
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 15 Jan 2023 09:00:15 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <caoisohYpLPenyXaozXGLJ4uIOb6had9dbz-B1u327w=.73a1da2d-ff0f-4344-8f01-ee5504fd3945@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

Keep open.

On Sat, Jan 14, 2023, 14:15 bridgekeeper[bot] ***@***.***>
wrote:

> @Pr0methean <https://github.com/Pr0methean> 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!
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/8131#issuecomment-1382939712>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABF3NBO4MWUYIPGXBF7LBCDWSMQRHANCNFSM5SWZWANA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR: https://git.openjdk.org/jdk/pull/8131

From fyang at openjdk.org  Sun Jan 15 09:12:10 2023
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 15 Jan 2023 09:12:10 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
Message-ID: <jC0uX2BkP-M64FUvzhIibHAhLHhxkH9SwNkG8B_BDwo=.81293542-41f2-4ce8-9f67-14e8aa119174@github.com>

On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix callArranger

Changes requested by fyang (Reviewer).

test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2023, Institute of Software, Chinese Academy of Sciences. All rights reserved.

I think we should also break this into two separate lines like you do for other newly-added files.

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

PR: https://git.openjdk.org/jdk/pull/11004

From duke at openjdk.org  Sun Jan 15 14:34:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 15 Jan 2023 14:34:34 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v3]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <IDs2Av3VY7g5XLqxsLYYe3PcaS12MliDd_HQkMsXi7o=.fc0f366c-5d1e-4056-be88-55ff40406c61@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

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

  Check that JarSigner does not move unrelated [SF,RSA] files to the beginning of signed JARs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/828e083c..209d12ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=01-02

  Stats: 56 lines in 1 file changed: 35 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sun Jan 15 14:40:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 15 Jan 2023 14:40:11 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v3]
In-Reply-To: <svOLKLcH7IMWPV8vw7zs___cH_fdkCq_Ov2fNPRuwzE=.bca897ad-5379-403c-bc8b-9747fd6665ac@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <svOLKLcH7IMWPV8vw7zs___cH_fdkCq_Ov2fNPRuwzE=.bca897ad-5379-403c-bc8b-9747fd6665ac@github.com>
Message-ID: <KiD5t_vuj7MDd202RffTqpx0d4nFDvIPS2ML_qu7s7o=.68c5738b-facc-447c-8175-958bea785710@github.com>

On Sat, 14 Jan 2023 13:17:32 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/util/jar/JarFile/VerifyUnrelatedSignatureFiles.java line 61:
>> 
>>> 59:         File j = createJarFile();
>>> 60:         File s = signJarFile(j, "signed");
>>> 61:         File m = moveSignatureRelated(s);
>> 
>> Try sign it again to a different file. Let's see if the moved files are also signed.
>
> Nice, I added a check which verifies that a JAR containing non signature related files is signed as expected

I also added a check verifying that JarSigner does not move unrelated signature files to the beginning of the signed JAR

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

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Sun Jan 15 15:15:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 15 Jan 2023 15:15:34 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v4]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <GXTAkOshirWSlMC6ETjHhE3J0_zfMnILf3pm0-bHG8Y=.80f5b1fe-ed3b-4a3c-a635-01df2387923e@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

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

  To ensure that the "unrelated signature files" code path of JarVerifier is actually being exercised by our tests, add unrelated signature files also at the beginning of the test JAR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/209d12ea..f264547a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=02-03

  Stats: 10 lines in 1 file changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From fjiang at openjdk.org  Sun Jan 15 15:31:52 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 15 Jan 2023 15:31:52 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v6]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <5EFRZ3OVzKXhrdzba7Pcvpx-9gV8tu_ttcAvUsFtrUk=.0c60959f-9849-42c3-a8aa-c1cd712e816a@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
> - [x] jdk_foreign with release/fastdebug build on linux-x64
> - [x] jdk_foreign with release/fastdebug build on linux-aarch64

Feilong Jiang 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 10 additional commits since the last revision:

 - fix comment & code adjustment
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - fix callArranger
 - fix callArranger
 - fix build
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - code adjustment and remove unnecessary static
 - sync with JDK-8296477
 - sync with JDK-8295044
 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/fee96ae8..be0826db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=04-05

  Stats: 5077 lines in 204 files changed: 3274 ins; 964 del; 839 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From fjiang at openjdk.org  Sun Jan 15 15:33:10 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 15 Jan 2023 15:33:10 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <jC0uX2BkP-M64FUvzhIibHAhLHhxkH9SwNkG8B_BDwo=.81293542-41f2-4ce8-9f67-14e8aa119174@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
 <jC0uX2BkP-M64FUvzhIibHAhLHhxkH9SwNkG8B_BDwo=.81293542-41f2-4ce8-9f67-14e8aa119174@github.com>
Message-ID: <sQ5AwUVn-jZcOaIkyIOSfbEWv0Yy5RL92QJmFf74x_w=.20f96db9-0698-4473-b004-6cacbf64d53c@github.com>

On Sun, 15 Jan 2023 09:09:07 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix callArranger
>
> test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2023, Institute of Software, Chinese Academy of Sciences. All rights reserved.
> 
> I think we should also break this into two separate lines like you do for other newly-added files.

Oops! Missed here, fixed.

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

PR: https://git.openjdk.org/jdk/pull/11004

From duke at openjdk.org  Sun Jan 15 22:26:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sun, 15 Jan 2023 22:26:47 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v5]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <cf1tLLC7Kz9x0trxiK3WPGLTkFJZy6vZzCt2lj8y8-Q=.4f8e666e-b3ff-4df5-afa0-a5597bba3116@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

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

  Tag the test with the bug number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/f264547a..6d0f6904

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/11976

From redestad at openjdk.org  Sun Jan 15 23:24:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 15 Jan 2023 23:24:18 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v18]
In-Reply-To: <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <rrNQoogB_S9ngedjCdkRsEOPyguvSBo1SExPsZfVR2g=.edf9d2db-cdff-4b37-8b1d-6bf97838e3d8@github.com>
Message-ID: <uMqVEWXzBqMacMfNb04G91Wc92tZ2oMOw1sZ1AsWCAc=.e5e46904-b660-4423-b3c5-7bb1581435c0@github.com>

On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly lea external address

FWIW I prototyped a follow-up to use basic types and extracted the String special-casing from the code. To do so a few things unraveled, such as needing to pass the initial value, but arguably it all ended up a bit neater. I've put this experiment in another branch for now (https://github.com/openjdk/jdk/compare/pr/10847...cl4es:jdk:8282664-type-cleanup?expand=1) since I need to test it through thoroughly, but functionally and to ensure there's no obvious performance impact (did some quick sanity testing on micros that look perfectly neutral) 

@iwanowww does this make you a bit happier? I think of it as an immediate follow-up - but if there's strong preference I can merge it into this PR.

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

PR: https://git.openjdk.org/jdk/pull/10847

From fjiang at openjdk.org  Mon Jan 16 06:38:35 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 16 Jan 2023 06:38:35 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v7]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
> - [x] jdk_foreign with release/fastdebug build on linux-x64
> - [x] jdk_foreign with release/fastdebug build on linux-aarch64

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

  more code style adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/be0826db..c4809317

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=05-06

  Stats: 17 lines in 1 file changed: 1 ins; 15 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From fyang at openjdk.org  Mon Jan 16 06:47:10 2023
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 16 Jan 2023 06:47:10 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v7]
In-Reply-To: <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>
Message-ID: <B__0lQI2SC-VJDHpWi-xWNp2Yqku45gdEewqIFYd6fc=.478d02c0-a7e0-41e9-8bb7-accc373764b2@github.com>

On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more code style adjustment

Looks good to me. This also passed tier1-4 tests on my HiFive Unmatched boards.

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

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11004

From alanb at openjdk.org  Mon Jan 16 08:24:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jan 2023 08:24:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.

Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

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

PR: https://git.openjdk.org/jdk/pull/12005

From jiefu at openjdk.org  Mon Jan 16 08:54:10 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 16 Jan 2023 08:54:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
Message-ID: <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>

On Mon, 16 Jan 2023 08:21:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

Thanks @AlanBateman for the review.

Here is the bug report while building libjli (target support_native_java.base_libjli_zadler32.o).

1 error generated.
* For target support_native_java.base_libjli_zadler32.o:

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

PR: https://git.openjdk.org/jdk/pull/12005

From jiefu at openjdk.org  Mon Jan 16 08:59:10 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 16 Jan 2023 08:59:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
 <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
Message-ID: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>

On Mon, 16 Jan 2023 08:51:34 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too.

Mainly caused by files under `src/java.base/share/native/libzip/zlib/`.
I'm not sure if there is already a bug report to the upstream.

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

PR: https://git.openjdk.org/jdk/pull/12005

From alanb at openjdk.org  Mon Jan 16 09:06:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jan 2023 09:06:10 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <G43X3_TR0Wnisg2ugSVG--mPKEDluk5iE4hjg7PS2_8=.0c4f45af-ec1e-476e-aee9-133956cd6f35@github.com>
 <qkITP57tQNke6tqHjnc3qX8zjl1nj32U02cO1Nrl1FU=.3e49f5c5-fe22-4bfc-9575-faf3f72cb8a1@github.com>
 <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com>
Message-ID: <DOy_TtzJBod7_igu0htfT89lm-EPZANaEluI2wgGBBY=.9ba04372-2915-4795-884b-0144e17f05d0@github.com>

On Mon, 16 Jan 2023 08:56:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm not sure if there is already a bug report to the upstream.

Maybe this one:
https://github.com/madler/zlib/issues/633

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

PR: https://git.openjdk.org/jdk/pull/12005

From mcimadamore at openjdk.org  Mon Jan 16 11:56:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 11:56:24 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
Message-ID: <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>

On Fri, 13 Jan 2023 22:48:59 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This PR adds a new lint warning category `this-escape`.
>> 
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
>> 
>> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
>> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
>> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
>> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
>> 
>> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
>> 
>> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
>> 
>> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
>> 
>> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
>> 
>> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
>> 
>> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
>> 
>> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
>> 
>> **Patch Navigation Guide**
>> 
>> * Non-trivial compiler changes:
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
>> 
>> * Javadoc additions of `@implNote`:
>> 
>>     * `src/java.base/share/classes/java/io/PipedReader.java`
>>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>>     * `src/java.base/share/classes/java/lang/Throwable.java`
>>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>>     * `src/java.base/share/classes/java/util/EnumMap.java`
>>     * `src/java.base/share/classes/java/util/HashSet.java`
>>     * `src/java.base/share/classes/java/util/Hashtable.java`
>>     * `src/java.base/share/classes/java/util/LinkedList.java`
>>     * `src/java.base/share/classes/java/util/TreeMap.java`
>>     * `src/java.base/share/classes/java/util/TreeSet.java`
>> 
>> * New unit tests
>>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
>> 
>> * **Everything else** is just adding `@SuppressWarnings("this-escape")`
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix bug where field initializer warnings could be incorrectly suppressed.
>  - Consolidate all the unit tests that generate warnings into one.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096:

> 1094: 
> 1095:     // Perform the given action within a new scope
> 1096:     private <T> void visitScoped(boolean promote, Runnable action) {

type-variable unused here?

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Mon Jan 16 12:08:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 16 Jan 2023 12:08:43 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v6]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <iaUQqY_Lff1wlMD25Ex76-fcePZjHXTH64-E4Gm8d-4=.b0743dd8-a1f1-4771-bff1-1dfe87860619@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

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

  Fix copyright year of newly added test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/6d0f6904..808d1f41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11976

From mcimadamore at openjdk.org  Mon Jan 16 12:54:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 12:54:22 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
Message-ID: <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>

On Fri, 13 Jan 2023 21:28:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088:
>> 
>>> 1086:     private <T extends JCTree> void visitLooped(T tree, Consumer<T> visitor) {
>>> 1087:         visitScoped(tree, false, t -> {
>>> 1088:             while (true) {
>> 
>> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times
>
> The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.
> 
> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).
> 
> If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).

I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping".

So, here's what I found:

* compiling the JDK with the current patch produces 2376 warnings
* disabling support for recursive calls produces 2427 warnings
* treating all method calls inside a loop to be escaping produces 2464 warnings
* disabling scanning of methods in same compilation unit produces  4317 warnings

(Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis).

This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase).

So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Mon Jan 16 13:45:11 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 16 Jan 2023 13:45:11 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <HQ9YI5uuBlqqa4I00qGVZTh9Kdu4Gc-k1soeaaN1Plo=.816e2b0d-1d93-421e-a490-4296a3836b1b@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

Is anyone willing to review this PR?

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

PR: https://git.openjdk.org/jdk/pull/11897

From dfuchs at openjdk.org  Mon Jan 16 15:14:11 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jan 2023 15:14:11 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
Message-ID: <FkPLDaxSwyRWsh6wE9m2HCmZSkHinDCMbGuWJs28npk=.93efb630-22ba-4f5a-8867-b06477c9a9d1@github.com>

On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

src/java.base/share/classes/java/lang/CharSequence.java line 76:

> 74:      *
> 75:      * <p>If the {@code char} value specified by the index is a
> 76:      * {@linkplain Character##unicode surrogate}, the surrogate value

I didn't know about the `##` trick. Is that a new feature to target an HTML anchor?

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

PR: https://git.openjdk.org/jdk/pull/12000

From duke at openjdk.org  Mon Jan 16 15:49:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 15:49:28 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v10]
In-Reply-To: <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <bDUtLc3rL8E_h_r1dKHG3L5FMm90Hn-ujFxiVREnaG8=.4b15343c-2501-4c48-9f9c-901a4407662b@github.com>
 <Rj0irdJkEal-iRo_X8kMZ7M9s4MC8JcPFDkEbw0s8Q8=.19719a5f-9964-4a3e-88b9-e755bc4eed93@github.com>
Message-ID: <eig0bd85iBDM3fvvNZVAHmsoiHDj0VI3oSJRlNpn_64=.c78bc7b1-a6b8-4504-96f4-4149fb7836b9@github.com>

On Mon, 16 Jan 2023 11:53:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix bug where field initializer warnings could be incorrectly suppressed.
>>  - Consolidate all the unit tests that generate warnings into one.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096:
> 
>> 1094: 
>> 1095:     // Perform the given action within a new scope
>> 1096:     private <T> void visitScoped(boolean promote, Runnable action) {
> 
> type-variable unused here?

Thanks - will fix.

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Mon Jan 16 16:32:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 16:32:25 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
 <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
Message-ID: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>

On Mon, 16 Jan 2023 12:51:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop.
>> 
>> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`).
>> 
>> If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here).
>
> I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping".
> 
> So, here's what I found:
> 
> * compiling the JDK with the current patch produces 2376 warnings
> * disabling support for recursive calls produces 2427 warnings
> * treating all method calls inside a loop to be escaping produces 2464 warnings
> * disabling scanning of methods in same compilation unit produces  4317 warnings
> 
> (Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis).
> 
> This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase).
> 
> So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have.

Thanks for doing that analysis - very interesting.

It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.:

.../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized
        init(title, null);
            ^
.../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation
        SunToolkit.checkAndSetPolicy(this);
                                     ^


Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package".

I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.).

In any case, here are the results:

* Warnings for subclass in separate compilation unit: 2093
* Warnings for subclass in separate package: 1334

So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes.

FWIW this is the patch I used:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
index e81df22b017..f309a4742aa 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
@@ -216,24 +217,24 @@ class ThisEscapeAnalyzer extends TreeScanner {
 
             private Lint lint = ThisEscapeAnalyzer.this.lint;
             private JCClassDecl currentClass;
-            private boolean privateOuter;
+            private boolean nonPublicOuter;
 
             @Override
             public void visitClassDef(JCClassDecl tree) {
                 JCClassDecl currentClassPrev = currentClass;
-                boolean privateOuterPrev = privateOuter;
+                boolean nonPublicOuterPrev = nonPublicOuter;
                 Lint lintPrev = lint;
                 lint = lint.augment(tree.sym);
                 try {
                     currentClass = tree;
-                    privateOuter |= tree.sym.isAnonymous();
-                    privateOuter |= (tree.mods.flags & Flags.PRIVATE) != 0;
+                    nonPublicOuter |= tree.sym.isAnonymous();
+                    nonPublicOuter |= (tree.mods.flags & Flags.PUBLIC) == 0;
 
                     // Recurse
                     super.visitClassDef(tree);
                 } finally {
                     currentClass = currentClassPrev;
-                    privateOuter = privateOuterPrev;
+                    nonPublicOuter = nonPublicOuterPrev;
                     lint = lintPrev;
                 }
             }
@@ -268,10 +269,10 @@ class ThisEscapeAnalyzer extends TreeScanner {
                     // Determine if this is a constructor we should analyze
                     boolean analyzable = currentClassIsExternallyExtendable() &&
                         TreeInfo.isConstructor(tree) &&
-                        !tree.sym.isPrivate() &&
+                        (tree.sym.isPublic() || (tree.sym.flags() & Flags.PROTECTED) != 0) &&
                         !suppressed.contains(tree.sym);
 
-                    // Determine if this method is "invokable" in an analysis (can't be overridden)
+                    // Determine if this method is "invokable" in an analysis (can't be overridden outside package)
                     boolean invokable = !currentClassIsExternallyExtendable() ||
                         TreeInfo.isConstructor(tree) ||
                         (tree.mods.flags & (Flags.STATIC | Flags.PRIVATE | Flags.FINAL)) != 0;
@@ -286,12 +287,13 @@ class ThisEscapeAnalyzer extends TreeScanner {
                 }
             }
 
-            // Determines if the current class could be extended in some external compilation unit
+            // Determines if the current class could be extended in some other package
             private boolean currentClassIsExternallyExtendable() {
                 return !currentClass.sym.isFinal() &&
+                  currentClass.sym.isPublic() &&
                   !(currentClass.sym.isSealed() && currentClass.permitting.isEmpty()) &&
                   !(currentClass.sym.owner.kind == MTH) &&
-                  !privateOuter;
+                  !nonPublicOuter;
             }
         }.scan(env.tree);

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

PR: https://git.openjdk.org/jdk/pull/11874

From ihse at openjdk.org  Mon Jan 16 16:50:06 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:50:06 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into properties-eol-clean-safe
 - 8298047: Remove all non-significant trailing whitespace from properties files

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

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=01
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Mon Jan 16 16:52:12 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 16:52:12 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <_jLR_ky5hw9zllvt1MZyi3KWmGOefoRazd7sjzoUivo=.e0bc2d7a-05ad-4417-bc34-369c67c3bf5a@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I know this is boring stuff, but please can I get some more reviews on this? Sergey has reviewed the client parts. It's just removing trailing whitespaces. You should be able to just quickly scroll through this and confirm that this is indeed the case. If someone can take pity on me and just quickly check the non-client parts, I'd be very grateful.

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

PR: https://git.openjdk.org/jdk/pull/11491

From mcimadamore at openjdk.org  Mon Jan 16 17:16:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Jan 2023 17:16:26 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v9]
In-Reply-To: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
 <n3hUWG5kLL-55MW_LB6x91vBH5Mi4JCx0gjH3LnpB1o=.64e22db1-5031-408e-8c39-0f64284dc9a4@github.com>
 <C1dC7U69q67lgSFzmm1ntOzHAm_BcqisYnlAhekzAeo=.60148dca-01d1-4cee-8687-d3bba5aabc24@github.com>
 <YeWkbLGMsOSWBdyO1UAWlq60X7TdWdH8UU2JU80dNGg=.eecfe4c1-cc7f-419f-a9d4-35861172ae68@github.com>
 <tWT-QFU_CwEgdWme_qL8JF20FdgFaQpJWpP958IOLWM=.a4cf149e-b791-4403-abe5-332e166b07ce@github.com>
 <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com>
Message-ID: <fyeJ5SBQY5LsQePrlC2y9aADocSpEoYpNrTHCV9SRiQ=.47c49123-5acd-4482-9ce1-93a984fb3f51@github.com>

On Mon, 16 Jan 2023 16:29:31 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.:

yes, I really did the simplest possible thing (e.g. just counting the number of escape-this warnings, regardless of their kinds). Perhaps some of my measurements might be skewed as a result - but I think that magnitude-wise they are still telling.
> 
> ```
> .../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized
>         init(title, null);
>             ^
> .../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation
>         SunToolkit.checkAndSetPolicy(this);
>                                      ^
> ```
> 
> Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package".

To be fair, this is what my brain was reading when you talked about "compilation unit" - but then saw that the code was doing it differently. You see, for "sealed" classes we have a notion of "maintenance domain". E.g. the classes in a `permits` clause of a `sealed` declaration must belong to the same module (if available) or same package (if no module is available). That's how you get the exhaustiveness analysis and all the goodies, by essentially making a close-world assumption on the classes that are passed to javac for a given compilation task. I think it would make a lot of sense to apply these very same boundaries to the escape-this analysis (and, in fact, when looking at warnings coming out of the JDK, I often found false positives that were caused by this).
> 
> I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.).

Perhaps - but, as said above, `sealed` already does this by default - so there's a (strong) precedent, I believe, should we want to bend the analysis that way.
> 
> In any case, here are the results:
> 
>     * Warnings for subclass in separate compilation unit: 2093
> 
>     * Warnings for subclass in separate package: 1334
> 
> 
> So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes.

That corresponds to what I've sampled (unscientifically).

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

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Mon Jan 16 17:24:17 2023
From: duke at openjdk.org (balcanuc)
Date: Mon, 16 Jan 2023 17:24:17 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v5]
In-Reply-To: <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
Message-ID: <fWYHp0z8ZQo2L9BihqHU0VEihaMgygnn98iHIY_TQGI=.5d6d3740-d92c-4209-a050-589a23a74ec4@github.com>

On Thu, 12 Jan 2023 15:31:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This change transforms a O(n^2) path to O(n) when prepending zero padding to decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299677: Formatter.format might take a long time to format an integer or floating-point

in which JDK versions will the bug-fix back ported? As it is, it is impossible to be back ported to JDK8

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

PR: https://git.openjdk.org/jdk/pull/11939

From duke at openjdk.org  Mon Jan 16 17:24:20 2023
From: duke at openjdk.org (balcanuc)
Date: Mon, 16 Jan 2023 17:24:20 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v4]
In-Reply-To: <VMbNtYGyB7fkBUu5jVFELVWCIJP1ipmItNnJOwDyF8o=.9292e46a-18e9-4158-8e62-c239badffa3d@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <9qfrsqAY_WqyeNZzIPRbZ1ZAzIwBeZTYBG3gsimTUJQ=.8fbba88e-3a88-44f7-82ec-e1f02f84301f@github.com>
 <VMbNtYGyB7fkBUu5jVFELVWCIJP1ipmItNnJOwDyF8o=.9292e46a-18e9-4158-8e62-c239badffa3d@github.com>
Message-ID: <JggSAvjf_QywEv4MUdoO03ih3uQAxjQSOqCjF_SbSAs=.c20e4685-50a9-443d-9f7d-1871bdd3dee5@github.com>

On Thu, 12 Jan 2023 11:40:32 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8299677: Formatter.format might take a long time to format an integer or floating-point
>
> src/java.base/share/classes/java/util/Formatter.java line 4600:
> 
>> 4598:             // apply zero padding
>> 4599:             if (width > sb.length() && Flags.contains(f, Flags.ZERO_PAD)) {
>> 4600:                 String zeros = Character.toString(zero).repeat(width - sb.length());
> 
> `Character.toString(zero)` could be replaced directly with `String.valueOf(zero)` saving one more method call

is the bug going to be backported to JDK8? Due to the use of 'repeat' this seems to not be possible.

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

PR: https://git.openjdk.org/jdk/pull/11939

From rriggs at openjdk.org  Mon Jan 16 17:25:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jan 2023 17:25:12 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

The non-client parts look fine.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11491

From dfuchs at openjdk.org  Mon Jan 16 17:33:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jan 2023 17:33:10 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
Message-ID: <Q4GEjiaxLkldqkJXNeul0z_mVwiUC45g_OohzMGzkh0=.868ced78-7eb5-4ed0-a21d-f40de2c5d37b@github.com>

On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

Changes to InetAddressResolverProvider.java look good.

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

PR: https://git.openjdk.org/jdk/pull/12000

From rriggs at openjdk.org  Mon Jan 16 17:33:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jan 2023 17:33:12 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <FkPLDaxSwyRWsh6wE9m2HCmZSkHinDCMbGuWJs28npk=.93efb630-22ba-4f5a-8867-b06477c9a9d1@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
 <FkPLDaxSwyRWsh6wE9m2HCmZSkHinDCMbGuWJs28npk=.93efb630-22ba-4f5a-8867-b06477c9a9d1@github.com>
Message-ID: <DYRxgbuPf5iMH6ax_QCLGm9IefmnXHLMDw3i3gQIXUo=.a1fe4f71-0258-4bbd-8521-cc15eccd0b00@github.com>

On Mon, 16 Jan 2023 15:06:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo found in code review.
>
> src/java.base/share/classes/java/lang/CharSequence.java line 76:
> 
>> 74:      *
>> 75:      * <p>If the {@code char} value specified by the index is a
>> 76:      * {@linkplain Character##unicode surrogate}, the surrogate value
> 
> I didn't know about the `##` trick. Is that a new feature to target an HTML anchor?

The CSR has a concise description: [JDK-8294195](https://bugs.openjdk.org/browse/JDK-8294195) Generalize see and link tags for user-defined anchors

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

PR: https://git.openjdk.org/jdk/pull/12000

From rgiulietti at openjdk.org  Mon Jan 16 17:53:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 16 Jan 2023 17:53:19 GMT
Subject: RFR: 8299677: Formatter.format might take a long time to format an
 integer or floating-point [v5]
In-Reply-To: <fWYHp0z8ZQo2L9BihqHU0VEihaMgygnn98iHIY_TQGI=.5d6d3740-d92c-4209-a050-589a23a74ec4@github.com>
References: <b3fkLovXZw5XwJ5-H3iXivzaBo_htbSBD8dVze2wvzw=.407948c6-90b4-47c4-a256-2ed5566de08d@github.com>
 <KC8DLGhtSB8cTKgv5CID14ci_EQvpa8COBLbEjF7GqQ=.4c9566d3-ca6f-4842-aa8c-3839440ee069@github.com>
 <fWYHp0z8ZQo2L9BihqHU0VEihaMgygnn98iHIY_TQGI=.5d6d3740-d92c-4209-a050-589a23a74ec4@github.com>
Message-ID: <IgpNZVJ1Oh7llQGgesF_UxjxhN0-sKgmZavrSqZcsVc=.e8da5277-6253-48f2-a789-470cb3232564@github.com>

On Mon, 16 Jan 2023 17:13:52 GMT, balcanuc <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8299677: Formatter.format might take a long time to format an integer or floating-point
>
> in which JDK versions will the bug-fix back ported? As it is, it is impossible to be back ported to JDK8

@balcanuc Backporting is done in other, separate projects. Whether changes in mainline are backported, and how, is publicly discussed in the respective mailing lists. 

In particular, for JDK 8 Updates you might want to have a look at
[this mailing list](https://mail.openjdk.org/mailman/listinfo/jdk8u-dev) and the [this git repo](https://github.com/openjdk/jdk8u-dev).

If you feel this change is relevant to JDK 8, you are welcome to discuss a solution that does not rely on `repeat()` on that mailing list, and then [contribute](https://openjdk.org/contribute/) your code to the [JDK 8 Update project](https://openjdk.org/projects/jdk8u/).

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

PR: https://git.openjdk.org/jdk/pull/11939

From ihse at openjdk.org  Mon Jan 16 18:57:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:21 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
Message-ID: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>

On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into properties-eol-clean-safe
>>  - 8298047: Remove all non-significant trailing whitespace from properties files
>
> The non-client parts look fine.

@RogerRiggs Thanks!

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

PR: https://git.openjdk.org/jdk/pull/11491

From ihse at openjdk.org  Mon Jan 16 18:57:22 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Jan 2023 18:57:22 GMT
Subject: Integrated: 8298047: Remove all non-significant trailing whitespace
 from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <fTgnorzgmXthXmq26skxN42TKuvrV5cVOtaxjIVUu84=.75d2e856-d8c4-4630-8fb8-a35112a68b05@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has now been integrated.

Changeset: 4073b685
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4073b68565f9d5283be96ee6b75bab686f076bea
Stats:     693 lines in 264 files changed: 0 ins; 0 del; 693 mod

8298047: Remove all non-significant trailing whitespace from properties files

Reviewed-by: serb, rriggs

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

PR: https://git.openjdk.org/jdk/pull/11491

From redestad at openjdk.org  Mon Jan 16 23:19:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Jan 2023 23:19:49 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v19]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <FnXcw2xcaIeykRYVP8TGKV--WCHA89mVbaF0XgNmYkc=.4486a41e-120d-4688-a2dd-cbb0a903c90f@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with three additional commits since the last revision:

 - Change signature to offset + length, add sanity test
 - Adapt end input to len (fix latent bug with sub-ranges
 - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/c8c58f4a..59e179c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=17-18

  Stats: 210 lines in 13 files changed: 41 ins; 61 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Mon Jan 16 23:22:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 16 Jan 2023 23:22:00 GMT
Subject: RFR: 8015831: Add lint check for calling overridable methods from
 a constructor [v11]
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <S5AVjGo0WvhVFDj7fxOscuRhQisB7bkXZbQXuMpjouU=.646605ae-74d8-4878-9278-71bedfcaf3ac@github.com>

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unused type variable on method visitScoped().
 - Remove expression type filtering; it doesn't seem to be needed.
 - Clean up unused import.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11874/files
  - new: https://git.openjdk.org/jdk/pull/11874/files/0b06dc32..a0b4310d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09-10

  Stats: 21 lines in 2 files changed: 0 ins; 20 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874

PR: https://git.openjdk.org/jdk/pull/11874

From redestad at openjdk.org  Mon Jan 16 23:28:37 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Jan 2023 23:28:37 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v20]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <pyVLeQ7Nsz-zQ6ByDGzBA0zW3y3T8Tw7hU62PQRKmHY=.00a93b57-85aa-4cb6-8a4a-01a5370325b6@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

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

  trailing ws

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/59e179c5..ffe5b66d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=18-19

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

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Jan 16 23:32:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Jan 2023 23:32:13 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
Message-ID: <Uogu6009DQz4ft5ageJdtt2LBPNrzbGrswNs5UeusZY=.44d34723-bfec-4a81-9a77-f9a4e134b8ae@github.com>

On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/
>> 
>> Intriguing. How far off is this - and do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
>> 
>> If we turn this intrinsic into a stub we might also be able to reuse the optimization in other places, including from within the VM (calculating String hashCodes happen in a couple of places, including String deduplication). So I think there are still a few compelling reasons to go the manual route and continue on this path.
>
>> How far off is this ...?
> 
> Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. 
> 
>>  ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
> 
> Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector.
> 
> Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well).

I've opted to include the changes spurred by @iwanowww's comments since it led to a number of revisions to the intrinsified method API, and it would be strange to introduce an intrinsified method just to change the API drastically in a follow-up. Basically `ArraysSupport.vectorizedHashCode` has been changed to take an offset + length, an initial value and the logical basic type of the array elements. Which means any necessary scaling of index and length needs to be taken care of before calling the intrinsic. This makes the implementation more flexible at no measurable performance cost. Overall the refactoring might have reduced complexity a bit. 

Reviewers might observe that nothing is currently passing anything but `0` and `length` to `vectorizedHashCode` outside of the simple sanity test I've added, but I've verified this feature can be used to some effect elsewhere in the JDK, e.g: https://github.com/openjdk/jdk/compare/pr/10847...cl4es:jdk:zipcoder-hashcode?expand=1 (which improves speed of opening `ZipFile` by a small percentage in microbenchmarks).

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

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Tue Jan 17 01:11:09 2023
From: duke at openjdk.org (j3graham)
Date: Tue, 17 Jan 2023 01:11:09 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
Message-ID: <Wb3ckPXymAuUsKwrtXi-4zN80k999XnYwxYnHcYRX58=.771502fa-7e13-4fad-9dd4-472f29e3da8c@github.com>

On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk <duke at openjdk.org> wrote:

> 
> Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?

 `ImageOutputStreamImpl` and  `ImageInputStreamImpl`  in `javax.imageio.stream` have some very similar code that might benefit.

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

PR: https://git.openjdk.org/jdk/pull/11840

From fjiang at openjdk.org  Tue Jan 17 02:00:11 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 17 Jan 2023 02:00:11 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <xbM07GsK0sQfAD0K2zEuZFG8-lDnHjjNQ71ahGbA08s=.723105ba-82e7-43a1-af14-aa137d24d086@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
 <xbM07GsK0sQfAD0K2zEuZFG8-lDnHjjNQ71ahGbA08s=.723105ba-82e7-43a1-af14-aa137d24d086@github.com>
Message-ID: <oziCXM5kl0_Qp5IBJpN1YaUqpyOUWsDMmOK2sh9nHkE=.2263330e-c995-4c16-b0af-93011466cf24@github.com>

On Fri, 13 Jan 2023 11:30:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Excellent. No Comments.
> 
> I am running some sanity testing on our CI, and will approve when it comes back green.

@JornVernee, thanks for the reviewing and testing!

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

PR: https://git.openjdk.org/jdk/pull/11004

From dholmes at openjdk.org  Tue Jan 17 04:32:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jan 2023 04:32:08 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Hotspot changes are good.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12005

From jwaters at openjdk.org  Tue Jan 17 04:51:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 17 Jan 2023 04:51:10 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
Message-ID: <186n3G67Sj8P2mBITAMOffS96BHYjyHM3JAs5uZxvhQ=.0437fc64-5941-49ef-8733-9dedf6db78bf@github.com>

On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove faulty test tag, improve other test tag, fix comments

> /sponsor

Skara might be slightly confused since the Author has become a Committer right after the sponsor prompt, @minborg I'd suggest you issue `/integrate` again in that case

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

PR: https://git.openjdk.org/jdk/pull/11840

From jiefu at openjdk.org  Tue Jan 17 06:03:13 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 06:03:13 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <OFfuAHdidKLnoukO-HBMeNeSSmAFI5_mb4mGx6f-EFI=.0192744e-3e2a-4fcb-aa45-87f0e3ba83a5@github.com>
Message-ID: <Z1mb5W9xZsxCAsddrOnUd7BpoXR2wMxJfU8PosdtgJw=.36e86349-76eb-427f-8732-27fa4469cc1a@github.com>

On Tue, 17 Jan 2023 04:29:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hotspot changes are good.

Thanks @dholmes-ora .

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

PR: https://git.openjdk.org/jdk/pull/12005

From stsypanov at openjdk.org  Tue Jan 17 07:28:09 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 07:28:09 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <sK9SHY26UCsiXS9goCl7WXpiQVYMPRWA6gzJ-yepiUM=.a6d99924-2550-4471-a7f7-edb54e5e625d@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

I see that `getBytesUTF8NoRepl()` is used in `j.u.z.ZipCoder`, so could you run tests for zip encoding just to make sure everything is fine there? And I think that tier2 should be run for this as well.

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

PR: https://git.openjdk.org/jdk/pull/11897

From pminborg at openjdk.org  Tue Jan 17 07:48:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Jan 2023 07:48:19 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <Wb3ckPXymAuUsKwrtXi-4zN80k999XnYwxYnHcYRX58=.771502fa-7e13-4fad-9dd4-472f29e3da8c@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
 <Wb3ckPXymAuUsKwrtXi-4zN80k999XnYwxYnHcYRX58=.771502fa-7e13-4fad-9dd4-472f29e3da8c@github.com>
Message-ID: <mH1I6vH053AyhwYetQ3l8JnsgqZTsccgjSbV4fOmAWs=.415d085e-0da4-49f8-8f3d-1f8405a37329@github.com>

On Tue, 17 Jan 2023 01:08:09 GMT, j3graham <duke at openjdk.org> wrote:

> > Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?
> 
> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream` have some very similar code that might benefit. Also `DataInputStream` and `DataOutpuStream`could possibly use `Bits` directly.

Thanks @j3graham

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

PR: https://git.openjdk.org/jdk/pull/11840

From pminborg at openjdk.org  Tue Jan 17 07:48:21 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Jan 2023 07:48:21 GMT
Subject: Integrated: 8299576: Reimplement java.io.Bits using VarHandle access
In-Reply-To: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
Message-ID: <1M9sh3bzaGjSF7jP8D8CWriRYZsdxfeYTArkqxKqTcU=.a3d3a99f-0daf-454c-a97b-ec1c036003d8@github.com>

On Wed, 4 Jan 2023 08:48:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
> 
> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
> 
> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
> 
> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762

This pull request has now been integrated.

Changeset: 3462438a
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3462438ae1bc469243096abeb5adbe007ef14fe5
Stats:     467 lines in 3 files changed: 428 ins; 24 del; 15 mod

8299576: Reimplement java.io.Bits using VarHandle access

Reviewed-by: uschindler, alanb

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

PR: https://git.openjdk.org/jdk/pull/11840

From stsypanov at openjdk.org  Tue Jan 17 08:31:02 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 08:31:02 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles
Message-ID: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>

- `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
- comparison of two lists can be done without `Stream.reduce()`

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

Commit messages:
 - Fix test
 - Improve MH

Changes: https://git.openjdk.org/jdk/pull/12025/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300237
  Stats: 14 lines in 1 file changed: 2 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12025/head:pull/12025

PR: https://git.openjdk.org/jdk/pull/12025

From stsypanov at openjdk.org  Tue Jan 17 08:34:22 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 08:34:22 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <mH1I6vH053AyhwYetQ3l8JnsgqZTsccgjSbV4fOmAWs=.415d085e-0da4-49f8-8f3d-1f8405a37329@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
 <Wb3ckPXymAuUsKwrtXi-4zN80k999XnYwxYnHcYRX58=.771502fa-7e13-4fad-9dd4-472f29e3da8c@github.com>
 <mH1I6vH053AyhwYetQ3l8JnsgqZTsccgjSbV4fOmAWs=.415d085e-0da4-49f8-8f3d-1f8405a37329@github.com>
Message-ID: <nwc5FrKw9dJCou_bWk-dOC3XvcmdL3M9K56kd-SKTFg=.79a19181-7493-4da7-b2d8-5f16ab748bcb@github.com>

On Tue, 17 Jan 2023 07:43:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> 
>>> Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?
>> 
>>  `ImageOutputStreamImpl` and  `ImageInputStreamImpl`  in `javax.imageio.stream` have some very similar code that might benefit. Also `DataInputStream` and `DataOutpuStream`could possibly use `Bits` directly.
>
>> > Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?
>> 
>> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream` have some very similar code that might benefit. Also `DataInputStream` and `DataOutpuStream`could possibly use `Bits` directly.
> 
> Thanks @j3graham

@minborg I guess that the same can be done for `MethodHandles.readInt()`, `ByteBuffer.getInt()`, `AESCrypt.implEncryptBlock()`. Btw, I see that unlike original code `VarHandle.get()` returns Object, not primitive. Won't we have excessive allocation with this change?

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

PR: https://git.openjdk.org/jdk/pull/11840

From qamai at openjdk.org  Tue Jan 17 09:03:19 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 17 Jan 2023 09:03:19 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <nwc5FrKw9dJCou_bWk-dOC3XvcmdL3M9K56kd-SKTFg=.79a19181-7493-4da7-b2d8-5f16ab748bcb@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
 <Wb3ckPXymAuUsKwrtXi-4zN80k999XnYwxYnHcYRX58=.771502fa-7e13-4fad-9dd4-472f29e3da8c@github.com>
 <mH1I6vH053AyhwYetQ3l8JnsgqZTsccgjSbV4fOmAWs=.415d085e-0da4-49f8-8f3d-1f8405a37329@github.com>
 <nwc5FrKw9dJCou_bWk-dOC3XvcmdL3M9K56kd-SKTFg=.79a19181-7493-4da7-b2d8-5f16ab748bcb@github.com>
Message-ID: <Lz1ZJNgPl4TVtkfRhwQ3n9KjecTvuYkIWzDkT_8AFvE=.6e8669a9-e84f-454d-a337-2ea041eab707@github.com>

On Tue, 17 Jan 2023 08:30:58 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>>> > Do you see any concrete examples of classes in the JDK that could benefit from a "VarHandlization"?
>>> 
>>> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream` have some very similar code that might benefit. Also `DataInputStream` and `DataOutpuStream`could possibly use `Bits` directly.
>> 
>> Thanks @j3graham
>
> @minborg I guess that the same can be done for `MethodHandles.readInt()`, `ByteBuffer.getInt()`, `AESCrypt.implEncryptBlock()`. Btw, I see that unlike original code `VarHandle.get()` returns Object, not primitive. Won't we have excessive allocation with this change?

@stsypanov `VarHandle.get()` is a polymorphic signature method, which means that a call `(int) INT.get(b, off)` will invoke a method with a signature of `int VarHandle::get(byte[], int)`

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

PR: https://git.openjdk.org/jdk/pull/11840

From shade at openjdk.org  Tue Jan 17 09:10:14 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 17 Jan 2023 09:10:14 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v7]
In-Reply-To: <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>
Message-ID: <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com>

On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more code style adjustment

Looks okay from the cursory review.

src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 3:

> 1: /*
> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 3:  * Copyright (c) 2022, Institute of Software, Chinese Academy of Sciences.

Not sure if this change is accidental?

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11004

From forax at openjdk.org  Tue Jan 17 09:15:23 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 Jan 2023 09:15:23 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
Message-ID: <sppP6PjGLEm4F2RMo-dfOoPfYD6bUEpTqEONAMc_Zyw=.6b02e179-0083-4875-9d47-33aa6f737445@github.com>

On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove faulty test tag, improve other test tag, fix comments

yes,
see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/MethodHandle.html#sigpoly
and https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html

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

PR: https://git.openjdk.org/jdk/pull/11840

From rgiulietti at openjdk.org  Tue Jan 17 09:53:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Jan 2023 09:53:53 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical equivalent
 permutations in j.u.r.Pattern
Message-ID: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>

- Strengthen a computation that could overflow.
- Specify that use of CANON_EQ could exhaust memory in the compilation phase.

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

Commit messages:
 - 8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern

Changes: https://git.openjdk.org/jdk/pull/12027/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12027&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300207
  Stats: 30 lines in 1 file changed: 24 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12027.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12027/head:pull/12027

PR: https://git.openjdk.org/jdk/pull/12027

From redestad at openjdk.org  Tue Jan 17 09:55:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 09:55:12 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>

On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6754:

> 6752:                         filter(t -> t.parameterCount() > skipSize).
> 6753:                         map(MethodType::ptypes).
> 6754:                         reduce((p, q) -> p.length >= q.length ? p : q).orElse(EMPTY);

Could avoid the need to introduce `EMPTY` if you make the stream expression return the longest list directly:

                reduce((p, q) -> {
                    var longest = (p.size() >= q.size()) ? p : q;
                    return List.of(Arrays.copyOfRange(longest, skipSize, longest.size()); // checking isEmpty() is redundant here since we filter on `t.parameterCount() > skipSize`
                }).orElse(List.of());

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

PR: https://git.openjdk.org/jdk/pull/12025

From redestad at openjdk.org  Tue Jan 17 10:07:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 10:07:13 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <9wMP81qcS6tgA56eMIAWERa2kqPqkE7csjhAAucfeGA=.fb546e0e-5065-4a9f-aa7e-b782ff44b063@github.com>

On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

Remove `EMPTY` (using my earlier suggestion or by simply inlining `new Class<?>[0]`) and I think this looks OK if framed as a code cleanup. The affected code isn't very performance sensitive as it's only used in the setup for `MHs.loop` combinators, which are likely to be rare in practice.

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

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12025

From alanb at openjdk.org  Tue Jan 17 10:10:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 10:10:13 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern
In-Reply-To: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
Message-ID: <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>

On Tue, 17 Jan 2023 09:44:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> - Strengthen a computation that could overflow.
> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.

src/java.base/share/classes/java/util/regex/Pattern.java line 1099:

> 1097:      * flags.
> 1098:      *
> 1099:      * <p>Setting {@link #CANON_EQ} among the flags may impose a moderate risk

This may be a candidate for `@apiNote`, same thing for the note added to CANON_EQ.

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

PR: https://git.openjdk.org/jdk/pull/12027

From forax at openjdk.org  Tue Jan 17 10:14:14 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 Jan 2023 10:14:14 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles
In-Reply-To: <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>
Message-ID: <RggKipVAvqKk6BLyAR9DE_fQBBQ15VEOWups-djRshY=.8e9fd79c-0fa6-4753-9232-50eea37d2950@github.com>

On Tue, 17 Jan 2023 09:51:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6754:
> 
>> 6752:                         filter(t -> t.parameterCount() > skipSize).
>> 6753:                         map(MethodType::ptypes).
>> 6754:                         reduce((p, q) -> p.length >= q.length ? p : q).orElse(EMPTY);
> 
> Could avoid the need to introduce `EMPTY` if you make the stream expression return the longest list directly:
> 
>                 reduce((p, q) -> {
>                     var longest = (p.size() >= q.size()) ? p : q;
>                     return List.of(Arrays.copyOfRange(longest, skipSize, longest.size()); // checking isEmpty() is redundant here since we filter on `t.parameterCount() > skipSize`
>                 }).orElse(List.of());

Using lambdas inside MethodHandles is quite dangerous given that lambdas are initialized using method handles. It may work now because longuestParameterList() is not called when initializing a lambda but it may make any changes in the implementation of lambdas painfull in the future.

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

PR: https://git.openjdk.org/jdk/pull/12025

From redestad at openjdk.org  Tue Jan 17 10:21:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 10:21:18 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles
In-Reply-To: <RggKipVAvqKk6BLyAR9DE_fQBBQ15VEOWups-djRshY=.8e9fd79c-0fa6-4753-9232-50eea37d2950@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>
 <RggKipVAvqKk6BLyAR9DE_fQBBQ15VEOWups-djRshY=.8e9fd79c-0fa6-4753-9232-50eea37d2950@github.com>
Message-ID: <SYT6-7R_T2S-be55KOThrLr-Z5dotJhdgyT95q5hv8o=.fd491c75-f4e1-4cc9-98df-8f1cd531ef4b@github.com>

On Tue, 17 Jan 2023 10:11:49 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6754:
>> 
>>> 6752:                         filter(t -> t.parameterCount() > skipSize).
>>> 6753:                         map(MethodType::ptypes).
>>> 6754:                         reduce((p, q) -> p.length >= q.length ? p : q).orElse(EMPTY);
>> 
>> Could avoid the need to introduce `EMPTY` if you make the stream expression return the longest list directly:
>> 
>>                 reduce((p, q) -> {
>>                     var longest = (p.size() >= q.size()) ? p : q;
>>                     return List.of(Arrays.copyOfRange(longest, skipSize, longest.size()); // checking isEmpty() is redundant here since we filter on `t.parameterCount() > skipSize`
>>                 }).orElse(List.of());
>
> Using lambdas inside MethodHandles is quite dangerous given that lambdas are initialized using method handles. It may work now because longuestParameterList() is not called when initializing a lambda but it may make any changes in the implementation of lambdas painfull in the future.

Precious little method handle use in lambda bootstrap since JDK 11. Though I agree with the sentiment - having fixed a number of bootstrap issues in the past - `MethodHandles` is a small step up the abstraction ladder and the code in particular already uses a number of method refs and lambdas.

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

PR: https://git.openjdk.org/jdk/pull/12025

From rgiulietti at openjdk.org  Tue Jan 17 10:23:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Jan 2023 10:23:15 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern
In-Reply-To: <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
Message-ID: <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>

On Tue, 17 Jan 2023 10:06:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> - Strengthen a computation that could overflow.
>> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 1099:
> 
>> 1097:      * flags.
>> 1098:      *
>> 1099:      * <p>Setting {@link #CANON_EQ} among the flags may impose a moderate risk
> 
> This may be a candidate for `@apiNote`, same thing for the note added to CANON_EQ.

The choice of a `<p>` paragraph rather than `@apiNote` is for consistency with similar commentary paragraphs in the specs of `CASE_INSENSITIVE`, `UNICODE_CASE`, and `UNICODE_CHARACTER_CLASS`.

I have no problems in using `@apiNote` instead, but then it would be better to apply the same for the other mentioned flags as well.

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

PR: https://git.openjdk.org/jdk/pull/12027

From jiefu at openjdk.org  Tue Jan 17 11:33:12 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 11:33:12 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <vbGfneNvtdDItzIDppzwCHK_adtw5fm3DT3Pm_0Ygr0=.2346b778-78ec-4e9b-ac7f-3d32118a11be@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Hi @kevinrushforth and @AlanBateman , are you fine with this change?
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/12005

From vsitnikov at openjdk.org  Tue Jan 17 11:47:26 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Tue, 17 Jan 2023 11:47:26 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
Message-ID: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>

On Mon, 16 Jan 2023 18:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The non-client parts look fine.
>
> @RogerRiggs Thanks!

@magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?

Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

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

PR: https://git.openjdk.org/jdk/pull/11491

From alanb at openjdk.org  Tue Jan 17 12:03:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 12:03:52 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if resource
 name maps to invalid file path
Message-ID: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>

The ModuleReader implementation for exploded modules maps resource names to file paths. A small oversight is that it doesn't handle InvalidPathException which is thrown when the resource name maps to something that can't be parsed as a file path. This has a knock on impact to Class/ClassLoader getResourceXXX and other usages of ModuleReader.

The existing ModuleReaderTest is updated to include additional resource names to test. I've also moved `@Test` annotation to the test methods so that it's a bit clearer which are the test methods in this source file.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300228
  Stats: 55 lines in 2 files changed: 29 ins; 12 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12035/head:pull/12035

PR: https://git.openjdk.org/jdk/pull/12035

From ihse at openjdk.org  Tue Jan 17 12:17:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 17 Jan 2023 12:17:25 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <RL9o7v8nYmartQrhygV7sw42MUZ8vaS1qoqy0TzH_6s=.71f4b88f-3517-41f2-8e2f-d059eb3f4969@github.com>
 <aifLgLpgJS_gMzyzRP6INOO4R7bE50ruKJ6R5pQS-lk=.66345dcc-48ae-43d9-b205-8d2f8f1e7ebf@github.com>
 <JxuulcLUmSJ-XI3ENSzO2Nji3I5Z-irlTUt3AITca0c=.d6978830-c241-4d1a-be0d-1515935c38e2@github.com>
Message-ID: <lKrVS5Y1fnd5UqKpq4potUFK_E7nBX4lAeqVoLY1OrM=.0db54199-ac6f-4b3a-bf25-f6df1db5bfef@github.com>

On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

>> @RogerRiggs Thanks!
>
> @magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace?
> 
> Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default.

@vlsi That is an interesting suggestion. My experience with `.editorconfig` is that it is a bit so-so about getting it to actually describe the coding practices of a project, but it can probably be used for a thing like stripping trailing whitespace.

I suggest we continue that discussion in ide-support-dev at openjdk.org, to figure out exactly what can be added to an `.editorconfig file`, how it interacts with jcheck rules and test how different IDEs behave.

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

PR: https://git.openjdk.org/jdk/pull/11491

From alanb at openjdk.org  Tue Jan 17 12:26:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 12:26:14 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern
In-Reply-To: <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
 <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
Message-ID: <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>

On Tue, 17 Jan 2023 10:20:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/regex/Pattern.java line 1099:
>> 
>>> 1097:      * flags.
>>> 1098:      *
>>> 1099:      * <p>Setting {@link #CANON_EQ} among the flags may impose a moderate risk
>> 
>> This may be a candidate for `@apiNote`, same thing for the note added to CANON_EQ.
>
> The choice of a `<p>` paragraph rather than `@apiNote` is for consistency with similar commentary paragraphs in the specs of `CASE_INSENSITIVE`, `UNICODE_CASE`, and `UNICODE_CHARACTER_CLASS`.
> 
> I have no problems in using `@apiNote` instead, but then it would be better to apply the same for the other mentioned flags as well.

Okay, I see your point and to use apiNote consistently would require "converting" some of the existing text to apiNote too.

I'm still mulling over Pattern.compile throwing OOME. An implNote is probably the right category for this, in which case it can start with "In the the JDK Reference Implementation ...".  I assume the static Pattern.matches needs same, and also Pattern.matcher for the lazy compilation case.

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

PR: https://git.openjdk.org/jdk/pull/12027

From jpai at openjdk.org  Tue Jan 17 12:37:16 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jan 2023 12:37:16 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
Message-ID: <TB5S_2T6ofeyovSAMJYMS7v1lLDJKk2BLrZVCJuQUW8=.b2166bb4-e846-4393-85b2-dfaf02d1f6ab@github.com>

On Tue, 17 Jan 2023 11:34:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The ModuleReader implementation for exploded modules maps resource names to file paths. A small oversight is that it doesn't handle InvalidPathException which is thrown when the resource name maps to something that can't be parsed as a file path. This has a knock on impact to Class/ClassLoader getResourceXXX and other usages of ModuleReader.
> 
> The existing ModuleReaderTest is updated to include additional resource names to test. I've also moved `@Test` annotation to the test methods so that it's a bit clearer which are the test methods in this source file.

Looks good to me. Should we also add a `C:/java` (one with a forward slash) to the new junk resource names added in this test, to exercise the path where a forward slash is present in a resource name which also has the Windows disallowed `:` character in it?

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12035

From chegar at openjdk.org  Tue Jan 17 12:43:12 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Tue, 17 Jan 2023 12:43:12 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
Message-ID: <cD6H9Qmt124uKHDrPWwp0XNhiD8fx40q-yA5kfYFl1Q=.308f7dd0-59f9-4735-a5ec-d7102e5d71ce@github.com>

On Tue, 17 Jan 2023 11:34:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The ModuleReader implementation for exploded modules maps resource names to file paths. A small oversight is that it doesn't handle InvalidPathException which is thrown when the resource name maps to something that can't be parsed as a file path. This has a knock on impact to Class/ClassLoader getResourceXXX and other usages of ModuleReader.
> 
> The existing ModuleReaderTest is updated to include additional resource names to test. I've also moved `@Test` annotation to the test methods so that it's a bit clearer which are the test methods in this source file.

LGTM

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12035

From fjiang at openjdk.org  Tue Jan 17 12:49:15 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 17 Jan 2023 12:49:15 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v7]
In-Reply-To: <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <ovy_a4vCVyDnfDWMZukZ3ZfkDIbsV8X5X91zt2FQ76M=.40a239ed-43a5-4089-ab89-7bdfb9b4f636@github.com>
 <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com>
Message-ID: <DYPLX20a6prKz04r69wt0kypFfbiYvJod4KaeOcIvR0=.e54689a5-3553-44bb-bacb-f249525d92b8@github.com>

On Mon, 16 Jan 2023 11:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more code style adjustment
>
> src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 3:
> 
>> 1: /*
>> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 3:  * Copyright (c) 2022, Institute of Software, Chinese Academy of Sciences.
> 
> Not sure if this change is accidental?

The copyright of ISCAS is too long for one line, so we split them into separate lines.

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

PR: https://git.openjdk.org/jdk/pull/11004

From kcr at openjdk.org  Tue Jan 17 13:38:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:38:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

Yes, but I would wait for @prrace to review the Harfbuzz change.

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

PR: https://git.openjdk.org/jdk/pull/12005

From kcr at openjdk.org  Tue Jan 17 13:38:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 17 Jan 2023 13:38:17 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
 <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
Message-ID: <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>

On Sun, 15 Jan 2023 01:56:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191:
>> 
>>> 189: #define hb_int_max(T) hb_int_max<T>::value
>>> 190: 
>>> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__)
>> 
>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
>
>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
> 
> Thanks @kevinrushforth for your review.
> 
> Yes, it had been fixed in the upstream and I just follow it.
> Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .
> 
> Or did you mean we had to sync the whole harfbuzz with the upstream?
> If so, I would suggest doing it in a separate PR.
> What do you think?
> Thanks.

No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says.

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

PR: https://git.openjdk.org/jdk/pull/12005

From cstein at openjdk.org  Tue Jan 17 13:43:14 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Jan 2023 13:43:14 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
Message-ID: <y1enmB9ySbubXeNpGK9HkBvw8XLJT6mHWI-pcNGZuos=.8bba643f-5da6-4f95-9d38-bcaeb0cf5824@github.com>

On Tue, 17 Jan 2023 11:34:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The ModuleReader implementation for exploded modules maps resource names to file paths. A small oversight is that it doesn't handle InvalidPathException which is thrown when the resource name maps to something that can't be parsed as a file path. This has a knock on impact to Class/ClassLoader getResourceXXX and other usages of ModuleReader.
> 
> The existing ModuleReaderTest is updated to include additional resource names to test. I've also moved `@Test` annotation to the test methods so that it's a bit clearer which are the test methods in this source file.

Marked as reviewed by cstein (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12035

From alanb at openjdk.org  Tue Jan 17 14:13:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 14:13:14 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <TB5S_2T6ofeyovSAMJYMS7v1lLDJKk2BLrZVCJuQUW8=.b2166bb4-e846-4393-85b2-dfaf02d1f6ab@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
 <TB5S_2T6ofeyovSAMJYMS7v1lLDJKk2BLrZVCJuQUW8=.b2166bb4-e846-4393-85b2-dfaf02d1f6ab@github.com>
Message-ID: <vGPKTYejFie4STxxD86B9x5VMHWI7yc6zUpNYz6gqmA=.159f75b2-1a0b-493b-90b3-bb866473dab3@github.com>

On Tue, 17 Jan 2023 12:34:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we also add a `C:/java` (one with a forward slash) to the new junk resource names added in this test, to exercise the path where a forward slash is present in a resource name which also has the Windows disallowed `:` character in it?

C:/java is a legal file path so there wouldn't be InvalidPathException for that case. The reason that resource name will be rejected on Windows is because it has a root component.  So yes, it could be added as a test case, just wouldn't add any more test coverage to the existing tests.

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

PR: https://git.openjdk.org/jdk/pull/12035

From jpai at openjdk.org  Tue Jan 17 14:24:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jan 2023 14:24:18 GMT
Subject: RFR: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <vGPKTYejFie4STxxD86B9x5VMHWI7yc6zUpNYz6gqmA=.159f75b2-1a0b-493b-90b3-bb866473dab3@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
 <TB5S_2T6ofeyovSAMJYMS7v1lLDJKk2BLrZVCJuQUW8=.b2166bb4-e846-4393-85b2-dfaf02d1f6ab@github.com>
 <vGPKTYejFie4STxxD86B9x5VMHWI7yc6zUpNYz6gqmA=.159f75b2-1a0b-493b-90b3-bb866473dab3@github.com>
Message-ID: <onpme1AH3w1v5YQWkmAf6AVy6BjC-ZiQ7uA60ZNnOlc=.7085e254-87de-49bd-8c66-c5f394a4784d@github.com>

On Tue, 17 Jan 2023 14:10:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So yes, it could be added as a test case, just wouldn't add any more test coverage to the existing tests.

Thank you for the explanation, Alan. The current state of the test, in the PR, looks fine to me then.

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

PR: https://git.openjdk.org/jdk/pull/12035

From rriggs at openjdk.org  Tue Jan 17 14:56:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Jan 2023 14:56:39 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <1vX9tKbkrXdxIyMRVW-cGETZ1NdWyWT919uZgCnBkNo=.ed67804c-74b9-4c9b-bd93-7f3d2d9f4267@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

`newStringUTF*NoRepl` is not described or expected to optimizing the array allocation.
Nor does it mandate that callers must guarantee that the array is not re-used or modified.
The access to this method through JavaLangAccess is solely for the convenience of the algorithm.
I don't see the performance improvement as sufficient to offset the risk of mis-use and its possible loss of integrity.

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

PR: https://git.openjdk.org/jdk/pull/11897

From stsypanov at openjdk.org  Tue Jan 17 14:57:57 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 14:57:57 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v2]
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <K7TKm6-n0RVm0edTIibjRI7Elq3X2EaP3p2gCw3nTyI=.aa50812a-57cc-4327-819e-e6111f9f4561@github.com>

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

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

  Simplify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12025/files
  - new: https://git.openjdk.org/jdk/pull/12025/files/e9e0baa0..6d1397c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12025/head:pull/12025

PR: https://git.openjdk.org/jdk/pull/12025

From rgiulietti at openjdk.org  Tue Jan 17 14:58:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Jan 2023 14:58:24 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern
In-Reply-To: <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
 <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
 <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
Message-ID: <V0HVrdFWi7OwnruwvhKRW3_gIC_-0cfDF_Nkx3lJbHA=.2326113d-053b-4985-83c3-0816b66cdbd6@github.com>

On Tue, 17 Jan 2023 12:23:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The choice of a `<p>` paragraph rather than `@apiNote` is for consistency with similar commentary paragraphs in the specs of `CASE_INSENSITIVE`, `UNICODE_CASE`, and `UNICODE_CHARACTER_CLASS`.
>> 
>> I have no problems in using `@apiNote` instead, but then it would be better to apply the same for the other mentioned flags as well.
>
> Okay, I see your point and to use apiNote consistently would require "converting" some of the existing text to apiNote too.
> 
> I'm still mulling over Pattern.compile throwing OOME. An implNote is probably the right category for this, in which case it can start with "In the the JDK Reference Implementation ...".  I assume the static Pattern.matches needs same, and also Pattern.matcher for the lazy compilation case.

There's no hard limit for the number of combining marks in the Unicode specification, even though in practice it never reaches the implementation limit. A high number of combining marks is thus more akin to a a resource exhaustion condition than to anything else, IMO.

Even today, compilation of a pattern risks throwing an OOME anyway when trying to generate the permutations. Pre-emptively throwing an OOME just anticipates and extrapolates this behavior beyond the `int` limit of array lengths.

Alternatively, compilation (greedy or lazy) could throw `PatternSyntaxException`, although there is not really something wrong with syntax.

I'll add `@implNote` to the other methods you mention.

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

PR: https://git.openjdk.org/jdk/pull/12027

From forax at openjdk.org  Tue Jan 17 15:33:18 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 Jan 2023 15:33:18 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v2]
In-Reply-To: <SYT6-7R_T2S-be55KOThrLr-Z5dotJhdgyT95q5hv8o=.fd491c75-f4e1-4cc9-98df-8f1cd531ef4b@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>
 <RggKipVAvqKk6BLyAR9DE_fQBBQ15VEOWups-djRshY=.8e9fd79c-0fa6-4753-9232-50eea37d2950@github.com>
 <SYT6-7R_T2S-be55KOThrLr-Z5dotJhdgyT95q5hv8o=.fd491c75-f4e1-4cc9-98df-8f1cd531ef4b@github.com>
Message-ID: <eppBkh-sxcnNvnyUeklE3iq4r6U_JL-tVDStNwmYdg4=.f5937a5b-6a17-4d06-9ac8-6fee02688768@github.com>

On Tue, 17 Jan 2023 10:18:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Using lambdas inside MethodHandles is quite dangerous given that lambdas are initialized using method handles. It may work now because longuestParameterList() is not called when initializing a lambda but it may make any changes in the implementation of lambdas painfull in the future.
>
> Precious little method handle use in lambda bootstrap since JDK 11. Though I agree with the sentiment - having fixed a number of bootstrap issues in the past - `MethodHandles` is a small step up the abstraction ladder and the code in particular already uses a number of method refs and lambdas.

ok, two small changes,
-  formatting: usually the method call in a stream are aligned with the '.' at the beginning
    ```
     stream
       .filter(...)
      .map(...)
   ```
   instead of at the end.

- the reduce is a max(),
  `max(Comparator.comparingInt(List::size))`

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

PR: https://git.openjdk.org/jdk/pull/12025

From duke at openjdk.org  Tue Jan 17 15:47:39 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 17 Jan 2023 15:47:39 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <1vX9tKbkrXdxIyMRVW-cGETZ1NdWyWT919uZgCnBkNo=.ed67804c-74b9-4c9b-bd93-7f3d2d9f4267@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
 <1vX9tKbkrXdxIyMRVW-cGETZ1NdWyWT919uZgCnBkNo=.ed67804c-74b9-4c9b-bd93-7f3d2d9f4267@github.com>
Message-ID: <1SMsTy-AvN72_PZ4s8bW5lV1xLG0lkxKTSHS8k0rEr0=.cad4e2c2-efae-4c0e-8543-9080797a1b86@github.com>

On Tue, 17 Jan 2023 14:53:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> `newStringUTF*NoRepl` is not described or expected to optimizing the array allocation. Nor does it mandate that callers must guarantee that the array is not re-used or modified. The access to this method through JavaLangAccess is solely for the convenience of the algorithm. I don't see the performance improvement as sufficient to offset the risk of mis-use and its possible loss of integrity.

@RogerRiggs 

I reread the javadoc document and found that I really misread the document. The method marked as not replicating is `newStringNoRepl`/`getBytesNoRepl`.

However, `newStringNoRepl` called `newStringUTF8NoRepl` for UTF-8, which caused the behavior of `newStringNoRepl` to be inconsistent with its javadoc. I think `Files.readString` is relying on this behavior because it will also copy the array defensively before calling `newStringNoRepl`.

Although the inconsistency between the behavior of `newStringUTF8NoRepl`/`getBytesUTF8NoRepl` and `newStringNoRepl`/`getBytesNoRepl` is confusing, I don't want to dwell on this issue. But I think I should reopen a PR for `newStringNoRepl`. Do you agree with me?

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

PR: https://git.openjdk.org/jdk/pull/11897

From alanb at openjdk.org  Tue Jan 17 15:50:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 15:50:45 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <Fjb-j8fv4anex_kR64SULL367y2DwdNkFvCMiyLzGCM=.bdafd023-7fec-40fc-a1bc-9815fff29c71@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <Fjb-j8fv4anex_kR64SULL367y2DwdNkFvCMiyLzGCM=.bdafd023-7fec-40fc-a1bc-9815fff29c71@github.com>
Message-ID: <PK2cHGKB_hDo6qcoP83m9V10xm2CMz5NVEBMdZ1YyWU=.1b5ba36d-a928-4751-953d-d61b3d656b6f@github.com>

On Wed, 11 Jan 2023 14:30:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> While running tier testing, one existing test showed that I hadn't taken into account SecurityManager checks in the new code that I had added. I have now fixed that part and pushed an update to the PR.
> 
> There's one additional unrelated test failing (`TestMaxCachedBufferSize`) in a odd way and I'll investigate it separately.

@jaikiran I've been mulling over this a bit further. When jlink is cross linking, as in creating a run-time image for a different target platform, then I think we should strive to have it create the jimage file in the native endian for the target platform. Right now this means the user needs to help out by providing the --endian option. For example, if the user is on linux-x64 but generating a run-time image for solaris-sparcv9 or aix-ppc, then it requires specifying jlink --endian=big to ensure that the jimage file is in the endianness needed at runtime. I don't disagree that having the 2-arg ImageFileReader::open retry with the opposite of the endian parameter will work but I don't think this is the right thing to do. Instead I think we need to consider determine the endian from the target java.base module. Right now the ModuleTarget class file attribute is not enough but a short term fix might be for jlink to have a simple mapping of known ModuleTarget values to endianness. Overal
 l, it's probably low priority as the most likely users of this will be environments building for embedded platforms.

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

PR: https://git.openjdk.org/jdk/pull/11943

From jlahoda at openjdk.org  Tue Jan 17 15:55:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 17 Jan 2023 15:55:40 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>

> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
> 
> switch (obj) {
>     case String s when s.isEmpty() -> {}
>     case String s -> {}
>     case CharSequence cs -> {}
>     ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
> 
> obj == null ? -1
>                   : switch (restartIndex) {
>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                         ...
>                         default -> <labels-count>;
>                     }
> 
> 
> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
> 
> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
> 
> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
> 
> 
> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

Jan Lahoda 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 four additional commits since the last revision:

 - Adding comments
 - Improving performance
 - Merge branch 'master' into JDK-8291966
 - 8291966: SwitchBootstrap.typeSwitch could be faster

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9779/files
  - new: https://git.openjdk.org/jdk/pull/9779/files/a7052742..004e63d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9779&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9779&range=00-01

  Stats: 592268 lines in 7950 files changed: 296207 ins; 212001 del; 84060 mod
  Patch: https://git.openjdk.org/jdk/pull/9779.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9779/head:pull/9779

PR: https://git.openjdk.org/jdk/pull/9779

From weijun at openjdk.org  Tue Jan 17 16:14:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jan 2023 16:14:34 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v6]
In-Reply-To: <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
Message-ID: <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>

On Sat, 14 Jan 2023 12:14:54 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 980:
>> 
>>> 978:      * Returns true iff the entry resides directly in the META-INF/ directory
>>> 979:      */
>>> 980:     private boolean isInMetaInf(ZipEntry ze) {
>> 
>> Maybe move this method and the one in `JarVerifier` to a common place like `sun.security.util.SignatureFileVerifier`?
>
> This duplicated check annoyed me also, but the existing checks have different behavior:
> 
> - JarVerifier.beginEntry normalizes the path to uppercase, them checks that it starts with "META-INF/" or "/META-INF/"
> - JarSigner.sign0 does not normalize to uppercase , then checks that the path starts with "META-INF/"
> 
> Introducing a common method would need change behaviour of one of these methods. This change of behaviour would not be relevant to the bug being fixed in this PR.
> 
> Since I'm cautious of changing behaviour, I decided to keep the two methods.

While `JarSigner` has not normalize to uppercase, the check is the same. As for `/META-INF/`, it must be very broken now since `JarFile::maybeInstantiateVerifier` is using `JUZFA.getManifestName(this,true)` to read the manifest and `ZipFile` will not see the signature-related files. We can probably clean these up in a different PR.

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

PR: https://git.openjdk.org/jdk/pull/11976

From alanb at openjdk.org  Tue Jan 17 16:29:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 16:29:02 GMT
Subject: Integrated: 8300228: ModuleReader.find on exploded module throws if
 resource name maps to invalid file path
In-Reply-To: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
References: <XTRnCqY5RkODVArBOVIOYqpAsKbD7mWuu-1e3IKD1NA=.33747a50-a0f0-41ca-a38f-6a7c06e162ff@github.com>
Message-ID: <Xp54eG5qvZpZPPT3YzlW_budC5kh98vpE-zIZV8oTXs=.3b121603-4935-4540-b58e-f8f623abbb25@github.com>

On Tue, 17 Jan 2023 11:34:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The ModuleReader implementation for exploded modules maps resource names to file paths. A small oversight is that it doesn't handle InvalidPathException which is thrown when the resource name maps to something that can't be parsed as a file path. This has a knock on impact to Class/ClassLoader getResourceXXX and other usages of ModuleReader.
> 
> The existing ModuleReaderTest is updated to include additional resource names to test. I've also moved `@Test` annotation to the test methods so that it's a bit clearer which are the test methods in this source file.

This pull request has now been integrated.

Changeset: fb147aae
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb147aaea1593e8a13d562d15994f67cdde3eb35
Stats:     55 lines in 2 files changed: 29 ins; 12 del; 14 mod

8300228: ModuleReader.find on exploded module throws if resource name maps to invalid file path

Reviewed-by: jpai, chegar, cstein

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

PR: https://git.openjdk.org/jdk/pull/12035

From weijun at openjdk.org  Tue Jan 17 16:49:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jan 2023 16:49:23 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v6]
In-Reply-To: <UCsro35XQhSOoB-nQEfp_JJ2JlxbkMzBHJOSlK0XmkA=.5911e2e8-b406-43eb-92c1-3d4bb5bd5306@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <UCsro35XQhSOoB-nQEfp_JJ2JlxbkMzBHJOSlK0XmkA=.5911e2e8-b406-43eb-92c1-3d4bb5bd5306@github.com>
Message-ID: <A2yY5Asj7ib13Fd5FxZ-bk8WzKUSzEmBFLs0NPrT6G4=.87c3c9c8-2dc2-4868-a2ea-bb256f073c3e@github.com>

On Sat, 14 Jan 2023 12:02:11 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1748:
>> 
>>> 1746:                 .isBlockOrSF(new String(name, off, len, UTF_8.INSTANCE)
>>> 1747:                     .toUpperCase(Locale.ENGLISH)));
>>> 1748: 
>> 
>> How about updating `SignatureFileVerifier.isBlockOrSF` so that it only returns true for files inside `META-INF/`. This way it's consistent to this method.
>
> I started there, but ran into some problems:
> 
> SignatureFileVerifier.isSigningRelated calls isBlockOrSF, but it removes the "META-INF/" prefix from the path first. So we can't assume that input to isBlockOrSF is the full path.
> 
> I could update SignatureFileVerifier.isSigningRelated to send the full path, but we still have another problem:
> 
> JarSigner.sign0 puts META-INF/ files in a vector, such that it can output them first. We want to update this method such that it outputs only files which live directly in META-INF/ first. So we still need to check for "directness" outside isBlockOrSF.
> 
> isBlockOrSF has 8 call sites, most of them in security sensitive and tricky code. In the end, I felt safer leaving isBlockOrSF alone and just fix the bug-relevant call sites instead. Also, being a new contributor to security-dev, I wanted to keep the PR relatively simple and easy to review.
> 
> WDYT?

In almost every call to `isBlockOrSF`, there is already an `isInMetaInf` (or equivalent) call right before it so it's always safe. The only exception is in `jarsigner`'s `verifyJar` method:

                    hasSignature = hasSignature
                            || SignatureFileVerifier.isBlockOrSF(name);

and it makes a subtle difference. The `unrelated-signature-files-modified.jar` your test created has SF/block files inside a sub-directory. Try verifying it with jarsigner. Here `hasSignature` is true but the SF/block is not considered signature-related, an error message will show `Signature is either not parsable or not verifiable`. If `isBlockOrSF` is modified to return false, it will be simply `jar is unsigned`.

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

PR: https://git.openjdk.org/jdk/pull/11976

From alanb at openjdk.org  Tue Jan 17 16:54:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 16:54:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <ABCj-zAMOh9x0xfkZN4dvaigzkTyWs6WWx1uRtQpZmA=.21c0b273-8122-4903-aeb7-0d65030cdc00@github.com>
Message-ID: <a8NjKk5ruGTmxeaA5kG9rlCH6_buPpBBCxsrbaOZX6Q=.88ba3920-4d30-451d-9691-98e25fdeb0d2@github.com>

On Tue, 17 Jan 2023 13:33:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review the fix for the build failure with clang-15.
>> 
>> 1. -Wbitwise-instead-of-logical
>> 
>>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
>> 
>> 
>> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
>> 
>>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
>> 
>>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
>> 
>>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
>> 
>> 
>> 3. -Wdeprecated-builtins
>> 
>>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
>> 
>>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
>> 
>> 4. -Wgnu-folding-constant
>> 
>>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Yes, but I would wait for @prrace to review the Harfbuzz change.

> Hi @kevinrushforth and @AlanBateman , are you fine with this change?

No objection from me but I agree with Kevin to wait to see what Phil says about Harfbuzz.

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

PR: https://git.openjdk.org/jdk/pull/12005

From naoto at openjdk.org  Tue Jan 17 17:29:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 17:29:29 GMT
Subject: Integrated: 8300010: UnsatisfiedLinkError on calling
 System.console().readPassword() on Windows
In-Reply-To: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
References: <MmiJmejlDQYnhS1PE8YUuU4_I9eWfnix-0x61xPOFuw=.4a8e5b17-f28a-4a6c-903a-3a8388fdfcfa@github.com>
Message-ID: <2KJAfZDFXd7E17Kv01BVPBJlb19jvkKf-u3wSMir3Xg=.d5fe7abb-51a0-4441-92d6-ed89b7415131@github.com>

On Thu, 12 Jan 2023 17:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the fix to [JDK-8298971](https://bugs.openjdk.org/browse/JDK-8298971). The previous fix lacked the native part change on Windows.

This pull request has now been integrated.

Changeset: e7e37121
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7e371212163ba6a56a9a365c662da3fa1a0fe47
Stats:     89 lines in 2 files changed: 58 ins; 24 del; 7 mod

8300010: UnsatisfiedLinkError on calling System.console().readPassword() on Windows

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/11973

From jbhateja at openjdk.org  Tue Jan 17 17:33:04 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Jan 2023 17:33:04 GMT
Subject: RFR: 8300208: Optimize Adler32 stub for AVX-512 targets.
Message-ID: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>

Patch optimizes Adler32 stub for AVX512 target.

Main computation loop now uses zero extended lane widening load vector operation.

New sequence also honors AVX3Thresholds so that implementation uses existing AVX2 instruction sequence on relevant targets
if input size is smaller than threshold limit (default 4096).

Following are the result of an [existing JMH micro ](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestAdler32.java)on various targets.

**System Configurations : Turbo frequency scaling is disabled, all the data is collected at fixed frequency of 2.8 GHz.
SUT1   : Intel? Xeon? Platinum 8480+ Processor (Sapphire Rapids)? 56C 2S
SUT2   : Intel(R) Xeon(R) Platinum 8380 CPU (Icelake Server) 40C 2S
SUT3   : Intel(R) Xeon(R) Platinum 8280 CPU (Cascadelake Server) 28C 2S**


![image](https://user-images.githubusercontent.com/59989778/212934730-68717a61-191f-4dba-8c83-2eddf6007a47.png)

![image](https://user-images.githubusercontent.com/59989778/212934945-cada95ad-c93c-487f-bacc-928a2e3b5c21.png)

![image](https://user-images.githubusercontent.com/59989778/212935059-511aca3b-c736-40a2-bff6-89caf0664828.png)


Please review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8300208: Optimize Adler32 stub for AVX-512 targets.

Changes: https://git.openjdk.org/jdk/pull/12045/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300208
  Stats: 142 lines in 4 files changed: 84 ins; 28 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/12045.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12045/head:pull/12045

PR: https://git.openjdk.org/jdk/pull/12045

From ccheung at openjdk.org  Tue Jan 17 17:40:33 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 17 Jan 2023 17:40:33 GMT
Subject: RFR: 8292635: Improve CDSHeapVerifier testing [v2]
In-Reply-To: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
Message-ID: <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>

> Moving the `ArchivedEnumTest.java` from `runtime/cds/appcds/cacheObject` to `jdk/internal/misc/CDS` so that the test will be run in jdk-tier1. This is to avoid inadvertently breakage of the test like in JDK-8292499.
> 
> Testing: jdk-tier1, tier3, tier4.

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

  enable CDSHeapVerifier::verify() for non-debug build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11999/files
  - new: https://git.openjdk.org/jdk/pull/11999/files/2d9ba35c..65b91b71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11999&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11999&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11999

From jlaskey at openjdk.org  Tue Jan 17 17:56:21 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Jan 2023 17:56:21 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <S6HUlJCPs6xE4WZbxuCLjFpho2Uq_ZPT7LpG1PBfAm4=.ed49590f-2c30-4e40-9950-4e3f44919c93@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Changes requested by jlaskey (Reviewer).

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 222:

> 220:         if (bb.getInt() == MAGIC) {
> 221:             return bb.order();
> 222:         }

I would have just added `public static final int REVERSE_MAGIC = 0xDADAFECA;` and add an else clause. to compare to REVERSE_MAGIC. Much simpler.

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 226:

> 224:         ByteOrder altByteOrder = bb.order() == ByteOrder.BIG_ENDIAN
> 225:                 ? ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN;
> 226:         bb.flip();

Don't you just want to rewind here?

src/java.base/share/native/libjimage/imageFile.cpp line 284:

> 282:     if (reader == NULL || !reader->open()) {
> 283:         // Failed to open.
> 284:         if (reader != NULL && reader->_invalid_magic) {

Similar here. Flip the byte order if matches IMAGE_REVERSE_MAGIC.

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

PR: https://git.openjdk.org/jdk/pull/11943

From jlaskey at openjdk.org  Tue Jan 17 18:00:20 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Jan 2023 18:00:20 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <xBZV1QhmytwS8t5NrFwcmlFFXqnEtPsgyPMsgHqDdVU=.16bd10f9-69f6-4627-8560-c60e835ab374@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

I'm in agreement with Alan that this change seems suspicious. That is, you should not attempt to run with non-native byte order.  That said, I can see where the java reader could read non-native as an analysis tool. So,  C code should continue to be an error if not the native byte order. The java code, might be useful for tools but not sure.

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

PR: https://git.openjdk.org/jdk/pull/11943

From jlaskey at openjdk.org  Tue Jan 17 18:03:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Jan 2023 18:03:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v34]
In-Reply-To: <aMzz-RB2a28FYxOS9RQNSfWihrd0oECGc0x7ZInGRzY=.6383a823-1d33-44e6-ae9f-1dcb7e589714@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <aMzz-RB2a28FYxOS9RQNSfWihrd0oECGc0x7ZInGRzY=.6383a823-1d33-44e6-ae9f-1dcb7e589714@github.com>
Message-ID: <4iErqSLrHHY_Wmv5yztRHFs5v2LGQTjez0TJMfZ_sV0=.0a73c032-240e-4957-ac28-51d93091beae@github.com>

On Wed, 11 Jan 2023 14:07:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to JDK 21

Still active.

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

PR: https://git.openjdk.org/jdk/pull/10889

From prr at openjdk.org  Tue Jan 17 18:05:14 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 18:05:14 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <KNSxgTc0PTTJMrnnClBbw3aWl-OiDixgplMRl-F38nc=.fc1273ad-2bce-44e7-ae1f-ddca61a37119@github.com>
 <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com>
 <vZLF4HQRfvxIa4lw69akNAPdD8t6YWmwGa_ARxwrtKc=.769c954d-9327-40d8-9e07-815dbab43b36@github.com>
Message-ID: <pIOV0HJbQQkRkMqZEUNMtTsmkYmsAw7SrO2qkIDwm2c=.3054d754-a519-4c59-a481-aebcf91f6673@github.com>

On Tue, 17 Jan 2023 13:35:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm.
>> 
>> Thanks @kevinrushforth for your review.
>> 
>> Yes, it had been fixed in the upstream and I just follow it.
>> Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 .
>> 
>> Or did you mean we had to sync the whole harfbuzz with the upstream?
>> If so, I would suggest doing it in a separate PR.
>> What do you think?
>> Thanks.
>
> No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says.

If the *exact* same change has been committed upstream then we are OK to take this because then when we upgrade harfbuzz (under a separate bug) whoever doing the upgrade can be blissfully ignorant of this. In fact it is because there is no easy way to be track changes on the JDK side and reapply them that we have this rule.

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

PR: https://git.openjdk.org/jdk/pull/12005

From stsypanov at openjdk.org  Tue Jan 17 18:07:37 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 18:07:37 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v3]
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <7u9rH4mq2Ts5xhr7uHDOZXSbTWDIjbz6aKuPj6usBvw=.fdfdcb63-eae6-47cd-bd40-cfd4ac4ecc77@github.com>

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

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

  Polishing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12025/files
  - new: https://git.openjdk.org/jdk/pull/12025/files/6d1397c4..cab00aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12025/head:pull/12025

PR: https://git.openjdk.org/jdk/pull/12025

From weijun at openjdk.org  Tue Jan 17 18:07:52 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jan 2023 18:07:52 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs
In-Reply-To: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
Message-ID: <bp_JV29s-XS3IOdQq25wATufxh3F9-9zBIuEoDwalgs=.7cbd18cf-136f-404f-9340-b294becc5e63@github.com>

On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR adds test coverage for pending block files in signed JAR files
> 
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
> 
> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
> 
> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

Thanks for the fix. I've created https://bugs.openjdk.org/browse/JDK-8300259.

I'll run this test on some platforms before approving it. Whenever such a test fails, it's on Windows because this or that file is still opened, but I see you've used try-with-resources all the time and hopefully everything is fine.

test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 72:

> 70: 
> 71:     private static void checkSigned(File b) throws Exception {
> 72:         try(JarFile jf = new JarFile(b, true)) {

We usually add a whitespace between a keyword (`try` here) and a left parenthesis. Also lines 75, 87, 90, 109, 128, 157, 172.

test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 85:

> 83:      */
> 84:     private static File invalidate(File s) throws Exception{
> 85:         File invalid = File.createTempFile("pending-block-file-invalidated-", ".jar");

Another suggestion. We usually just create a file in the current directory and leave it there. If the test passes, all files in the current directory are cleaned up (and yes, it also helps you confirm newly created files are properly closed on Windows). Otherwise, the files are stored in a bundle (see `jtreg -retain` option) for your diagnosis. It's a little difficult to locate these files in a shared temporary directory. If the OS is not good at clean up the directory, then it's also a waste of disk space.

test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 151:

> 149:                 .generateCertPath(Arrays.asList(ks.getCertificateChain("r")));
> 150: 
> 151:         JarSigner signer = new JarSigner.Builder(pkr, cp)

There is a `Builder` constructor that takes a `PrivateKeyEntry`.

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

PR: https://git.openjdk.org/jdk/pull/12009

From duke at openjdk.org  Tue Jan 17 18:07:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 17 Jan 2023 18:07:49 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block files
 in signed JARs
Message-ID: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>

This PR adds test coverage for pending block files in signed JAR files

A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 

JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.

The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

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

Commit messages:
 - Create JAR files in the current directory and let jtreg handle any deletion or retention of the files
 - Style: Add separating whitespace between keywords (such as try,for) and a left parenthesis
 - Use the JarSigner.Builder constructor which takes PrivateKeyEntry
 - Adds test coverage for pending block files in JarVerifier.processEntry

Changes: https://git.openjdk.org/jdk/pull/12009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300259
  Stats: 173 lines in 1 file changed: 173 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12009.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12009/head:pull/12009

PR: https://git.openjdk.org/jdk/pull/12009

From duke at openjdk.org  Tue Jan 17 18:07:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 17 Jan 2023 18:07:54 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs
In-Reply-To: <bp_JV29s-XS3IOdQq25wATufxh3F9-9zBIuEoDwalgs=.7cbd18cf-136f-404f-9340-b294becc5e63@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
 <bp_JV29s-XS3IOdQq25wATufxh3F9-9zBIuEoDwalgs=.7cbd18cf-136f-404f-9340-b294becc5e63@github.com>
Message-ID: <Aa-XVfwHC2FXYRscLYhiL4V7jcxnZXgsqXzPpanG4wg=.34e08370-e247-4928-805c-b4714aebd133@github.com>

On Tue, 17 Jan 2023 14:07:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This PR adds test coverage for pending block files in signed JAR files
>> 
>> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
>> 
>> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
>> 
>> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.
>
> test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 72:
> 
>> 70: 
>> 71:     private static void checkSigned(File b) throws Exception {
>> 72:         try(JarFile jf = new JarFile(b, true)) {
> 
> We usually add a whitespace between a keyword (`try` here) and a left parenthesis. Also lines 75, 87, 90, 109, 128, 157, 172.

Fixed

> test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 85:
> 
>> 83:      */
>> 84:     private static File invalidate(File s) throws Exception{
>> 85:         File invalid = File.createTempFile("pending-block-file-invalidated-", ".jar");
> 
> Another suggestion. We usually just create a file in the current directory and leave it there. If the test passes, all files in the current directory are cleaned up (and yes, it also helps you confirm newly created files are properly closed on Windows). Otherwise, the files are stored in a bundle (see `jtreg -retain` option) for your diagnosis. It's a little difficult to locate these files in a shared temporary directory. If the OS is not good at clean up the directory, then it's also a waste of disk space.

I'm fairly new to jteg, so this was very useful, thanks! 

I replaced Files.createTempFile with Path.of.

> test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 151:
> 
>> 149:                 .generateCertPath(Arrays.asList(ks.getCertificateChain("r")));
>> 150: 
>> 151:         JarSigner signer = new JarSigner.Builder(pkr, cp)
> 
> There is a `Builder` constructor that takes a `PrivateKeyEntry`.

Thanks, I fixed this. It was just copy/pasted over, most probably from Spec.java

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

PR: https://git.openjdk.org/jdk/pull/12009

From stsypanov at openjdk.org  Tue Jan 17 18:10:39 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 18:10:39 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v3]
In-Reply-To: <eppBkh-sxcnNvnyUeklE3iq4r6U_JL-tVDStNwmYdg4=.f5937a5b-6a17-4d06-9ac8-6fee02688768@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7ZGviu0cQ5FEf5CAZdWKgiMux5yHSTfvxI-1WHPwg2E=.43175525-9c9b-4204-a0b6-252f64d8763b@github.com>
 <RggKipVAvqKk6BLyAR9DE_fQBBQ15VEOWups-djRshY=.8e9fd79c-0fa6-4753-9232-50eea37d2950@github.com>
 <SYT6-7R_T2S-be55KOThrLr-Z5dotJhdgyT95q5hv8o=.fd491c75-f4e1-4cc9-98df-8f1cd531ef4b@github.com>
 <eppBkh-sxcnNvnyUeklE3iq4r6U_JL-tVDStNwmYdg4=.f5937a5b-6a17-4d06-9ac8-6fee02688768@github.com>
Message-ID: <OLNmwzg6dTPWmo5a1A4dTohbnq0_2ZruhHryyKm25ro=.6140d7bd-4804-4880-8b56-1d3ccc7c2873@github.com>

On Tue, 17 Jan 2023 15:30:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Precious little method handle use in lambda bootstrap since JDK 11. Though I agree with the sentiment - having fixed a number of bootstrap issues in the past - `MethodHandles` is a small step up the abstraction ladder and the code in particular already uses a number of method refs and lambdas.
>
> ok, two small changes,
> -  formatting: usually the method call in a stream are aligned with the '.' at the beginning
>     ```
>      stream
>        .filter(...)
>       .map(...)
>    ```
>    instead of at the end.
> 
> - the reduce is a max(),
>   `max(Comparator.comparingInt(List::size))`

@forax formatting is fixed. As of max() I think we can improve this even more by hoisting max() before calling ptypes()

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

PR: https://git.openjdk.org/jdk/pull/12025

From prr at openjdk.org  Tue Jan 17 18:16:01 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jan 2023 18:16:01 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

client changes are OK by me.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12005

From alanb at openjdk.org  Tue Jan 17 18:18:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jan 2023 18:18:08 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs
In-Reply-To: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
Message-ID: <tXwFisLWyZ0WzcvKfBzjUYLcANeotLNqmshBUDalRVE=.0d54a978-6b28-4c0a-b811-24ca7974b839@github.com>

On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR adds test coverage for pending block files in signed JAR files
> 
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
> 
> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
> 
> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 45:

> 43: import java.util.zip.ZipOutputStream;
> 44: 
> 45: public class PendingBlocksJar {

Would it be possible to rename this to something like SignedJarPendingBlocks or something like that so that it's clear that this is a test for signed JARs? Or maybe we created a sub-directory and move the tests for signed JARs there.

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

PR: https://git.openjdk.org/jdk/pull/12009

From duke at openjdk.org  Tue Jan 17 18:40:41 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 17 Jan 2023 18:40:41 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v18]
In-Reply-To: <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
Message-ID: <WMjqSR2AS7RvIBz3Os0bT2C_gRlzWdquYAH8e2WZc00=.763452a5-478a-40b2-b681-527251345fc2@github.com>

On Wed, 9 Nov 2022 21:06:50 GMT, iaroslavski <duke at openjdk.org> 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)
>   
>   * Fixed microbenchmarking tests

This PR is being moved to the new PR.

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

PR: https://git.openjdk.org/jdk/pull/3938

From jlu at openjdk.org  Tue Jan 17 18:41:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 18:41:30 GMT
Subject: Integrated: 8300011: Refactor code examples to use @snippet in
 java.util.TimeZone
In-Reply-To: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
References: <RxwXpSlZTJtYSTRGX69-7kJPzZzuxCJGcLHv9n8bW_A=.686fd251-545c-4337-8e43-d07b8a8ccc40@github.com>
Message-ID: <nzjJRbtPQbxZ0wKtl4Ngfur316ne-52Ryhj1APUZD3M=.2d8429de-c43d-4b72-8cd7-eb3cff6d8d72@github.com>

On Wed, 11 Jan 2023 23:41:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for _[java.util.TimeZone](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/TimeZone.html)_.
> 
> Code examples using <pre> ...  </pre> blocks are replaced with the @ snippet syntax where applicable.

This pull request has now been integrated.

Changeset: d7c05d18
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7c05d18700e512722aee078c049389733f87867
Stats:     24 lines in 1 file changed: 12 ins; 0 del; 12 mod

8300011: Refactor code examples to use @snippet in java.util.TimeZone

Reviewed-by: lancea, naoto, iris

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

PR: https://git.openjdk.org/jdk/pull/11955

From duke at openjdk.org  Tue Jan 17 18:54:13 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 17 Jan 2023 18:54:13 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs [v2]
In-Reply-To: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
Message-ID: <C6eR-gsDGOO9u4-ELduSXdACSe_sdwkGW_p5hVuC3ug=.5fdb1397-16d0-4922-b8cb-33c5dcb859e0@github.com>

> This PR adds test coverage for pending block files in signed JAR files
> 
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
> 
> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
> 
> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

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

 - Make it more clear in the @summary tag that it is the block file that is pending, not the signature file
 - Renamed test from PendingBlocksJar to more descriptive SignedJarPendingBlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12009/files
  - new: https://git.openjdk.org/jdk/pull/12009/files/acaad55c..162744ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12009&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12009&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12009.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12009/head:pull/12009

PR: https://git.openjdk.org/jdk/pull/12009

From duke at openjdk.org  Tue Jan 17 18:54:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 17 Jan 2023 18:54:16 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs [v2]
In-Reply-To: <tXwFisLWyZ0WzcvKfBzjUYLcANeotLNqmshBUDalRVE=.0d54a978-6b28-4c0a-b811-24ca7974b839@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
 <tXwFisLWyZ0WzcvKfBzjUYLcANeotLNqmshBUDalRVE=.0d54a978-6b28-4c0a-b811-24ca7974b839@github.com>
Message-ID: <Z2S6rt6KCjnZKh9rKIgOWkKqWQhzxdG5UtysM4znI_U=.144b346d-e6f7-4ef4-a6ca-7c7ca7b6b07b@github.com>

On Tue, 17 Jan 2023 18:15:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Make it more clear in the @summary tag that it is the block file that is pending, not the signature file
>>  - Renamed test from PendingBlocksJar to more descriptive SignedJarPendingBlock
>
> test/jdk/java/util/jar/JarFile/PendingBlocksJar.java line 45:
> 
>> 43: import java.util.zip.ZipOutputStream;
>> 44: 
>> 45: public class PendingBlocksJar {
> 
> Would it be possible to rename this to something like SignedJarPendingBlocks or something like that so that it's clear that this is a test for signed JARs? Or maybe we created a sub-directory and move the tests for signed JARs there.

Thanks Alan, I've renamed to 'SignedJarPendingBlock' for now!

Not sure I feel familiar enough with the code base to have a strong opinion on moving to a subdirectory. The majority (albeit small) of the tests in this folder seems to already be somehow signature-related.

Moving them in this PR would introduce conflicts with some other ongoing PRs in this area though.  Perhaps work for a separate, later PR?

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

PR: https://git.openjdk.org/jdk/pull/12009

From vlivanov at openjdk.org  Tue Jan 17 18:59:51 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 17 Jan 2023 18:59:51 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v20]
In-Reply-To: <pyVLeQ7Nsz-zQ6ByDGzBA0zW3y3T8Tw7hU62PQRKmHY=.00a93b57-85aa-4cb6-8a4a-01a5370325b6@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pyVLeQ7Nsz-zQ6ByDGzBA0zW3y3T8Tw7hU62PQRKmHY=.00a93b57-85aa-4cb6-8a4a-01a5370325b6@github.com>
Message-ID: <BMfo_ISoCjxXeSPzkk6V4efxxKZGa754pjQPBLu_Jg8=.a9e4c334-801c-4f6c-a7fe-d8e1cc4e2fa7@github.com>

On Mon, 16 Jan 2023 23:28:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing ws

Thanks, Claes. Looks good.

Please, file an RFE for the follow-up work.

src/hotspot/share/opto/machnode.cpp line 211:

> 209:     opcnt++;                          // Bump operand count
> 210:     assert( opcnt < numopnds, "Accessing non-existent operand" );
> 211: 

A leftover from a previous change?

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 168:

> 166:     // See https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.newarray.
> 167: 
> 168:     public static final int T_BOOLEAN = 4;

As an idea for a follow-up enhancement, unless there are plans to implement runtime dispatching between different stubs, the basic type can be coded as a Class and on compiler side the corresponding basic type extracted with `java_lang_Class::as_BasicType()`.

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10847

From iklam at openjdk.org  Tue Jan 17 19:00:43 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Jan 2023 19:00:43 GMT
Subject: RFR: 8292635: Improve CDSHeapVerifier testing [v2]
In-Reply-To: <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
 <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
Message-ID: <KQ88OGCdjM4Mr-1XtLBtPps3ypxVexT1SxJH_oeqx2M=.3b935652-72db-4ba6-b497-9024eb70c28e@github.com>

On Tue, 17 Jan 2023 17:40:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Moving the `ArchivedEnumTest.java` from `runtime/cds/appcds/cacheObject` to `jdk/internal/misc/CDS` so that the test will be run in jdk-tier1. This is to avoid inadvertently breakage of the test like in JDK-8292499.
>> 
>> Testing: jdk-tier1, tier3, tier4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable CDSHeapVerifier::verify() for non-debug build

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11999

From mchung at openjdk.org  Tue Jan 17 19:20:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 17 Jan 2023 19:20:04 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <pFSkTajUnC5VFlysyYHbu9U1g_hlFW-teb4ckqFh8rg=.6f99af0c-d381-4bdb-a033-9363500a00c1@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

> When jlink is cross linking, as in creating a run-time image for a different target platform, then I think we should strive to have it create the jimage file in the native endian for the target platform. .... Instead I think we need to consider determine the endian from the target java.base module.

Having jlink to determine the endianness for the target platform is a good idea.  This will improve its usability and `--endian` option could be dropped.  Currently jlink looks at the `ModuleTarget` attribute to determine the target platform, which can be extended to include endianness.  

> Right now the ModuleTarget class file attribute is not enough but a short term fix might be for jlink to have a simple mapping of known ModuleTarget values to endianness.

This is a viable short-term solution.

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

PR: https://git.openjdk.org/jdk/pull/11943

From naoto at openjdk.org  Tue Jan 17 19:27:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 19:27:45 GMT
Subject: RFR: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
In-Reply-To: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
References: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
Message-ID: <dmAQnb1hXe2QmeeWR5Ge183bS1_LAsXYe5SWur--L58=.cd42031c-b0b1-4449-a920-5cff1037e2ae@github.com>

On Fri, 13 Jan 2023 21:47:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Looks good. One minor nit (not related to your change).

src/java.base/share/classes/java/text/MessageFormat.java line 336:

> 334:  * String forParsing = "x, y, z";
> 335:  * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> 336:  * // result now equals {new String("z")}

I believe this `result` was meant for `objs`.

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

PR: https://git.openjdk.org/jdk/pull/12001

From naoto at openjdk.org  Tue Jan 17 19:40:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 19:40:25 GMT
Subject: RFR: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
In-Reply-To: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
References: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
Message-ID: <otyD3Ae4cuckIthKxv1ydeFm4TvcKQFzCqIHc31N0Iw=.ab0f66f0-0494-4160-a5a3-132c659b2608@github.com>

On Fri, 13 Jan 2023 21:47:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12001

From naoto at openjdk.org  Tue Jan 17 19:40:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 19:40:29 GMT
Subject: RFR: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
In-Reply-To: <dmAQnb1hXe2QmeeWR5Ge183bS1_LAsXYe5SWur--L58=.cd42031c-b0b1-4449-a920-5cff1037e2ae@github.com>
References: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
 <dmAQnb1hXe2QmeeWR5Ge183bS1_LAsXYe5SWur--L58=.cd42031c-b0b1-4449-a920-5cff1037e2ae@github.com>
Message-ID: <tnX_VeRahG0IkTS4_zsi7tal59cAvzZ6olAIlIz2lZk=.51f17239-04a0-4196-b3d7-2581989a0212@github.com>

On Tue, 17 Jan 2023 19:24:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> src/java.base/share/classes/java/text/MessageFormat.java line 336:
> 
>> 334:  * String forParsing = "x, y, z";
>> 335:  * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
>> 336:  * // result now equals {new String("z")}
> 
> I believe this `result` was meant for `objs`.

Ah, this PR is already `/integated`. You can fix it at a later time.

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

PR: https://git.openjdk.org/jdk/pull/12001

From jlu at openjdk.org  Tue Jan 17 19:44:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 19:44:35 GMT
Subject: Integrated: 8300093: Refactor code examples to use @snippet in
 java.text.MessageFormat
In-Reply-To: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
References: <1TQpjbUcl5hz7RVNrXF1AXvc98ooTMP1iA3LxiRmEho=.bb28548d-77d2-4399-ae77-43a45066497f@github.com>
Message-ID: <pxjeYgLVG1t5dkGVD5OG8PYQ6jm2YAo9R1jZAoIAOTc=.d50daacc-daa7-481a-a906-6317e7243fca@github.com>

On Fri, 13 Jan 2023 21:47:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.MessageFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/class-use/MessageFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

This pull request has now been integrated.

Changeset: ade08e19
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ade08e190cc28cf0ce0194fa3fb67e48dc634e07
Stats:     24 lines in 1 file changed: 12 ins; 0 del; 12 mod

8300093: Refactor code examples to use @snippet in java.text.MessageFormat

Reviewed-by: iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/12001

From forax at openjdk.org  Tue Jan 17 20:54:19 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 Jan 2023 20:54:19 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v3]
In-Reply-To: <7u9rH4mq2Ts5xhr7uHDOZXSbTWDIjbz6aKuPj6usBvw=.fdfdcb63-eae6-47cd-bd40-cfd4ac4ecc77@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7u9rH4mq2Ts5xhr7uHDOZXSbTWDIjbz6aKuPj6usBvw=.fdfdcb63-eae6-47cd-bd40-cfd4ac4ecc77@github.com>
Message-ID: <Uo3SFLIv-94bmUVc83kbvJSqm4CXeUz0k7otbz7jAjY=.42d04a59-061c-455c-ae67-f7ad8466583e@github.com>

On Tue, 17 Jan 2023 18:07:37 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polishing

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 59:

> 57: import java.nio.ByteOrder;
> 58: import java.security.ProtectionDomain;
> 59: import java.util.*;

oops

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6747:

> 6745:                 .max(Comparator.comparing(MethodType::parameterCount))
> 6746:                 .map(MethodType::ptypes)
> 6747:                 .map(longest -> List.of(Arrays.copyOfRange(longest, skipSize, longest.length)))

i think you can fuse these to map() calls

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

PR: https://git.openjdk.org/jdk/pull/12025

From redestad at openjdk.org  Tue Jan 17 20:55:08 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 20:55:08 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v21]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <iyutarPu17AS32--w38D_6SZY0CynjwEH_skKtXQXBs=.019a68ed-bd3e-4973-9e69-b231038d85ea@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

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

  Remove spurious newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/ffe5b66d..48c068bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=19-20

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

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Jan 17 20:55:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 20:55:12 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v20]
In-Reply-To: <BMfo_ISoCjxXeSPzkk6V4efxxKZGa754pjQPBLu_Jg8=.a9e4c334-801c-4f6c-a7fe-d8e1cc4e2fa7@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pyVLeQ7Nsz-zQ6ByDGzBA0zW3y3T8Tw7hU62PQRKmHY=.00a93b57-85aa-4cb6-8a4a-01a5370325b6@github.com>
 <BMfo_ISoCjxXeSPzkk6V4efxxKZGa754pjQPBLu_Jg8=.a9e4c334-801c-4f6c-a7fe-d8e1cc4e2fa7@github.com>
Message-ID: <f9vtFdxiQt0gY27IvWzP41j8zHBsvASC0EIByLU7ILk=.f592a294-928b-48c7-970b-7fa1dfaaa993@github.com>

On Tue, 17 Jan 2023 18:46:00 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trailing ws
>
> src/hotspot/share/opto/machnode.cpp line 211:
> 
>> 209:     opcnt++;                          // Bump operand count
>> 210:     assert( opcnt < numopnds, "Accessing non-existent operand" );
>> 211: 
> 
> A leftover from a previous change?

Fixed

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

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Jan 17 21:06:01 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 21:06:01 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v22]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <Dc_hKFdwo8hMhgmHXPMl7t5rMadSMLkvlseKWcUW4G0=.34b035a8-872b-40f2-8767-de2253da05a7@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:

 - Copyrights
 - Merge branch 'master' into 8282664-polyhash
 - Remove spurious newline
 - trailing ws
 - Change signature to offset + length, add sanity test
 - Adapt end input to len (fix latent bug with sub-ranges
 - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic
 - Explicitly lea external address
 - Merge branch 'master' into 8282664-polyhash
 - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types
 - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6

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

Changes: https://git.openjdk.org/jdk/pull/10847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=21
  Stats: 1062 lines in 33 files changed: 975 ins; 9 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Jan 17 21:09:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 21:09:58 GMT
Subject: Integrated: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <hBDra4o_gCI3wZyQZLIbHeBIp7IKl4oiD7TEezzasmA=.6263e969-a897-424f-86a1-e7f22015c326@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

This pull request has now been integrated.

Changeset: e37078f5
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e37078f5bb626c7ce0348a38bb86ca2ca62ba915
Stats:     1062 lines in 33 files changed: 975 ins; 9 del; 78 mod

8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: vlivanov, sviswanathan, luhenry

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

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Jan 17 21:09:56 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 21:09:56 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v21]
In-Reply-To: <iyutarPu17AS32--w38D_6SZY0CynjwEH_skKtXQXBs=.019a68ed-bd3e-4973-9e69-b231038d85ea@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <iyutarPu17AS32--w38D_6SZY0CynjwEH_skKtXQXBs=.019a68ed-bd3e-4973-9e69-b231038d85ea@github.com>
Message-ID: <u1M-QWCTf9SnBwrKQPFo5FF49Syj17HiqC7-MXAWhKY=.c1eddd20-45a2-4d65-9046-d89b7921ad50@github.com>

On Tue, 17 Jan 2023 20:55:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove spurious newline

Thanks for your patience and reviews.

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

PR: https://git.openjdk.org/jdk/pull/10847

From stsypanov at openjdk.org  Tue Jan 17 21:24:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 21:24:34 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v4]
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <WbUjYg9FZvyYQb2ezzW1oParHnNKqo_XApObn0X3AwQ=.fb7d6e20-83b2-4c19-b89a-bec4c5afac02@github.com>

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

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

  Merge map() calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12025/files
  - new: https://git.openjdk.org/jdk/pull/12025/files/cab00aee..f3fc18dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=02-03

  Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12025/head:pull/12025

PR: https://git.openjdk.org/jdk/pull/12025

From stsypanov at openjdk.org  Tue Jan 17 21:24:39 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 17 Jan 2023 21:24:39 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v3]
In-Reply-To: <Uo3SFLIv-94bmUVc83kbvJSqm4CXeUz0k7otbz7jAjY=.42d04a59-061c-455c-ae67-f7ad8466583e@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <7u9rH4mq2Ts5xhr7uHDOZXSbTWDIjbz6aKuPj6usBvw=.fdfdcb63-eae6-47cd-bd40-cfd4ac4ecc77@github.com>
 <Uo3SFLIv-94bmUVc83kbvJSqm4CXeUz0k7otbz7jAjY=.42d04a59-061c-455c-ae67-f7ad8466583e@github.com>
Message-ID: <iQ2LT9hojY9hTvO3KKP1BHvWWTvOTD27_qxnxAstaMw=.e99da464-1c2e-49f1-943c-f1cb872a446f@github.com>

On Tue, 17 Jan 2023 20:51:06 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Polishing
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 59:
> 
>> 57: import java.nio.ByteOrder;
>> 58: import java.security.ProtectionDomain;
>> 59: import java.util.*;
> 
> oops

Reverted

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6747:
> 
>> 6745:                 .max(Comparator.comparing(MethodType::parameterCount))
>> 6746:                 .map(MethodType::ptypes)
>> 6747:                 .map(longest -> List.of(Arrays.copyOfRange(longest, skipSize, longest.length)))
> 
> i think you can fuse these two map() calls

Done!

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

PR: https://git.openjdk.org/jdk/pull/12025

From darcy at openjdk.org  Tue Jan 17 21:38:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Jan 2023 21:38:03 GMT
Subject: RFR: JDK-8300321: Use link tags in javax.sql.rowset package-info
Message-ID: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>

In the course of some other work (JDK-8300133), I noticed some cases where the javadoc in the package-info file for javax.sql.rowset used HTML links where a more readable javadoc link tag would suffice.

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

Commit messages:
 - JDK-8300321: Use link tags in javax.sql.rowset package-info

Changes: https://git.openjdk.org/jdk/pull/12051/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12051&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300321
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12051.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12051/head:pull/12051

PR: https://git.openjdk.org/jdk/pull/12051

From jlu at openjdk.org  Tue Jan 17 21:39:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 21:39:00 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
Message-ID: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>

A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.


* Object[] objs = mf.parse(forParsing, new ParsePosition(0));
* // result now equals {new String("z")}


The name of the intended variable should be `objs`, not `result`

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

Commit messages:
 - Fix conflicts
 - Use correct variable (objs)

Changes: https://git.openjdk.org/jdk/pull/12050/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300308
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12050.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12050/head:pull/12050

PR: https://git.openjdk.org/jdk/pull/12050

From mcimadamore at openjdk.org  Tue Jan 17 21:40:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 17 Jan 2023 21:40:54 GMT
Subject: [jdk20] RFR: 8300275: SegmentScope.isAccessibleBy returning incorrect
 values
Message-ID: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>

The implementation of MemorySessionImpl::isAccessibleBy is incorrect, and ends up always returning `false` for scopes associated with shared arenas.
This patch rectifies that, and adds some tests.

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

Commit messages:
 - Fix bug in MemorySessionImpl::isAccessibleBy

Changes: https://git.openjdk.org/jdk20/pull/110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300275
  Stats: 24 lines in 2 files changed: 19 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/110/head:pull/110

PR: https://git.openjdk.org/jdk20/pull/110

From naoto at openjdk.org  Tue Jan 17 21:44:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 21:44:36 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
In-Reply-To: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
References: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
Message-ID: <3JznI-ESZg-WX4i12gztnolVHAPORqmjSdv-tGog8PA=.6ea03d9c-a6cc-4347-9406-fd9672f1be1b@github.com>

On Tue, 17 Jan 2023 21:28:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12050

From jlu at openjdk.org  Tue Jan 17 22:00:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 22:00:31 GMT
Subject: Withdrawn: 8300308: java.text.MessageFormat has incorrect doc comment
In-Reply-To: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
References: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
Message-ID: <q2vLnPzCwtcLAbTmMbwZQJXQPxTTFjs2xKqQppCQKkU=.bcfc239c-c457-4389-97bd-964abff2fa7e@github.com>

On Tue, 17 Jan 2023 21:28:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12050

From jlu at openjdk.org  Tue Jan 17 22:00:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 22:00:29 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
 [v2]
In-Reply-To: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
References: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
Message-ID: <70oVIgoIIfc0228rKPgYlEx_K77aJILdGyT3JUI7BqQ=.59baf97e-b295-4230-9fdf-569801784763@github.com>

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

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

 - Add missing semicolons
 - Swap to use snippet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12050/files
  - new: https://git.openjdk.org/jdk/pull/12050/files/60994b91..130127bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12050&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12050&range=00-01

  Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12050.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12050/head:pull/12050

PR: https://git.openjdk.org/jdk/pull/12050

From lancea at openjdk.org  Tue Jan 17 22:10:22 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Jan 2023 22:10:22 GMT
Subject: RFR: JDK-8300321: Use link tags in javax.sql.rowset package-info
In-Reply-To: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
References: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
Message-ID: <DKt-cFBgeGQLslUVWFFCTrP1OpKLA0MvIpd0wkDunSw=.484ed6dd-34a5-4d5e-9e13-876def238d16@github.com>

On Tue, 17 Jan 2023 21:29:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In the course of some other work (JDK-8300133), I noticed some cases where the javadoc in the package-info file for javax.sql.rowset used HTML links where a more readable javadoc link tag would suffice.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12051

From iris at openjdk.org  Tue Jan 17 22:14:31 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 17 Jan 2023 22:14:31 GMT
Subject: RFR: JDK-8300321: Use link tags in javax.sql.rowset package-info
In-Reply-To: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
References: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
Message-ID: <wD_zvqz-YcN6RZa4pVROdPNCKkM1QpN5rF8YfIbBLXA=.f40cb248-5d74-4d5c-b9d2-b03e7bd4adf3@github.com>

On Tue, 17 Jan 2023 21:29:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In the course of some other work (JDK-8300133), I noticed some cases where the javadoc in the package-info file for javax.sql.rowset used HTML links where a more readable javadoc link tag would suffice.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12051

From darcy at openjdk.org  Tue Jan 17 22:23:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Jan 2023 22:23:06 GMT
Subject: Integrated: JDK-8300321: Use link tags in javax.sql.rowset
 package-info
In-Reply-To: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
References: <dKu1iKNb9KnUs21U6ZgvEtmoEWcz8u_V_-cp_dmt0Rk=.d4023adb-7aab-4986-a875-9c6ade0f424f@github.com>
Message-ID: <3K6iUysYqBdXZyEaNBM2BBr30l08wBnlmQu4jZhYqs0=.6d384879-30d3-4684-b195-2143eec23cc5@github.com>

On Tue, 17 Jan 2023 21:29:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In the course of some other work (JDK-8300133), I noticed some cases where the javadoc in the package-info file for javax.sql.rowset used HTML links where a more readable javadoc link tag would suffice.

This pull request has now been integrated.

Changeset: 1d8b87dd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d8b87dda4f0e40b02dd025fb5fa9d0a75fc9f90
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8300321: Use link tags in javax.sql.rowset package-info

Reviewed-by: lancea, iris

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

PR: https://git.openjdk.org/jdk/pull/12051

From redestad at openjdk.org  Tue Jan 17 22:33:29 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Jan 2023 22:33:29 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v4]
In-Reply-To: <WbUjYg9FZvyYQb2ezzW1oParHnNKqo_XApObn0X3AwQ=.fb7d6e20-83b2-4c19-b89a-bec4c5afac02@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <WbUjYg9FZvyYQb2ezzW1oParHnNKqo_XApObn0X3AwQ=.fb7d6e20-83b2-4c19-b89a-bec4c5afac02@github.com>
Message-ID: <3kB0HEP3wwNt-k58_Ruc2wJeMvve3MMvuygMi1ecLYg=.7244bd26-233e-495a-8591-f611bd3b1255@github.com>

On Tue, 17 Jan 2023 21:24:34 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge map() calls

LGTM

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6752:

> 6750:                 .map(MethodHandle::type)
> 6751:                 .filter(t -> t.parameterCount() > skipSize)
> 6752:                 .max(Comparator.comparing(MethodType::parameterCount))

@forax suggested `Comparator.comparingInt` here, which may or may not help avoid some boxing.

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12025

From jlu at openjdk.org  Tue Jan 17 22:44:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 22:44:23 GMT
Subject: RFR: 8300307: Refactor code examples to use @snippet in
 java.text.DateFormat
Message-ID: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>

This PR implements JEP 413: Code Snippets in Java API Documentation for [java.text.DateFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DateFormat.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Additionally, missing semi colons were added in the code examples

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

Commit messages:
 - Use snippets, add missing semicolons

Changes: https://git.openjdk.org/jdk/pull/12053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300307
  Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12053.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12053/head:pull/12053

PR: https://git.openjdk.org/jdk/pull/12053

From jlu at openjdk.org  Tue Jan 17 22:47:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 22:47:21 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
 [v2]
In-Reply-To: <70oVIgoIIfc0228rKPgYlEx_K77aJILdGyT3JUI7BqQ=.59baf97e-b295-4230-9fdf-569801784763@github.com>
References: <xspfQK-OBBFl-WEU6mPbeSYp8BcmGOQC-xi4Bh8I7KI=.543acce4-b98d-4945-998f-b2f33cd64ee7@github.com>
 <70oVIgoIIfc0228rKPgYlEx_K77aJILdGyT3JUI7BqQ=.59baf97e-b295-4230-9fdf-569801784763@github.com>
Message-ID: <0z9_KMEzFH55yku1SQI0J3FEB4IymzPwZwnYBahESs8=.32bb241b-cce2-41f2-a884-0089f8cf75f5@github.com>

On Tue, 17 Jan 2023 22:00:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
>> 
>> 
>> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
>> * // result now equals {new String("z")}
>> 
>> 
>> The name of the intended variable should be `objs`, not `result`
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add missing semicolons
>  - Swap to use snippet

Closed, please refer to https://github.com/openjdk/jdk/pull/12054

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

PR: https://git.openjdk.org/jdk/pull/12050

From lancea at openjdk.org  Tue Jan 17 22:49:16 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Jan 2023 22:49:16 GMT
Subject: RFR: 8300307: Refactor code examples to use @snippet in
 java.text.DateFormat
In-Reply-To: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
References: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
Message-ID: <coosK3VI9SF6GNxdLWu2Lj44o-MuMjoitQjz5B6x0xs=.5c7fb8ed-a37f-49af-8a4f-61eb817594c8@github.com>

On Tue, 17 Jan 2023 22:35:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for [java.text.DateFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DateFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, missing semi colons were added in the code examples

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12053

From jlu at openjdk.org  Tue Jan 17 22:55:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 22:55:45 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
Message-ID: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>

A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.


* Object[] objs = mf.parse(forParsing, new ParsePosition(0));
* // result now equals {new String("z")}


The name of the intended variable should be `objs`, not `result`

-------------

Commit messages:
 - Revert
 - Add missing semicolons
 - Swap to use snippet
 - Fix conflicts
 - Use correct variable (objs)

Changes: https://git.openjdk.org/jdk/pull/12054/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300308
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12054/head:pull/12054

PR: https://git.openjdk.org/jdk/pull/12054

From naoto at openjdk.org  Tue Jan 17 22:55:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 22:55:46 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
In-Reply-To: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
References: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
Message-ID: <96EOcwVTWbMtLGjdAdrUmwvUodcgpHziHZ-1K1qH-6c=.085eeb7a-4ecb-4502-9733-3b2b7a9bd0a0@github.com>

On Tue, 17 Jan 2023 22:44:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12054

From kvn at openjdk.org  Tue Jan 17 22:56:02 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 17 Jan 2023 22:56:02 GMT
Subject: RFR: 8300208: Optimize Adler32 stub for AVX-512 targets.
In-Reply-To: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
References: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
Message-ID: <7TnklBoav4jqa4CH1BoqjmoWt7BQV8-YYuidn4Jdvw8=.23ee23e6-9238-4ba5-b169-6f8ec82bf55d@github.com>

On Tue, 17 Jan 2023 17:24:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch optimizes Adler32 stub for AVX512 target.
> 
> Main computation loop now uses zero extended lane widening load vector operation.
> 
> New sequence also honors AVX3Thresholds so that implementation uses existing AVX2 instruction sequence on relevant targets
> if input size is smaller than threshold limit (default 4096).
> 
> Following are the result of an [existing JMH micro ](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestAdler32.java)on various targets.
> 
> **System Configurations : Turbo frequency scaling is disabled, all the data is collected at fixed frequency of 2.8 GHz.
> SUT1   : Intel? Xeon? Platinum 8480+ Processor (Sapphire Rapids)? 56C 2S
> SUT2   : Intel(R) Xeon(R) Platinum 8380 CPU (Icelake Server) 40C 2S
> SUT3   : Intel(R) Xeon(R) Platinum 8280 CPU (Cascadelake Server) 28C 2S**
> 
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934730-68717a61-191f-4dba-8c83-2eddf6007a47.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934945-cada95ad-c93c-487f-bacc-928a2e3b5c21.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212935059-511aca3b-c736-40a2-bff6-89caf0664828.png)
> 
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Looks good to me. Let me test it.

-------------

PR: https://git.openjdk.org/jdk/pull/12045

From iris at openjdk.org  Tue Jan 17 22:56:42 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 17 Jan 2023 22:56:42 GMT
Subject: RFR: 8300307: Refactor code examples to use @snippet in
 java.text.DateFormat
In-Reply-To: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
References: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
Message-ID: <rNEee-1jOVRV7Xr_rZuUEz1QpEUfpqtG_c1yYMPg5qs=.c14c24cd-f45d-4ea4-a098-f6cc8e8151ad@github.com>

On Tue, 17 Jan 2023 22:35:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for [java.text.DateFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DateFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, missing semi colons were added in the code examples

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12053

From lancea at openjdk.org  Tue Jan 17 23:06:46 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Jan 2023 23:06:46 GMT
Subject: RFR: 8300308: java.text.MessageFormat has incorrect doc comment
In-Reply-To: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
References: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
Message-ID: <8NPD3XhUCjyiEt9d4_wuu-AcHnVHtiuKdod7FWnP0ms=.49009600-9280-4c75-8594-9a56251c4893@github.com>

On Tue, 17 Jan 2023 22:44:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12054

From naoto at openjdk.org  Tue Jan 17 23:36:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 23:36:24 GMT
Subject: RFR: 8300307: Refactor code examples to use @snippet in
 java.text.DateFormat
In-Reply-To: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
References: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
Message-ID: <PkBm1Qy5dySGTUstnea5ksF9zvYPkmABWZg8l04KFEM=.16a34e85-248b-43ca-a280-1a7638043f88@github.com>

On Tue, 17 Jan 2023 22:35:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for [java.text.DateFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DateFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, missing semi colons were added in the code examples

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12053

From jlu at openjdk.org  Tue Jan 17 23:51:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 23:51:22 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator
Message-ID: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.


Additionally, removed a floating colon in the code example

-------------

Commit messages:
 - Spacing and floating colon removal
 - Switch to snippet

Changes: https://git.openjdk.org/jdk/pull/12055/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300356
  Stats: 12 lines in 1 file changed: 0 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12055.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12055/head:pull/12055

PR: https://git.openjdk.org/jdk/pull/12055

From jlu at openjdk.org  Tue Jan 17 23:51:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jan 2023 23:51:23 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator
In-Reply-To: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
Message-ID: <RUdPSJEyMKmbtfs92E58JFlt_v5eL6DY9c456P1h1I0=.b457f53f-d2d4-4a45-9994-338c1a951d58@github.com>

On Tue, 17 Jan 2023 23:14:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> 
> Additionally, removed a floating colon in the code example

src/java.base/share/classes/java/text/CollationElementIterator.java line 87:

> 85:  *      CollationElementIterator collationElementIterator = ruleBasedCollator.getCollationElementIterator(testString);
> 86:  *      int primaryOrder = CollationElementIterator.primaryOrder(collationElementIterator.next());
> 87:  *          :

I believe this is a typo, and have removed it

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From jiefu at openjdk.org  Tue Jan 17 23:56:32 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 23:56:32 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <0NMWnUwU-YKzQ9V5AtT03yxs2OQQ6GnbrqLfi989mkg=.34ce9025-a67a-40fd-b27c-fa5aee2795be@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

> _Mailing list message from [Patrick Chen](mailto:chen.j.patrick at gmail.com) on [build-dev](mailto:build-dev at mail.openjdk.org):_
> 
> no you have to revert the commit

Why?
Is there anything wrong?
Thanks.

> 
> Le mar. 17 janv. 2023 ? 17:55, Alan Bateman <alanb at openjdk.org> a ?crit :
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230117/4dc50b9b/attachment.htm>

-------------

PR: https://git.openjdk.org/jdk/pull/12005

From jiefu at openjdk.org  Tue Jan 17 23:56:34 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 17 Jan 2023 23:56:34 GMT
Subject: RFR: 8300169: Build failure with clang-15
In-Reply-To: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
 <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com>
Message-ID: <zNOhExpbkk_FGIAYNpmeyWJQi1mEtza3Zs1rilB6bU4=.57a554af-c017-49f9-9c48-0a9b0c57a431@github.com>

On Tue, 17 Jan 2023 18:12:44 GMT, Phil Race <prr at openjdk.org> wrote:

> client changes are OK by me.

Thanks @prrace .

-------------

PR: https://git.openjdk.org/jdk/pull/12005

From naoto at openjdk.org  Tue Jan 17 23:58:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jan 2023 23:58:21 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator
In-Reply-To: <RUdPSJEyMKmbtfs92E58JFlt_v5eL6DY9c456P1h1I0=.b457f53f-d2d4-4a45-9994-338c1a951d58@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
 <RUdPSJEyMKmbtfs92E58JFlt_v5eL6DY9c456P1h1I0=.b457f53f-d2d4-4a45-9994-338c1a951d58@github.com>
Message-ID: <dyok5i_MI0NkVImu5NsZuStJ6EaLJdtwTqXpOtgxiQI=.5c3ee77b-8b2a-42f6-beef-d1b08db74389@github.com>

On Tue, 17 Jan 2023 23:15:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> 
>> Additionally, removed a floating colon in the code example
>
> src/java.base/share/classes/java/text/CollationElementIterator.java line 87:
> 
>> 85:  *      CollationElementIterator collationElementIterator = ruleBasedCollator.getCollationElementIterator(testString);
>> 86:  *      int primaryOrder = CollationElementIterator.primaryOrder(collationElementIterator.next());
>> 87:  *          :
> 
> I believe this is a typo, and have removed it

My guess is that this was meant as a vertical ellipsis, so instead of removing it, you can replace it with `?`.

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From naoto at openjdk.org  Wed Jan 18 00:01:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jan 2023 00:01:34 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator
In-Reply-To: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
Message-ID: <D_OTIIsGuSNYGBqBqoMeYeXom_2Rp-2U8m39Acam0c8=.f435cde7-e684-46a4-b211-7bb2278e0c21@github.com>

On Tue, 17 Jan 2023 23:14:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> 
> Additionally, removed a floating colon in the code example

src/java.base/share/classes/java/text/CollationElementIterator.java line 82:

> 80:  * String testString = "This is a test";
> 81:  * Collator col = Collator.getInstance();
> 82:  * if (col instanceof RuleBasedCollator) {

I'd use the pattern matching `instanceof` here

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From smarks at openjdk.org  Wed Jan 18 01:55:21 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Jan 2023 01:55:21 GMT
Subject: RFR: 8203035: Implement equals() and hashCode() for Throwable
In-Reply-To: <kUAymdlB4YL_BLTzTlvWvXjcGWRCEpe_hGU-2wr3NLo=.d53bc474-3c62-474f-a738-a5319aed1d68@github.com>
References: <kUAymdlB4YL_BLTzTlvWvXjcGWRCEpe_hGU-2wr3NLo=.d53bc474-3c62-474f-a738-a5319aed1d68@github.com>
Message-ID: <4pegwk6VrhyrLI0PJ8t6g4mH6Ge-umRYkAjFt4nYHdw=.75e5220e-5ba6-4ead-b3fb-a06fb187fd3e@github.com>

On Sat, 10 Dec 2022 18:11:30 GMT, Victor Toni <duke at openjdk.org> wrote:

> Being able to compare instances of Throwable allows simple detection of exceptions raised by the same circumstances. Comparison allows for reduction of excessive logging e.g. in hotspots without requiring custom code to compare Throwables.

I've closed [JDK-8203035](https://bugs.openjdk.org/browse/JDK-8203035) as Won't Fix; see comments there. Based on that analysis I recommend that we not proceed with this PR.

Briefly, I'd recommend that you implement your own logic for reducing logging messages based on "duplicate" exceptions. The logic for detecting duplicate exceptions is most likely application-specific and thus probably doesn't belong in the JDK.

-------------

PR: https://git.openjdk.org/jdk/pull/11624

From dholmes at openjdk.org  Wed Jan 18 02:21:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Jan 2023 02:21:25 GMT
Subject: RFR: 8292635: Improve CDSHeapVerifier testing [v2]
In-Reply-To: <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
 <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
Message-ID: <fpTAFmrfOFFZJvyBXCwXwA_Pt5Dfff4ki1b_7YvWbNM=.38145981-689b-4482-af97-cfc960b4b988@github.com>

On Tue, 17 Jan 2023 17:40:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Moving the `ArchivedEnumTest.java` from `runtime/cds/appcds/cacheObject` to `jdk/internal/misc/CDS` so that the test will be run in jdk-tier1. This is to avoid inadvertently breakage of the test like in JDK-8292499.
>> 
>> Testing: jdk-tier1, tier3, tier4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable CDSHeapVerifier::verify() for non-debug build

I'm a bit confused. The JBS issue lists two things to do to improve verification, but all this PR seems to do is move the test - in which case the JBS issue should be updated.

This PR also changes the verification logic to be available in product builds - presumably because JDK testing uses product builds not debug ones - but this is not mentioned. Can I assume this change in itself has no impact unless verification is explicitly requested?

-------------

PR: https://git.openjdk.org/jdk/pull/11999

From stsypanov at openjdk.org  Wed Jan 18 07:32:58 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 18 Jan 2023 07:32:58 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v4]
In-Reply-To: <3kB0HEP3wwNt-k58_Ruc2wJeMvve3MMvuygMi1ecLYg=.7244bd26-233e-495a-8591-f611bd3b1255@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <WbUjYg9FZvyYQb2ezzW1oParHnNKqo_XApObn0X3AwQ=.fb7d6e20-83b2-4c19-b89a-bec4c5afac02@github.com>
 <3kB0HEP3wwNt-k58_Ruc2wJeMvve3MMvuygMi1ecLYg=.7244bd26-233e-495a-8591-f611bd3b1255@github.com>
Message-ID: <CCPvZ2qwylMbrk5stPUeaNPXmgpDvwfoRP23J6Lu-1c=.8bc1b12b-f292-4fe1-94d6-a1f1902e2880@github.com>

On Tue, 17 Jan 2023 22:28:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge map() calls
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6752:
> 
>> 6750:                 .map(MethodHandle::type)
>> 6751:                 .filter(t -> t.parameterCount() > skipSize)
>> 6752:                 .max(Comparator.comparing(MethodType::parameterCount))
> 
> @forax suggested `Comparator.comparingInt` here, which may or may not help avoid some boxing.

Nice point, done!

-------------

PR: https://git.openjdk.org/jdk/pull/12025

From stsypanov at openjdk.org  Wed Jan 18 07:32:58 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 18 Jan 2023 07:32:58 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v5]
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <tU7DzztRzxUU3pe_093tQQcdyYM5wPUXN7dxJKcNvxk=.c3820dac-b0db-4641-9736-85874bbaee1a@github.com>

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Use comparingInt()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12025/files
  - new: https://git.openjdk.org/jdk/pull/12025/files/f3fc18dc..85662895

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12025&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12025/head:pull/12025

PR: https://git.openjdk.org/jdk/pull/12025

From luhenry at openjdk.org  Wed Jan 18 08:37:46 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 18 Jan 2023 08:37:46 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v22]
In-Reply-To: <Dc_hKFdwo8hMhgmHXPMl7t5rMadSMLkvlseKWcUW4G0=.34b035a8-872b-40f2-8767-de2253da05a7@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <Dc_hKFdwo8hMhgmHXPMl7t5rMadSMLkvlseKWcUW4G0=.34b035a8-872b-40f2-8767-de2253da05a7@github.com>
Message-ID: <zFN9qE9mR5FjzsUUdwUoAxSQZ0HmNHEnMJneDZwOab4=.daf0dafa-77b9-42a7-a417-b3fcd2919ccb@github.com>

On Tue, 17 Jan 2023 21:06:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - Copyrights
>  - Merge branch 'master' into 8282664-polyhash
>  - Remove spurious newline
>  - trailing ws
>  - Change signature to offset + length, add sanity test
>  - Adapt end input to len (fix latent bug with sub-ranges
>  - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic
>  - Explicitly lea external address
>  - Merge branch 'master' into 8282664-polyhash
>  - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types
>  - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6

Thanks for pushing it all the way!

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From xgong at openjdk.org  Wed Jan 18 09:08:14 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 18 Jan 2023 09:08:14 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
Message-ID: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>

The Vector API `"indexInRange(int offset, int limit)"` is used
to compute a vector mask whose lanes are set to true if the
index of the lane is inside the range specified by the `"offset"`
and `"limit"` arguments, otherwise the lanes are set to false.

There are two special cases for this API:
 1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
generated mask are false.
 2) If` "offset >= 0 && limit - offset >= vlength"`, all the
lanes of the generated mask are true. Note that `"vlength"` is
the number of vector lanes.

For such special cases, we can simply use `"maskAll(false|true)"`
to implement the API. Otherwise, the original comparison with
`"iota" `vector is needed. And for further optimization, we have
optimal instruction supported by SVE (i.e. whilelo [1]), which
can implement the API directly if the `"offset >= 0"`.

As a summary, to optimize the API, we can use the if-else branches
to handle the specific cases in java level and intrinsify the
remaining case by C2 compiler:


  public VectorMask<E> indexInRange(int offset, int limit) {
      if (offset < 0) {
          return this.and(indexInRange0Helper(offset, limit));
      } else if (offset >= limit) {
          return this.and(vectorSpecies().maskAll(false));
      } else if (limit - offset >= length()) {
          return this.and(vectorSpecies().maskAll(true));
      }
      return this.and(indexInRange0(offset, limit));
 }


The last part (i.e. `"indexInRange0"`) in the above implementation
is expected to be intrinsified by C2 compiler if the necessary IRs
are supported. Otherwise, it will fall back to the original API
implementation (i.e. `"indexInRange0Helper"`). Regarding to the
intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
with "limit - offset" as the input if the current platform supports
it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
on `"iota < limit - offset"`.

For the following java code which uses `"indexInRange"`:


static final VectorSpecies<Double> SPECIES =
                                   DoubleVector.SPECIES_PREFERRED;
static final int LENGTH = 1027;

public static double[] da;
public static double[] db;
public static double[] dc;

private static void func() {
    for (int i = 0; i < LENGTH; i += SPECIES.length()) {
        var m = SPECIES.indexInRange(i, LENGTH);
        var av = DoubleVector.fromArray(SPECIES, da, i, m);
        av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
    }
}


The core code generated with SVE 256-bit vector size is:


  ptrue   p2.d                  ; maskAll(true)
  ...
LOOP:
  ...
  sub     w11, w13, w14         ; limit - offset
  cmp     w14, w13
  b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
  cmp     w11, #0x4
  b.lt    LABEL-2               ; if (limit - offset < vlength)
  mov     p1.b, p2.b
LABEL-3:
  ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
  ...
  cmp     w14, w29
  b.cc    LOOP
  ...
LABEL-2:
  whilelo p1.d, x16, x10        ; VectorMaskGen
  ...
  b       LABEL-3
  ...
LABEL-1:
  uncommon-trap


Please note that if the array size `LENGTH` is aligned with
the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
will be optimized out by compiler and it becomes another
uncommon-trap.

For NEON, the main CFG is the same with above. But the compiler
intrinsification is different. Here is the code:


  sub     x10, x10, x12          ; limit - offset
  scvtf   d16, x10
  dup     v16.2d, v16.d[0]       ; replicateD

  mov     x8, #0xd8d0
  movk    x8, #0x84cb, lsl #16
  movk    x8, #0xffff, lsl #32
  ldr     q17, [x8], #0          ; load the "iota" const vector
  fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset


Here is the performance data of the new added benchmark on an ARM
SVE 256-bit platform:


Benchmark                               (size)  Before    After   Units
IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms


And the performance data with ARM NEON:


Benchmark                               (size)  Before    After   Units
IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms


The performance improves about `3.5x ~ 7.5x` on the vector size aligned
(1024 size) benchmarks both with NEON and SVE. And it improves about
`3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
SVE/NEON respectively. We can also observe the similar improvement on
the x86 platforms.

[1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

-------------

Commit messages:
 - 8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

Changes: https://git.openjdk.org/jdk/pull/12064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293198
  Stats: 665 lines in 41 files changed: 622 ins; 0 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/12064.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12064/head:pull/12064

PR: https://git.openjdk.org/jdk/pull/12064

From redestad at openjdk.org  Wed Jan 18 09:16:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 09:16:47 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v22]
In-Reply-To: <Dc_hKFdwo8hMhgmHXPMl7t5rMadSMLkvlseKWcUW4G0=.34b035a8-872b-40f2-8767-de2253da05a7@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <Dc_hKFdwo8hMhgmHXPMl7t5rMadSMLkvlseKWcUW4G0=.34b035a8-872b-40f2-8767-de2253da05a7@github.com>
Message-ID: <wBh824gIV3QHE9vzh276yBYffJrrPesf72qFiN0I0S8=.415b9a92-bdd7-4fda-9815-cc9577a99aae@github.com>

On Tue, 17 Jan 2023 21:06:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - Copyrights
>  - Merge branch 'master' into 8282664-polyhash
>  - Remove spurious newline
>  - trailing ws
>  - Change signature to offset + length, add sanity test
>  - Adapt end input to len (fix latent bug with sub-ranges
>  - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic
>  - Explicitly lea external address
>  - Merge branch 'master' into 8282664-polyhash
>  - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types
>  - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6

Filed https://bugs.openjdk.org/browse/JDK-8300448 to follow-up and rewrite part of or all of the inlined code as a stub call.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Wed Jan 18 09:47:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 09:47:29 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v7]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <DOefX0_u6CvCPOh9ilDphlmXnVT_PJtTuG1dx0Fhc_4=.e130c1ee-dd64-4819-90a8-49ffd00e454f@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:

 - Introduce SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier, JarSigner and SignatureFileVerifier.isSigningRelated.
   
   This introduces two subtle behavioural changes:
   
   - JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
   - JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little impact, since ZipFile.Source.isMetaName already rejects such paths.
 - jarsigner -verify should also ignore unrelated signature files
 - Style: Added whitespace separators between keyword and left parenthesis for try,while,if.Removed final accessors for some local variables.
 - Replacing File.createTempFile with Path.of lets jtreg handle retention of JARs created during the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/808d1f41..eadcc2c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=05-06

  Stats: 114 lines in 5 files changed: 48 ins; 24 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 09:51:26 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 09:51:26 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v7]
In-Reply-To: <A2yY5Asj7ib13Fd5FxZ-bk8WzKUSzEmBFLs0NPrT6G4=.87c3c9c8-2dc2-4868-a2ea-bb256f073c3e@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <UCsro35XQhSOoB-nQEfp_JJ2JlxbkMzBHJOSlK0XmkA=.5911e2e8-b406-43eb-92c1-3d4bb5bd5306@github.com>
 <A2yY5Asj7ib13Fd5FxZ-bk8WzKUSzEmBFLs0NPrT6G4=.87c3c9c8-2dc2-4868-a2ea-bb256f073c3e@github.com>
Message-ID: <i8usZN-kCjg8FvLP3pQI392DAP0n8sRErbyTE8hLODk=.23987ad0-5f60-4852-a262-2ab64bbcef1d@github.com>

On Tue, 17 Jan 2023 16:46:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I started there, but ran into some problems:
>> 
>> SignatureFileVerifier.isSigningRelated calls isBlockOrSF, but it removes the "META-INF/" prefix from the path first. So we can't assume that input to isBlockOrSF is the full path.
>> 
>> I could update SignatureFileVerifier.isSigningRelated to send the full path, but we still have another problem:
>> 
>> JarSigner.sign0 puts META-INF/ files in a vector, such that it can output them first. We want to update this method such that it outputs only files which live directly in META-INF/ first. So we still need to check for "directness" outside isBlockOrSF.
>> 
>> isBlockOrSF has 8 call sites, most of them in security sensitive and tricky code. In the end, I felt safer leaving isBlockOrSF alone and just fix the bug-relevant call sites instead. Also, being a new contributor to security-dev, I wanted to keep the PR relatively simple and easy to review.
>> 
>> WDYT?
>
> In almost every call to `isBlockOrSF`, there is already an `isInMetaInf` (or equivalent) call right before it so it's always safe. The only exception is in `jarsigner`'s `verifyJar` method:
> 
>                     hasSignature = hasSignature
>                             || SignatureFileVerifier.isBlockOrSF(name);
> 
> and it makes a subtle difference. The `unrelated-signature-files-modified.jar` your test created has SF/block files inside a sub-directory. Try verifying it with jarsigner. Here `hasSignature` is true but the SF/block is not considered signature-related, an error message will show `Signature is either not parsable or not verifiable`. If `isBlockOrSF` is modified to return false, it will be simply `jar is unsigned`.

Good catch!

I've added a guarding call to SignatureFileVerifier.isSigningRelated here, similar to the earlier call site of isBlockOrSf in this methid. I've also added a new check to the test to verify that there is no WARNING when calling jarsigner with the modified jar.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 09:56:26 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 09:56:26 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v7]
In-Reply-To: <DOefX0_u6CvCPOh9ilDphlmXnVT_PJtTuG1dx0Fhc_4=.e130c1ee-dd64-4819-90a8-49ffd00e454f@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <DOefX0_u6CvCPOh9ilDphlmXnVT_PJtTuG1dx0Fhc_4=.e130c1ee-dd64-4819-90a8-49ffd00e454f@github.com>
Message-ID: <r3R8gFstRZGxQb_V6cApkc-qTmBEKsZqznB2ZqDFzy4=.76c057f2-3f98-42a6-a93c-971dc1b03d73@github.com>

On Wed, 18 Jan 2023 09:47:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
>> 
>> The mentioned call sites needs updates to check and ignore such files.
>> 
>> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.
>
> Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Introduce SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier, JarSigner and SignatureFileVerifier.isSigningRelated.
>    
>    This introduces two subtle behavioural changes:
>    
>    - JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
>    - JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little impact, since ZipFile.Source.isMetaName already rejects such paths.
>  - jarsigner -verify should also ignore unrelated signature files
>  - Style: Added whitespace separators between keyword and left parenthesis for try,while,if.Removed final accessors for some local variables.
>  - Replacing File.createTempFile with Path.of lets jtreg handle retention of JARs created during the test

I added a few style fixes to the test which primarily adds whitespace between try,for,while,if and their following left parenthesis.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 09:56:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 09:56:28 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v7]
In-Reply-To: <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
 <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>
Message-ID: <KZFoIQoo0ovarcLVnVgEe_aJ_zsycz3hCJklKYbYSgo=.4da464bb-1b7d-4d09-83f9-fac12844a04b@github.com>

On Tue, 17 Jan 2023 16:11:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This duplicated check annoyed me also, but the existing checks have different behavior:
>> 
>> - JarVerifier.beginEntry normalizes the path to uppercase, them checks that it starts with "META-INF/" or "/META-INF/"
>> - JarSigner.sign0 does not normalize to uppercase , then checks that the path starts with "META-INF/"
>> 
>> Introducing a common method would need change behaviour of one of these methods. This change of behaviour would not be relevant to the bug being fixed in this PR.
>> 
>> Since I'm cautious of changing behaviour, I decided to keep the two methods.
>
> While `JarSigner` has not normalize to uppercase, the check is the same. As for `/META-INF/`, it must be very broken now since `JarFile::maybeInstantiateVerifier` is using `JUZFA.getManifestName(this,true)` to read the manifest and since `ZipFile` cannot see the signature-related files starting with `/META-INF/` this method will always return null.

I agree this deserves a cleanup, and since we're already deep into it it can make sense to fix this in this PR.

I have introduced SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier and  JarSigner. I also noticed that SignatureFileVerifier.isSigningRelated performs the same check, so I updated that method to also call the isInMetaInf.

This introduces two subtle behavioural changes:

- JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
- JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little practical impact, since ZipFile.Source.isMetaName already rejects such paths.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 10:02:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 10:02:00 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v8]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <o_IKu0SAyT_1BSgo0dRulW1xPMJgeIH0L6AMcNXKpgA=.3eb9c889-1f86-4a88-add3-d2e67b439955@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Renaming the test to IgnoreUnrelatedSignatureFiles to make it clear that unrelated files should be ignored.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/eadcc2c0..0cd4cc4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From forax at openjdk.org  Wed Jan 18 10:14:28 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 18 Jan 2023 10:14:28 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v5]
In-Reply-To: <tU7DzztRzxUU3pe_093tQQcdyYM5wPUXN7dxJKcNvxk=.c3820dac-b0db-4641-9736-85874bbaee1a@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <tU7DzztRzxUU3pe_093tQQcdyYM5wPUXN7dxJKcNvxk=.c3820dac-b0db-4641-9736-85874bbaee1a@github.com>
Message-ID: <__UXpY3yxHTteRIuH8DLz2-Ki-zOhSDUgKo_3Ox4SnM=.07ae2059-2093-4d97-8a41-736647e3d2f9@github.com>

On Wed, 18 Jan 2023 07:32:58 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use comparingInt()

Looks good to me,
i'm not an official reviewer but claes already review this PR so this is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12025

From redestad at openjdk.org  Wed Jan 18 10:23:32 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 10:23:32 GMT
Subject: RFR: 8300237: Minor improvements in MethodHandles [v5]
In-Reply-To: <tU7DzztRzxUU3pe_093tQQcdyYM5wPUXN7dxJKcNvxk=.c3820dac-b0db-4641-9736-85874bbaee1a@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
 <tU7DzztRzxUU3pe_093tQQcdyYM5wPUXN7dxJKcNvxk=.c3820dac-b0db-4641-9736-85874bbaee1a@github.com>
Message-ID: <8dXffq-gBV7Y7pFuJ-7EnaC-KkaScbfoz6JT0BHv6hM=.ea9e9f4b-4b66-4026-ae9f-2d97c9e29cc9@github.com>

On Wed, 18 Jan 2023 07:32:58 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use comparingInt()

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12025

From duke at openjdk.org  Wed Jan 18 10:23:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 10:23:54 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v9]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <sOkMRnxmqlxYTZxC6eOwmndErXgtaow-tkM2hS0g1K0=.8c168d84-a70e-44f0-acdc-044ecce37e23@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year of SignatureFileVerifier.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/0cd4cc4a..e0283565

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 10:31:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 10:31:33 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v10]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <bUFhyvY2dqd5T-sM4-RIkASOh-CDn9o4wC_AfmPJi68=.94336b08-1da5-4781-944c-91d2d10a4c84@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year of s.s.t.jarsigner.Main.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/e0283565..c3a19971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From alanb at openjdk.org  Wed Jan 18 10:35:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 10:35:24 GMT
Subject: [jdk20] RFR: 8300275: SegmentScope.isAccessibleBy returning
 incorrect values
In-Reply-To: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
References: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
Message-ID: <daPUg_4pINp3e0AKOG1Uk1YJmIuisaFhcSDXUsuImUE=.abcc2de6-d2d6-4d65-8954-7fb2ea3ff29f@github.com>

On Tue, 17 Jan 2023 18:30:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The implementation of MemorySessionImpl::isAccessibleBy is incorrect, and ends up always returning `false` for scopes associated with shared arenas.
> This patch rectifies that, and adds some tests.

Looks okay to me, surprised it slipped through. You probably need to update the end copyright date before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/110

From jiefu at openjdk.org  Wed Jan 18 10:35:30 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 18 Jan 2023 10:35:30 GMT
Subject: Integrated: 8300169: Build failure with clang-15
In-Reply-To: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
References: <l4-DgKqf9E9ehyGfJaO0XOq5TOfRrjM1z6i1auOLKYA=.342b6146-d4f9-4de4-a571-cd6436ebf152@github.com>
Message-ID: <bugPTQ5OV19Y9BPwcQJhkew1O3geVLxaKlsLGhG5hyc=.5e597842-eb82-471e-9c38-4894990fa04a@github.com>

On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix for the build failure with clang-15.
> 
> 1. -Wbitwise-instead-of-logical
> 
>    1) src/hotspot/share/oops/generateOopMap.cpp          <--- fixed the warning
>    2) src/hotspot/share/runtime/notificationThread.cpp   <--- keep the code and disable warnings
>    3) src/hotspot/share/runtime/serviceThread.cpp        <--- keep the code and disable warnings
> 
> 
> 2. -Wdeprecated-non-prototype (all the warnings are disabled)
> 
>    1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/`  <--- keep the code and disable warnings
>       It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
> 
>    2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c  <--- keep the code and disable warnings
> 
>    3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m  <--- fixed the warnings
> 
> 
> 3. -Wdeprecated-builtins
> 
>    Caused by files under src/java.desktop/share/native/libharfbuzz/  <--- fixed the warnings
> 
>    Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202
> 
> 4. -Wgnu-folding-constant
> 
>    Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m  <--- keep the code and disable warnings
> 
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 15a9186d
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15a9186db251f4be7a13e173842ac1bd858f984d
Stats:     15 lines in 6 files changed: 5 ins; 0 del; 10 mod

8300169: Build failure with clang-15

Reviewed-by: dholmes, prr

-------------

PR: https://git.openjdk.org/jdk/pull/12005

From fjiang at openjdk.org  Wed Jan 18 11:11:30 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 18 Jan 2023 11:11:30 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v8]
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <mLpfUcoaw_6CsS8BZD0M4sU67gPGMQ5SgonOX1UpWvg=.71ec8b24-e124-4afa-8f26-59004173f307@github.com>

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
> - [x] jdk_foreign with release/fastdebug build on linux-x64
> - [x] jdk_foreign with release/fastdebug build on linux-aarch64

Feilong Jiang 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:

 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - more code style adjustment
 - fix comment & code adjustment
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - fix callArranger
 - fix callArranger
 - fix build
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
 - code adjustment and remove unnecessary static
 - sync with JDK-8296477
 - ... and 2 more: https://git.openjdk.org/jdk/compare/e680b137...feac5fa8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11004/files
  - new: https://git.openjdk.org/jdk/pull/11004/files/c4809317..feac5fa8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=06-07

  Stats: 5459 lines in 620 files changed: 2808 ins; 769 del; 1882 mod
  Patch: https://git.openjdk.org/jdk/pull/11004.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004

PR: https://git.openjdk.org/jdk/pull/11004

From redestad at openjdk.org  Wed Jan 18 11:12:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 11:12:58 GMT
Subject: RFR: 8300489: Use ArraysSupport.vectorizedHashCode in
 j.l.CharacterName
Message-ID: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>

This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the performance win also for range-based hash calculations. Also modernized and cleaned up the surrounding code somewhat. 


Benchmark                          Mode  Cnt    Score   Error  Units
Characters.CodePoints.codePointOf  avgt   15  153.753 ? 6.119  ns/op
Characters.CodePoints.codePointOf  avgt   15  134.753 ? 4.386  ns/op # after, 1.14x


For C1 and C2 on non-x86 platforms the performance is neutral. Interpreter sees a 1-2% regression due a few added calls.

-------------

Commit messages:
 - 8300489: Use ArraysSupport.vectorizedHashCode in j.l.CharacterName

Changes: https://git.openjdk.org/jdk/pull/12068/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300489
  Stats: 30 lines in 2 files changed: 15 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12068.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12068/head:pull/12068

PR: https://git.openjdk.org/jdk/pull/12068

From duke at openjdk.org  Wed Jan 18 11:21:53 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 11:21:53 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
Message-ID: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>

The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.

Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

-------------

Commit messages:
 - Removed trailing spaces
 - Format file
 - Format file
 - Formatted
 - Added this. in BitSet(long[])
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - ... and 31 more: https://git.openjdk.org/jdk/compare/5a9490a4...57940e7f

Changes: https://git.openjdk.org/jdk/pull/11837/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300487
  Stats: 569 lines in 2 files changed: 185 ins; 45 del; 339 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From stooke at openjdk.org  Wed Jan 18 11:21:53 2023
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 18 Jan 2023 11:21:53 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <mbIAWcAzi9JxyTmx8O-GIn0evntmsD75NNAa8JTE1Iw=.684b73fa-b6fb-4e1a-8395-48ef6cc49ff5@github.com>

On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

(disclaimer - I am not a reviewer)
I think it's not recommended to do wholesale reformatting in a PR; it tends to obscure history and blurs the line between your essential changes and the non-essential changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From skuksenko at openjdk.org  Wed Jan 18 11:21:53 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Wed, 18 Jan 2023 11:21:53 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <Na1bQq4AS8uLbJ-55WA5h0Dd-JUuzIbKGEdPbRl7T9I=.2a139de5-1de8-417a-9805-85cf1886c5de@github.com>

On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

It would be better to see benchmark results other than cardinality operation.
To understand how big performance regression is.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From jwaters at openjdk.org  Wed Jan 18 11:21:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <j79TAGV00MPntbAP4hnBZQKc-EoSrRt93Xdb8APVnaA=.993e89ee-1824-46b0-8268-172b1874bd35@github.com>

On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

@fabioromano1 Would you like me to create an entry for you for the Pull Request is linked to the appropriate mailing list? When I do that you will have to change the name of this Pull Request though

Alright, just change your title to 8300487 and the renaming should be automatically taken care of

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 11:21:54 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <j79TAGV00MPntbAP4hnBZQKc-EoSrRt93Xdb8APVnaA=.993e89ee-1824-46b0-8268-172b1874bd35@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <j79TAGV00MPntbAP4hnBZQKc-EoSrRt93Xdb8APVnaA=.993e89ee-1824-46b0-8268-172b1874bd35@github.com>
Message-ID: <4og02_6Xzob87k0SyKNJrRbKYf07raayKDsjZFFx0dE=.19fd806f-7161-4405-8fc1-994d8aacb510@github.com>

On Wed, 18 Jan 2023 06:36:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> @fabioromano1 Would you like me to create an entry for you for the Pull Request is linked to the appropriate mailing list? When I do that you will have to change the name of this Pull Request though

Yes, thank you very much.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From jlaskey at openjdk.org  Wed Jan 18 11:21:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <o1nqsP_hUrKZrWXqbVG9TGgR1jNZFB8ukJXEz8V_UrY=.3a5a1065-f384-4da6-9c5c-9c166abf659f@github.com>

On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

src/java.base/share/classes/java/util/BitSet.java line 185:

> 183:     private BitSet(long[] words) {
> 184:         this.words = words;
> 185:         wordsInUse = words.length;

Why did you drop the `this.` in front of wordsInUse? (non-standard)

src/java.base/share/classes/java/util/BitSet.java line 189:

> 187:         checkInvariants();
> 188:     }
> 189:     

Make sure your editor strips trailing spaces.

src/java.base/share/classes/java/util/BitSet.java line 421:

> 419:         final long bitMask = 1L << bitIndex;
> 420:         words[wordIndex] ^= bitMask;
> 421:         cardinality += (words[wordIndex] & bitMask) != 0 ? 1 : -1;

Isn't there a race condition here? 

I'm wondering if it would not be better to cache the last cardinality and invalidate (negative cardinality) when the bit set is changed. Less intrusive and potentially quicker.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 11:21:54 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <o1nqsP_hUrKZrWXqbVG9TGgR1jNZFB8ukJXEz8V_UrY=.3a5a1065-f384-4da6-9c5c-9c166abf659f@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <o1nqsP_hUrKZrWXqbVG9TGgR1jNZFB8ukJXEz8V_UrY=.3a5a1065-f384-4da6-9c5c-9c166abf659f@github.com>
Message-ID: <CbZwzmKfvNYlrEnjHwKl08pUOLzqp4n0bzcmGXFrnjU=.c1b1e1eb-b4e0-43f3-9def-c2d49190d6ba@github.com>

On Wed, 11 Jan 2023 12:57:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> src/java.base/share/classes/java/util/BitSet.java line 185:
> 
>> 183:     private BitSet(long[] words) {
>> 184:         this.words = words;
>> 185:         wordsInUse = words.length;
> 
> Why did you drop the `this.` in front of wordsInUse? (non-standard)

Simply an oversight.

> src/java.base/share/classes/java/util/BitSet.java line 421:
> 
>> 419:         final long bitMask = 1L << bitIndex;
>> 420:         words[wordIndex] ^= bitMask;
>> 421:         cardinality += (words[wordIndex] & bitMask) != 0 ? 1 : -1;
> 
> Isn't there a race condition here? 
> 
> I'm wondering if it would not be better to cache the last cardinality and invalidate (negative cardinality) when the bit set is changed. Less intrusive and potentially quicker.

I agree with the fact that is less intrusive, but certainly not potentially quicker, since the complete recalculation of cardinality requires linear time in the value of wordsInUse

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From redestad at openjdk.org  Wed Jan 18 11:21:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <CbZwzmKfvNYlrEnjHwKl08pUOLzqp4n0bzcmGXFrnjU=.c1b1e1eb-b4e0-43f3-9def-c2d49190d6ba@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <o1nqsP_hUrKZrWXqbVG9TGgR1jNZFB8ukJXEz8V_UrY=.3a5a1065-f384-4da6-9c5c-9c166abf659f@github.com>
 <CbZwzmKfvNYlrEnjHwKl08pUOLzqp4n0bzcmGXFrnjU=.c1b1e1eb-b4e0-43f3-9def-c2d49190d6ba@github.com>
Message-ID: <hRBAnk3OTVUtVAJiGV2g5doIILMzgjprJXV5vufGAf4=.4eac30b2-0815-4a5a-87b7-30120fd1ed97@github.com>

On Wed, 11 Jan 2023 13:23:44 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/BitSet.java line 421:
>> 
>>> 419:         final long bitMask = 1L << bitIndex;
>>> 420:         words[wordIndex] ^= bitMask;
>>> 421:         cardinality += (words[wordIndex] & bitMask) != 0 ? 1 : -1;
>> 
>> Isn't there a race condition here? 
>> 
>> I'm wondering if it would not be better to cache the last cardinality and invalidate (negative cardinality) when the bit set is changed. Less intrusive and potentially quicker.
>
> I agree with the fact that is less intrusive, but certainly not potentially quicker, since the complete recalculation of cardinality requires linear time in the value of wordsInUse

A perhaps slightly less racy way would be to only read and write from `words` once:

final long newValue = words[wordIndex] ^ bitMask;
cardinality += (newValue & bitMask) != 0 ? 1 : -1;
words[wordIndex] = newValue;

.. but the fact remains that `BitSet` is not thread-safe, so I think we shouldn't complicate things to avoid or eliminate potential races. (Using a local might help the compiler to avoid the back-to-back array read, but probably doesn't matter)

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 11:21:54 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 11:21:54 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <hRBAnk3OTVUtVAJiGV2g5doIILMzgjprJXV5vufGAf4=.4eac30b2-0815-4a5a-87b7-30120fd1ed97@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <o1nqsP_hUrKZrWXqbVG9TGgR1jNZFB8ukJXEz8V_UrY=.3a5a1065-f384-4da6-9c5c-9c166abf659f@github.com>
 <CbZwzmKfvNYlrEnjHwKl08pUOLzqp4n0bzcmGXFrnjU=.c1b1e1eb-b4e0-43f3-9def-c2d49190d6ba@github.com>
 <hRBAnk3OTVUtVAJiGV2g5doIILMzgjprJXV5vufGAf4=.4eac30b2-0815-4a5a-87b7-30120fd1ed97@github.com>
Message-ID: <eamsW6MmTIrdtgM-HcCfyDlDKs4p1WReDwWdTYd1Y3s=.313c7e7e-9ee3-4f8a-8549-b47ce6bba530@github.com>

On Wed, 11 Jan 2023 15:33:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I agree with the fact that is less intrusive, but certainly not potentially quicker, since the complete recalculation of cardinality requires linear time in the value of wordsInUse
>
> A perhaps slightly less racy way would be to only read and write from `words` once:
> 
> final long newValue = words[wordIndex] ^ bitMask;
> cardinality += (newValue & bitMask) != 0 ? 1 : -1;
> words[wordIndex] = newValue;
> 
> .. but the fact remains that `BitSet` is not thread-safe, so I think we shouldn't complicate things to avoid or eliminate potential races. (Using a local might help the compiler to avoid the back-to-back array read, but probably doesn't matter)

I think the same of @cl4es.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 11:31:23 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 11:31:23 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v2]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <DHGvh7OlnSMVek78G3R91AFF_I9_Wj1kKrVjteuYiqg=.57e77cb4-0b17-4204-afdf-21281792d134@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added author to includes(BitSet)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/57940e7f..d06ed69d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From jvernee at openjdk.org  Wed Jan 18 11:35:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Jan 2023 11:35:25 GMT
Subject: [jdk20] RFR: 8300275: SegmentScope.isAccessibleBy returning
 incorrect values
In-Reply-To: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
References: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
Message-ID: <ukjOb3cNzGxuTz-X7t1WlsSDlvVepEcayKYzWVnK2Bo=.68d73ec4-db21-42f4-b90b-3e61ab5c45c3@github.com>

On Tue, 17 Jan 2023 18:30:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The implementation of MemorySessionImpl::isAccessibleBy is incorrect, and ends up always returning `false` for scopes associated with shared arenas.
> This patch rectifies that, and adds some tests.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/110

From alanb at openjdk.org  Wed Jan 18 11:42:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 11:42:22 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v2]
In-Reply-To: <DHGvh7OlnSMVek78G3R91AFF_I9_Wj1kKrVjteuYiqg=.57e77cb4-0b17-4204-afdf-21281792d134@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <DHGvh7OlnSMVek78G3R91AFF_I9_Wj1kKrVjteuYiqg=.57e77cb4-0b17-4204-afdf-21281792d134@github.com>
Message-ID: <aId_gBQMbG0s6NHsoppecbC9L6fYHuyNHUBNRajIABM=.0f925f21-691d-4490-ba09-2c3e8dcba347@github.com>

On Wed, 18 Jan 2023 11:31:23 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author to includes(BitSet)

It looks all the javadoc and several areas of the code have been re-formatted. Please revert all of this as it's impossible to see what has been changed.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 12:20:53 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 12:20:53 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v3]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <CESTTRcypSOMGtIgPnHssNgQWAVCNGTeOBdyBKafL-w=.30181c4c-97c5-40bc-b227-7470d3a1a33b@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

fabioromano1 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 43 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-2
 - Added author to includes(BitSet)
 - Removed trailing spaces
 - Format file
 - Format file
 - Formatted
 - Added this. in BitSet(long[])
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - Merge branch 'openjdk:master' into patch-2
 - ... and 33 more: https://git.openjdk.org/jdk/compare/d391b89f...206e967d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/d06ed69d..206e967d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=01-02

  Stats: 9034 lines in 717 files changed: 5331 ins; 1260 del; 2443 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From mcimadamore at openjdk.org  Wed Jan 18 12:27:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Jan 2023 12:27:03 GMT
Subject: [jdk20] RFR: 8300275: SegmentScope.isAccessibleBy returning
 incorrect values [v2]
In-Reply-To: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
References: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
Message-ID: <NNjl8y8EWL8MYW7bC4ADhmOMJF5qkbYBybvM01IeHfM=.5268bdbe-f76b-4602-ac3c-da893eeed5e3@github.com>

> The implementation of MemorySessionImpl::isAccessibleBy is incorrect, and ends up always returning `false` for scopes associated with shared arenas.
> This patch rectifies that, and adds some tests.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/110/files
  - new: https://git.openjdk.org/jdk20/pull/110/files/46f5abee..e8fcf2d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=110&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=110&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/110/head:pull/110

PR: https://git.openjdk.org/jdk20/pull/110

From duke at openjdk.org  Wed Jan 18 12:38:34 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 12:38:34 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v4]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <oF3iPQOo3JE7tXwAXwQs-tWXXvVL6Nldvq7OqvTXJpo=.f8a24a4e-fc2b-4005-8588-046133df0f17@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

fabioromano1 has updated the pull request incrementally with five additional commits since the last revision:

 - Revert "Formatted"
   
   This reverts commit dc2ee2c45a522f86cf8b9ab02c059e13ad5cabe7.
 - Revert "Format file"
   
   This reverts commit 39300ee7491e735bd890cb7b08be465efccbb4a1.
 - Revert "Format file"
   
   This reverts commit b4ac41f53a008e4326bc93761cc397f48f660a19.
 - Revert "Removed trailing spaces"
   
   This reverts commit 57940e7f931b373b0121bf86f860df47829f6324.
 - Revert "Added author to includes(BitSet)"
   
   This reverts commit d06ed69de02201cef908a7c16528690348f15583.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/206e967d..7af49d6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=02-03

  Stats: 425 lines in 1 file changed: 39 ins; 48 del; 338 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From mcimadamore at openjdk.org  Wed Jan 18 12:41:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Jan 2023 12:41:41 GMT
Subject: [jdk20] Integrated: 8300275: SegmentScope.isAccessibleBy returning
 incorrect values
In-Reply-To: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
References: <KufBXxqEs2U1K3VuswvMJEhud2kceJSK0g44YU28dP4=.4dc916f2-5d36-451d-a5b9-907ee1947e56@github.com>
Message-ID: <Q3dAEwLzacyJ8h9RzlJQGXUnN06QhMHidpdlDXivBE8=.9ca51363-79b7-47d6-b45d-0e3568207cd6@github.com>

On Tue, 17 Jan 2023 18:30:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The implementation of MemorySessionImpl::isAccessibleBy is incorrect, and ends up always returning `false` for scopes associated with shared arenas.
> This patch rectifies that, and adds some tests.

This pull request has now been integrated.

Changeset: b9275a8e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/b9275a8ed1c462cfad33dab140022e5968765e58
Stats:     26 lines in 2 files changed: 19 ins; 2 del; 5 mod

8300275: SegmentScope.isAccessibleBy returning incorrect values

Reviewed-by: alanb, jvernee

-------------

PR: https://git.openjdk.org/jdk20/pull/110

From duke at openjdk.org  Wed Jan 18 12:43:31 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 12:43:31 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
> 
> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added author and reverse the cicle order in includes(BitSet)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/7af49d6c..7f860b79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 12:43:33 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 12:43:33 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v2]
In-Reply-To: <aId_gBQMbG0s6NHsoppecbC9L6fYHuyNHUBNRajIABM=.0f925f21-691d-4490-ba09-2c3e8dcba347@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <DHGvh7OlnSMVek78G3R91AFF_I9_Wj1kKrVjteuYiqg=.57e77cb4-0b17-4204-afdf-21281792d134@github.com>
 <aId_gBQMbG0s6NHsoppecbC9L6fYHuyNHUBNRajIABM=.0f925f21-691d-4490-ba09-2c3e8dcba347@github.com>
Message-ID: <bZVYXDptx3Cf_VEaAisIzaf_w_4ris4p13Pd0mFeEjc=.dcd2d6a1-f24d-4b9c-b4aa-4ef84d1ed1e1@github.com>

On Wed, 18 Jan 2023 11:37:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It looks all the javadoc and several areas of the code have been re-formatted. Please revert all of this as it's impossible to see what has been changed.

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 12:56:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 12:56:32 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v11]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <uFn5EC45layGJeaCz2on57PUiWq7GUxd-D1QShZiqeQ=.97a43c0d-81d6-44ae-a0ec-4e8b5e3b7529@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - The accidental regression where MANIFEST.MF was incorrecly not matched by SignatureFileVerifier.isSigningRelated revealed was not caught by any test. Adding a sanity check to IgnoreUnrelatedSignatureFiles which verifies that a basic signed JAR has the expected manifest sections.
 - The update of SignatureFileVerifier.isSigningRelated to call isInMetaInf accidentally removed "META-INF/" prefix stripping. This broke some checks in the remainder of this method.
   
   I chose to restore current behaviour by comparing MANIFEST.MF and "SIG-" files using the full path. This saves the allocation caused by substring and also makes sure isBlockOrSF now always called with the full path.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/c3a19971..34873625

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=09-10

  Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 13:01:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 13:01:23 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v11]
In-Reply-To: <KZFoIQoo0ovarcLVnVgEe_aJ_zsycz3hCJklKYbYSgo=.4da464bb-1b7d-4d09-83f9-fac12844a04b@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
 <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>
 <KZFoIQoo0ovarcLVnVgEe_aJ_zsycz3hCJklKYbYSgo=.4da464bb-1b7d-4d09-83f9-fac12844a04b@github.com>
Message-ID: <zs0q4DEMrm_AC2VVhv5e08IwlgHC2bnzKbnSJ88uFjM=.ab0f4fc9-cfc6-4a03-9576-5e3e582d7428@github.com>

On Wed, 18 Jan 2023 09:51:35 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> While `JarSigner` has not normalize to uppercase, the check is the same. As for `/META-INF/`, it must be very broken now since `JarFile::maybeInstantiateVerifier` is using `JUZFA.getManifestName(this,true)` to read the manifest and since `ZipFile` cannot see the signature-related files starting with `/META-INF/` this method will always return null.
>
> I agree this deserves a cleanup, and since we're already deep into it it can make sense to fix this in this PR.
> 
> I have introduced SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier and  JarSigner. I also noticed that SignatureFileVerifier.isSigningRelated performs the same check, so I updated that method to also call the isInMetaInf.
> 
> This introduces two subtle behavioural changes:
> 
> - JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
> - JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little practical impact, since ZipFile.Source.isMetaName already rejects such paths.

When introducing the call to isInMetaInf in isSigningRelated, I accidentally broke the matching of MANIFEST.MF and SIG-* files.

When fixing this regression, I now match against the full path instead of the existing prefix stripping substring. (A nice side effect of this is that isBlockOrSF is now always called with the full path)

Since the regression was not caught by any existing test, I'm also adding a sanity check that a basic signed JAR has the expected sections in MANIFEST.MF. (The regression introduced a section for META-INF/MANIFEST.MF which seemed to not be caught by tests)

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From jdowland at openjdk.org  Wed Jan 18 13:31:30 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Wed, 18 Jan 2023 13:31:30 GMT
Subject: RFR: 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid
 results on 32 bit systems
Message-ID: <FyT__JTrsOsswaQlvPCOk-3mSXK0igHJAl67X9BIhtk=.a276d057-d5b1-435d-8f94-69aea63ba876@github.com>

This is a fix for https://bugs.openjdk.org/browse/JDK-8300119 (CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems). Thanks to @jerboaa Severin Gehwolf for figuring out the solution.

The problem is demonstrated by test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which fails on 32-bit x86 in HEAD, and passes after applying this patch.

I tested this on an amd64 system with a cross-compiled JDK. I needed to override the default docker container for the test, to get one with a 32-bit userland. (the precise choice was also dictated by ABI matching my main development machine):


$JT_HOME/bin/jtreg -v -Djdk.test.docker.retain.image=true -Djdk.test.docker.image.name=i386/debian -Djdk.test.docker.image.version=testing-slim -jdk:$JAVA_HOME test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

-------------

Commit messages:
 - 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems

Changes: https://git.openjdk.org/jdk/pull/12069/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12069&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300119
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12069.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12069/head:pull/12069

PR: https://git.openjdk.org/jdk/pull/12069

From stooke at openjdk.org  Wed Jan 18 13:43:30 2023
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 18 Jan 2023 13:43:30 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <Na1bQq4AS8uLbJ-55WA5h0Dd-JUuzIbKGEdPbRl7T9I=.2a139de5-1de8-417a-9805-85cf1886c5de@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Na1bQq4AS8uLbJ-55WA5h0Dd-JUuzIbKGEdPbRl7T9I=.2a139de5-1de8-417a-9805-85cf1886c5de@github.com>
Message-ID: <XTpEtelyKth7Ag-qeI-ha6pcVy9Z4QU45ksuNpiXfvs=.953b4e14-ec04-4b32-9cd2-dce19ed79123@github.com>

On Wed, 11 Jan 2023 16:02:40 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> It would be better to see benchmark results other than cardinality operation. To understand how big performance regression is.

Agreed - I suspect this is adding unnecessary overhead to the most common uses of BitSet; I'd be tempted to roll my own if this went in.  Benchmarks could add some level of comfort.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 13:44:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 13:44:37 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v11]
In-Reply-To: <zs0q4DEMrm_AC2VVhv5e08IwlgHC2bnzKbnSJ88uFjM=.ab0f4fc9-cfc6-4a03-9576-5e3e582d7428@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
 <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>
 <KZFoIQoo0ovarcLVnVgEe_aJ_zsycz3hCJklKYbYSgo=.4da464bb-1b7d-4d09-83f9-fac12844a04b@github.com>
 <zs0q4DEMrm_AC2VVhv5e08IwlgHC2bnzKbnSJ88uFjM=.ab0f4fc9-cfc6-4a03-9576-5e3e582d7428@github.com>
Message-ID: <MiMON9m1-uVAqR28j0nHDAX52rnuxzf1XeIPREJqat8=.2c5bf31f-339d-486f-94a6-3a8c28ea9233@github.com>

On Wed, 18 Jan 2023 12:57:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> I agree this deserves a cleanup, and since we're already deep into it it can make sense to fix this in this PR.
>> 
>> I have introduced SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier and  JarSigner. I also noticed that SignatureFileVerifier.isSigningRelated performs the same check, so I updated that method to also call the isInMetaInf.
>> 
>> This introduces two subtle behavioural changes:
>> 
>> - JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
>> - JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little practical impact, since ZipFile.Source.isMetaName already rejects such paths.
>
> When introducing the call to isInMetaInf in isSigningRelated, I accidentally broke the matching of MANIFEST.MF and SIG-* files.
> 
> When fixing this regression, I now match against the full path instead of the existing prefix stripping substring. (A nice side effect of this is that isBlockOrSF is now always called with the full path)
> 
> Since the regression was not caught by any existing test, I'm also adding a sanity check that a basic signed JAR has the expected sections in MANIFEST.MF. (The regression introduced a section for META-INF/MANIFEST.MF which seemed to not be caught by tests)

On a similar note, I added test covering for the matching of custom SIG-* files in SignatureFileVerifier.isSigningRelated.

The test now checks both valid and invalid SIG- file extensions and directory locations inside/outside META-INF

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 13:49:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 13:49:18 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v12]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <jBcH93F2Suf-8tWoZRudDUVm5EdRSjc-kv7vQdb-tKo=.e8e56802-14a9-454a-9569-c04c864532a6@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Link to a more recent version of the JAR File Specification
 - Add test coverage for matching of custom SIG-* files in SignatureFileVerifier.isSigningRelated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/34873625..de3c6781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=10-11

  Stats: 64 lines in 2 files changed: 56 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From alanb at openjdk.org  Wed Jan 18 13:50:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 13:50:16 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <b1ggi6Y5FuWURs6XF28jjPSxRCo9YRHdvhnzninuMt0=.d0024563-c476-47e5-b818-47986e93df76@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

As others have said, I think this will need a set of benchmarks to see what the impact, if any, on other methods.

Also I think it would be better to separate out the proposal to add includes(BitSet) as that is a different issue to the cardinality method.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From sgehwolf at openjdk.org  Wed Jan 18 13:51:18 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 18 Jan 2023 13:51:18 GMT
Subject: RFR: 8300119: CgroupMetrics.getTotalMemorySize0() can report
 invalid results on 32 bit systems
In-Reply-To: <FyT__JTrsOsswaQlvPCOk-3mSXK0igHJAl67X9BIhtk=.a276d057-d5b1-435d-8f94-69aea63ba876@github.com>
References: <FyT__JTrsOsswaQlvPCOk-3mSXK0igHJAl67X9BIhtk=.a276d057-d5b1-435d-8f94-69aea63ba876@github.com>
Message-ID: <m9ERlp3K-irG1yPAAt8MQEAij-I1gqwx1PlhcPzZXDI=.c25dd718-9b9a-45b5-8443-c807227ff1c2@github.com>

On Wed, 18 Jan 2023 13:20:06 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> This is a fix for https://bugs.openjdk.org/browse/JDK-8300119 (CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems). Thanks to @jerboaa Severin Gehwolf for figuring out the solution.
> 
> The problem is demonstrated by test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which fails on 32-bit x86 in HEAD, and passes after applying this patch.
> 
> I tested this on an amd64 system with a cross-compiled JDK. I needed to override the default docker container for the test, to get one with a 32-bit userland. (the precise choice was also dictated by ABI matching my main development machine):
> 
> 
> $JT_HOME/bin/jtreg -v -Djdk.test.docker.retain.image=true -Djdk.test.docker.image.name=i386/debian -Djdk.test.docker.image.version=testing-slim -jdk:$JAVA_HOME test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12069

From jlaskey at openjdk.org  Wed Jan 18 13:53:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 18 Jan 2023 13:53:04 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <vABwPzsyuj2lqPcrm-pUZQ9UDNq0hOtCMvqyN1bV8DM=.92043b9a-be45-4b80-9133-176cf1756183@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

In that vein, I wonder if this feature would be better implemented in a subclass of BitSet (BitSet is not a final class.)

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 13:53:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 13:53:55 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v13]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <Il3x5im9gDa_41gaQWfosmqAzTFx9SOmQuwN7jDQjjg=.794938c4-87e2-4f3f-b844-cb59e50a705b@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Style: Add whitespace between if and left parenthesis

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/de3c6781..7aeef1c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From stsypanov at openjdk.org  Wed Jan 18 13:59:48 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 18 Jan 2023 13:59:48 GMT
Subject: Integrated: 8300237: Minor improvements in MethodHandles
In-Reply-To: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
References: <9VA9pFEITyjz86qdgitnZTOnwVsH80fhDN9447zmFGM=.38835a40-0e72-44f5-8a80-8882aea10399@github.com>
Message-ID: <yxwMvBSAo1liP7jnNCef5s-jHtVRvP4oxPy-yGMPFPw=.053fe813-a48a-4789-94f7-6319cba3f8ca@github.com>

On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`

This pull request has now been integrated.

Changeset: 754f6e61
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/754f6e6116b8889c49abf34d01f6fc3e9f1b3cb7
Stats:     15 lines in 1 file changed: 1 ins; 6 del; 8 mod

8300237: Minor improvements in MethodHandles

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/12025

From redestad at openjdk.org  Wed Jan 18 14:10:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 14:10:09 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <-44ve_mObDKktPn063D_GqFhFDoDlze8-SsbqNiguVc=.72a301f3-0806-45f1-9e95-2075ec6ae48f@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

I'll additionally note that there was a recent enhancement to enable vectorization of loops over `Long.bitCount(long)`, which should help `BitSet.cardinality()` calls by a large factor: https://bugs.openjdk.org/browse/JDK-8278868 - this can mean building up and then invoking an unchanged `cardinality()` is likely to be cheaper than the extra book-keeping to maintain a derived `cardinality` value. How does performance of `BitSet.cardinality()` compare before/after JDK 19? If there's a large improvement the need for this approach might have diminished.

Perhaps caching the result of `cardinality()` is a less intrusive alternative, but as @JimLaskey is suggesting perhaps this would be better conceptualized as a subclass.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From uschindler at openjdk.org  Wed Jan 18 14:18:23 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 18 Jan 2023 14:18:23 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <uIh0WQ-k4Xwv3U9_Q7kw_Ve4o_dHjb73zg6-KuRUa74=.ed17ba9a-be3a-4178-bb87-af0ec96871ca@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

As one dealing with bitsets very often: In my opinion, adding this to bitset adds too much overhead on the hot methods like set/clear methods. Especially loops that populate a BitSet with values, I am not sure if the whole loop can be vectorized by Hotspot after this patch.

>From my experience with Apache Lucene it has been shown, that you use bitsets often to track existence/not existence in very hot loops. Calling cardinality() is done only after you have build the bitset and before you use it in a read-only way. 

I know there are other usages patterns, but also code using BitSet as a compact `Set<Integer>` does not need cardinality information.

I also have a comment about the code: There is an assert-only method called `checkInvariants()` that is executed after all bulk operations. This one should also check the cardinality fits the current words. This is especially important after those crazy methods that intersect bitsets and have special handling of first/last word.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From uschindler at openjdk.org  Wed Jan 18 14:23:46 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Wed, 18 Jan 2023 14:23:46 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <lNMxCqHcSMIOMMqZJBaRBARsyRw-KA4mxAFOmc_zDKM=.0631ea13-c582-45a0-9654-651c37fdfb3c@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

I think `includes(BitSet)` is a separate issue and can be done in a separate PR. It also needs a CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Wed Jan 18 14:37:38 2023
From: duke at openjdk.org (fabioromano1)
Date: Wed, 18 Jan 2023 14:37:38 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <uIh0WQ-k4Xwv3U9_Q7kw_Ve4o_dHjb73zg6-KuRUa74=.ed17ba9a-be3a-4178-bb87-af0ec96871ca@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
 <uIh0WQ-k4Xwv3U9_Q7kw_Ve4o_dHjb73zg6-KuRUa74=.ed17ba9a-be3a-4178-bb87-af0ec96871ca@github.com>
Message-ID: <zy1DZukY8Jg5BnjBKIfQwIDlxvt2PTTnDRe-ncPg2dw=.5ee79b26-4fa1-4614-9b65-418119755ce3@github.com>

On Wed, 18 Jan 2023 14:15:17 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> As one dealing with bitsets very often: In my opinion, adding this to bitset adds too much overhead on the hot methods like set/clear methods. Especially loops that populate a BitSet with values, I am not sure if the whole loop can be vectorized by Hotspot after this patch.
> 
> From my experience with Apache Lucene it has been shown, that you use bitsets often to track existence/not existence in very hot loops. Calling cardinality() is done only after you have build the bitset and before you use it in a read-only way.
> 
> I know there are other usages patterns, but also code using BitSet as a compact `Set<Integer>` does not need cardinality information.
> 
> I also have a comment about the code: There is an assert-only method called `checkInvariants()` that is executed after all bulk operations. This one should also check the cardinality fits the current words. This is especially important after those crazy methods that intersect bitsets and have special handling of first/last word.

I have already added a condition that asserts 0 <= cardinality <= length().

In my personal experience, I used BitSet for implementing a set of candidates for a sudoku solver, and the call to cardinality is needed often, and obviously is not read-only, since some candidates can be removed after the call.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From alanb at openjdk.org  Wed Jan 18 15:48:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 15:48:05 GMT
Subject: RFR: 8208077: File.listRoots performance degradation
Message-ID: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>

The Windows implementation of File.listRoots was changed in JDK 10 to test the root directory of each "logical drive" to see that it exists. The motive was to filter out drive letters corresponding to removable media where the media is not present. This is problematic for a number of reasons that include performance (esp. for mapped drives), inconsistency with FileSystem::getRootDirectories, and surprising behavior when media is re-inserted. After re-examining this area again, the best thing seems to be just undo this change so that File.listRoots doesn't attempt to do the problematic filtering.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12072/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8208077
  Stats: 29 lines in 2 files changed: 17 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12072.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12072/head:pull/12072

PR: https://git.openjdk.org/jdk/pull/12072

From duke at openjdk.org  Wed Jan 18 16:08:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 16:08:39 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v14]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <Ew0IE4upWagFso8S3tQ_JgcJ6g_MUX8_aZEjvI9cO8Q=.ad65e88e-6e43-4143-8fc3-e7134c655e11@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test VerifyUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Improve test coverage of SignatureFileVerifier.isSigningRelated by adding META-INF/unrelated.txt and META-INF/SIG- files with invalid as well as no file extension

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/7aeef1c6..cf93bfc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=12-13

  Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From duke at openjdk.org  Wed Jan 18 16:13:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 18 Jan 2023 16:13:17 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v14]
In-Reply-To: <MiMON9m1-uVAqR28j0nHDAX52rnuxzf1XeIPREJqat8=.2c5bf31f-339d-486f-94a6-3a8c28ea9233@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <iVPOOL5BevDfD4plUWFMzKMR04sGeGiIO9iIbnxIGhI=.5d7ad297-85fb-4d9d-9d8c-44abece9daf1@github.com>
 <HW2c5J32At6oouTNDIR8yuz5ikaUADNTAmEsfb7jdvA=.e6c5195f-a563-40d4-8b25-877c155edb68@github.com>
 <z3HmhFZiy2-qDk23oZG-_jFAx27K4PL5YC7dzX-Li5Y=.a7d0dc20-37c1-4620-bc58-390610ba721f@github.com>
 <KZFoIQoo0ovarcLVnVgEe_aJ_zsycz3hCJklKYbYSgo=.4da464bb-1b7d-4d09-83f9-fac12844a04b@github.com>
 <zs0q4DEMrm_AC2VVhv5e08IwlgHC2bnzKbnSJ88uFjM=.ab0f4fc9-cfc6-4a03-9576-5e3e582d7428@github.com>
 <MiMON9m1-uVAqR28j0nHDAX52rnuxzf1XeIPREJqat8=.2c5bf31f-339d-486f-94a6-3a8c28ea9233@github.com>
Message-ID: <pPUHq7nvqzph7KpOY-CZIe0XB1IsbHgjqUtxlwtYvJM=.5e2bd42f-cc47-46fc-bafb-c50a1f522839@github.com>

On Wed, 18 Jan 2023 13:42:12 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> When introducing the call to isInMetaInf in isSigningRelated, I accidentally broke the matching of MANIFEST.MF and SIG-* files.
>> 
>> When fixing this regression, I now match against the full path instead of the existing prefix stripping substring. (A nice side effect of this is that isBlockOrSF is now always called with the full path)
>> 
>> Since the regression was not caught by any existing test, I'm also adding a sanity check that a basic signed JAR has the expected sections in MANIFEST.MF. (The regression introduced a section for META-INF/MANIFEST.MF which seemed to not be caught by tests)
>
> On a similar note, I added test covering for the matching of custom SIG-* files in SignatureFileVerifier.isSigningRelated.
> 
> The test now checks both valid and invalid SIG- file extensions and directory locations inside/outside META-INF

Added test cases for:

- META-INF/unrelated.txt (Unrelated file in META-INF)
- META-INF/SIG-CUSTOM (No extension is ok)
- META-INF/SIG-CUSTOM2. (Extension too short)
- META-INF/SIG-CUSTOM2.ABCD (Extension too long)

Reading the Jar File Specification, I cannot see that it explicitly allows no extension for SIG- files, but that's what the current code does. It feels safest to leave it that way.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From lancea at openjdk.org  Wed Jan 18 16:21:14 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Jan 2023 16:21:14 GMT
Subject: RFR: 8208077: File.listRoots performance degradation
In-Reply-To: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
References: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
Message-ID: <AXlim6G518buXQCyk4sHQkZ3ysOf53Aa9RIIMsRxveE=.eeb3ba12-9a49-44dc-b8a5-66f3c4cc545d@github.com>

On Wed, 18 Jan 2023 14:16:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The Windows implementation of File.listRoots was changed in JDK 10 to test the root directory of each "logical drive" to see that it exists. The motive was to filter out drive letters corresponding to removable media where the media is not present. This is problematic for a number of reasons that include performance (esp. for mapped drives), inconsistency with FileSystem::getRootDirectories, and surprising behavior when media is re-inserted. After re-examining this area again, the best thing seems to be just undo this change so that File.listRoots doesn't attempt to do the problematic filtering.

Looks good Alan, thank you for revisiting this issue

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12072

From bpb at openjdk.org  Wed Jan 18 16:21:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Jan 2023 16:21:14 GMT
Subject: RFR: 8208077: File.listRoots performance degradation
In-Reply-To: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
References: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
Message-ID: <kk2QRDOxRArvmjM6WK-Y4ODi9sV1S-zY3shEcTnKM78=.363bd9f4-0b2d-4d79-9c51-ce7a29532541@github.com>

On Wed, 18 Jan 2023 14:16:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The Windows implementation of File.listRoots was changed in JDK 10 to test the root directory of each "logical drive" to see that it exists. The motive was to filter out drive letters corresponding to removable media where the media is not present. This is problematic for a number of reasons that include performance (esp. for mapped drives), inconsistency with FileSystem::getRootDirectories, and surprising behavior when media is re-inserted. After re-examining this area again, the best thing seems to be just undo this change so that File.listRoots doesn't attempt to do the problematic filtering.

Comparing to `FileSystem::getRootDirectories` is good.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12072

From alanb at openjdk.org  Wed Jan 18 16:25:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 16:25:16 GMT
Subject: RFR: 8300489: Use ArraysSupport.vectorizedHashCode in
 j.l.CharacterName
In-Reply-To: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
References: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
Message-ID: <Ir9LLGB1_VLujNkKyFFLoy7HcYK4CMmwXRieMFPPwTA=.b45005d2-c8e5-4f79-937a-2d2ea60d5943@github.com>

On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the performance win also for range-based hash calculations. Also modernized and cleaned up the surrounding code somewhat. 
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> Characters.CodePoints.codePointOf  avgt   15  153.753 ? 6.119  ns/op
> Characters.CodePoints.codePointOf  avgt   15  134.753 ? 4.386  ns/op # after, 1.14x
> 
> 
> For C1 and C2 on non-x86 platforms the performance is neutral. Interpreter sees a 1-2% regression due a few added calls.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12068

From kvn at openjdk.org  Wed Jan 18 16:29:16 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 18 Jan 2023 16:29:16 GMT
Subject: RFR: 8300208: Optimize Adler32 stub for AVX-512 targets.
In-Reply-To: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
References: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
Message-ID: <Tpt28bhTwtlHL3kKuoGMQAXIcNa0490MTEGXu00iqrc=.0d5ab48d-ec02-43e6-9435-cdcfcbec43b8@github.com>

On Tue, 17 Jan 2023 17:24:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch optimizes Adler32 stub for AVX512 target.
> 
> Main computation loop now uses zero extended lane widening load vector operation.
> 
> New sequence also honors AVX3Thresholds so that implementation uses existing AVX2 instruction sequence on relevant targets
> if input size is smaller than threshold limit (default 4096).
> 
> Following are the result of an [existing JMH micro ](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestAdler32.java)on various targets.
> 
> **System Configurations : Turbo frequency scaling is disabled, all the data is collected at fixed frequency of 2.8 GHz.
> SUT1   : Intel? Xeon? Platinum 8480+ Processor (Sapphire Rapids)? 56C 2S
> SUT2   : Intel(R) Xeon(R) Platinum 8380 CPU (Icelake Server) 40C 2S
> SUT3   : Intel(R) Xeon(R) Platinum 8280 CPU (Cascadelake Server) 28C 2S**
> 
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934730-68717a61-191f-4dba-8c83-2eddf6007a47.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934945-cada95ad-c93c-487f-bacc-928a2e3b5c21.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212935059-511aca3b-c736-40a2-bff6-89caf0664828.png)
> 
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

My testing passed. You need second review.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12045

From redestad at openjdk.org  Wed Jan 18 17:02:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 17:02:09 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder
Message-ID: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>

`ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.

Before:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op

After:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

-------------

Commit messages:
 - Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder

Changes: https://git.openjdk.org/jdk/pull/12077/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12077&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300493
  Stats: 116 lines in 4 files changed: 99 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12077.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12077/head:pull/12077

PR: https://git.openjdk.org/jdk/pull/12077

From naoto at openjdk.org  Wed Jan 18 17:10:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jan 2023 17:10:16 GMT
Subject: RFR: 8300489: Use ArraysSupport.vectorizedHashCode in
 j.l.CharacterName
In-Reply-To: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
References: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
Message-ID: <VfgpUOOtjsAVzi6kqi8PyWrySHL6xHAm2C0HTuxEvVM=.be373ebc-9664-4649-a80c-c1c369610ba9@github.com>

On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the performance win also for range-based hash calculations. Also modernized and cleaned up the surrounding code somewhat. 
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> Characters.CodePoints.codePointOf  avgt   15  153.753 ? 6.119  ns/op
> Characters.CodePoints.codePointOf  avgt   15  134.753 ? 4.386  ns/op # after, 1.14x
> 
> 
> For C1 and C2 on non-x86 platforms the performance is neutral. Interpreter sees a 1-2% regression due a few added calls.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12068

From redestad at openjdk.org  Wed Jan 18 17:42:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 17:42:22 GMT
Subject: RFR: 8300489: Use ArraysSupport.vectorizedHashCode in
 j.l.CharacterName
In-Reply-To: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
References: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
Message-ID: <0zvcOU207xe9dR8QJeo1Y4sQQu2AkFSPlfMwQKWHQ18=.bf3f3529-d21f-4983-9ec4-d30a567fbdb9@github.com>

On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the performance win also for range-based hash calculations. Also modernized and cleaned up the surrounding code somewhat. 
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> Characters.CodePoints.codePointOf  avgt   15  153.753 ? 6.119  ns/op
> Characters.CodePoints.codePointOf  avgt   15  134.753 ? 4.386  ns/op # after, 1.14x
> 
> 
> For C1 and C2 on non-x86 platforms the performance is neutral. Interpreter sees a 1-2% regression due a few added calls.

Thanks for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12068

From redestad at openjdk.org  Wed Jan 18 17:42:23 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Jan 2023 17:42:23 GMT
Subject: Integrated: 8300489: Use ArraysSupport.vectorizedHashCode in
 j.l.CharacterName
In-Reply-To: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
References: <_MBuyd4RUJQZ3Z-5lARtGlrYDGvgLDKqpjzSnRo7OgY=.f659e4c1-09bc-4f09-bd14-9b8851253c05@github.com>
Message-ID: <hgM39v18sue2S_RiAOQPwynmXisFgDi9HLSXU15w9eo=.d84858c1-761f-4e03-9e7d-a666f17a98a4@github.com>

On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the performance win also for range-based hash calculations. Also modernized and cleaned up the surrounding code somewhat. 
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> Characters.CodePoints.codePointOf  avgt   15  153.753 ? 6.119  ns/op
> Characters.CodePoints.codePointOf  avgt   15  134.753 ? 4.386  ns/op # after, 1.14x
> 
> 
> For C1 and C2 on non-x86 platforms the performance is neutral. Interpreter sees a 1-2% regression due a few added calls.

This pull request has now been integrated.

Changeset: 3ea0b8bc
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ea0b8bc253f1498895a879681406ecc15f37afb
Stats:     30 lines in 2 files changed: 15 ins; 5 del; 10 mod

8300489: Use ArraysSupport.vectorizedHashCode in j.l.CharacterName

Reviewed-by: alanb, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12068

From ccheung at openjdk.org  Wed Jan 18 18:13:14 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 18 Jan 2023 18:13:14 GMT
Subject: RFR: 8292635: Run ArchivedEnumTest.java in jdk tier testing [v2]
In-Reply-To: <fpTAFmrfOFFZJvyBXCwXwA_Pt5Dfff4ki1b_7YvWbNM=.38145981-689b-4482-af97-cfc960b4b988@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
 <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
 <fpTAFmrfOFFZJvyBXCwXwA_Pt5Dfff4ki1b_7YvWbNM=.38145981-689b-4482-af97-cfc960b4b988@github.com>
Message-ID: <7Q-0Ckz7dbEo4nZiLBMmc6FtDLVqtAFgsULe8qoTf6w=.f54742bd-50d9-4d13-8177-515fe93f4c8d@github.com>

On Wed, 18 Jan 2023 02:19:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm a bit confused. The JBS issue lists two things to do to improve verification, but all this PR seems to do is move the test - in which case the JBS issue should be updated.
> 

We will only address item [2] in the bug description in JDK 21.
I've updated both the bug and PR titles to reflect what is being done.

> This PR also changes the verification logic to be available in product builds - presumably because JDK testing uses product builds not debug ones - but this is not mentioned. Can I assume this change in itself has no impact unless verification is explicitly requested?

Yes, jdk-tier1 testing uses product builds.

-------------

PR: https://git.openjdk.org/jdk/pull/11999

From smarks at openjdk.org  Wed Jan 18 18:17:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Jan 2023 18:17:16 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v4]
In-Reply-To: <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
Message-ID: <U-ChBgL3w0vUsUQB5gcfFIqEFWPTCfjlH-tI0Jic1DM=.14451c86-f2a6-4ede-a459-a19bff85d158@github.com>

On Sun, 15 Jan 2023 07:52:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Copyright year and @since tag updated
>  - Fixes according to review
>    
>    1. Reduce duplication in tests
>    2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>    3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>  - Remove Random -> ThreadLocalRandom change
>  - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

Marked as reviewed by smarks (Reviewer).

Thanks for updates. I've tweaked the CSR a bit and I've marked it reviewed; please go ahead and move it to Finalized.

(On rebase vs. merge, merge is definitely preferable. Merges preserve PR history more faithfully. Merge commits as well as intermediate commits all get squashed when the PR is integrated, so the result is a single commit in the mainline repo. Rebasing isn't a big deal with a small change like this, but rebasing would probably confuse things if this PR were more complicated or if it had a lot of comments on different versions.)

Marking this Approved so it can be integrated after the CSR completes.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From jlu at openjdk.org  Wed Jan 18 18:35:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 18:35:34 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator [v2]
In-Reply-To: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
Message-ID: <ACgrfR_MA-fYbrPvNTnE5jQMCjQGGIdwtHmCx9q9hV4=.c75404d1-4882-4555-96a4-3b041b81643c@github.com>

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> 
> Additionally, removed a floating colon in the code example

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Replace conversion cast w/ pattern matching instaceOf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12055/files
  - new: https://git.openjdk.org/jdk/pull/12055/files/be291cbc..20c18209

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12055&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12055&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12055.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12055/head:pull/12055

PR: https://git.openjdk.org/jdk/pull/12055

From alanb at openjdk.org  Wed Jan 18 18:42:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jan 2023 18:42:15 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <8PUJ0Q50q_biw8S6-8-em8pmp9SNt9sqpt_vZx7mQ4c=.8f788eeb-7f2b-4bc9-a4ff-abc2aec4b37b@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

Using countPositives, and vectorizedHashCode(T_BOOLEAN) for unsigned bytes, make sense here. I don't have time to study the micro right now.

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From smarks at openjdk.org  Wed Jan 18 18:50:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Jan 2023 18:50:16 GMT
Subject: RFR: JDK-8300133: Use generalized see and link tags in core libs
 [v2]
In-Reply-To: <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
 <UaBeX5RWQwJrv1XbJifhCHhwaBjdm_dj8PUfvCeSeE0=.671a345f-d1d7-4656-b944-fab90cab5b84@github.com>
Message-ID: <EbBI_PyKevovi8qoAwSXAkUEvtSxG2pkGaST26W8IZU=.d2c46d50-ce7a-42de-b2b5-fd9ff986830f@github.com>

On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo found in code review.

Changes in collections look good. I think there are a bunch of other places where this could be used, but fixing up optional-restrictions is a good start.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12000

From darcy at openjdk.org  Wed Jan 18 18:57:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Jan 2023 18:57:23 GMT
Subject: Integrated: JDK-8300133: Use generalized see and link tags in core
 libs
In-Reply-To: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
References: <PxuKaVNs1sUw-9f9v1_QsWnjBriZbWOyqa2sjFoXZLE=.11aef1c3-15d4-4637-b7e2-6f7790d22568@github.com>
Message-ID: <neLsXfKFzhxMMpVw2LwhHIq5Wx-BUZb0d0Dgtuh83MY=.92353314-ac4e-453a-875c-dd201b3df505@github.com>

On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With generalized see and link tags that can refer to anchors (JDK-8200337), the see and link tags in core libraries should be updated to use this feature when possible. This PR covers such updates for java.base.

This pull request has now been integrated.

Changeset: 7bf0d146
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70
Stats:     107 lines in 10 files changed: 0 ins; 19 del; 88 mod

8300133: Use generalized see and link tags in core libs

Reviewed-by: jjg, mchung, naoto, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/12000

From jlu at openjdk.org  Wed Jan 18 19:02:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 19:02:36 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator [v3]
In-Reply-To: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
Message-ID: <sAY0ZDybSXBhaAqZnQkC8JO5Khqx8QnI4nanA7MDxL0=.09d0ae02-11b1-4fed-a0f1-5b5a020b79e4@github.com>

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> 
> Additionally, removed a floating colon in the code example

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add unicode vertical ellipsis

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12055/files
  - new: https://git.openjdk.org/jdk/pull/12055/files/20c18209..d559be78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12055&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12055&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12055.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12055/head:pull/12055

PR: https://git.openjdk.org/jdk/pull/12055

From jlu at openjdk.org  Wed Jan 18 19:02:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 19:02:38 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator [v3]
In-Reply-To: <D_OTIIsGuSNYGBqBqoMeYeXom_2Rp-2U8m39Acam0c8=.f435cde7-e684-46a4-b211-7bb2278e0c21@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
 <D_OTIIsGuSNYGBqBqoMeYeXom_2Rp-2U8m39Acam0c8=.f435cde7-e684-46a4-b211-7bb2278e0c21@github.com>
Message-ID: <XK_9gi_gjB6KSLvS2rIA2qw9_VCjSxxvUV4oJ7OgDcU=.261bb590-bdc6-4e88-8a98-23f61c69d667@github.com>

On Tue, 17 Jan 2023 23:58:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add unicode vertical ellipsis
>
> src/java.base/share/classes/java/text/CollationElementIterator.java line 82:
> 
>> 80:  * String testString = "This is a test";
>> 81:  * Collator col = Collator.getInstance();
>> 82:  * if (col instanceof RuleBasedCollator) {
> 
> I'd use the pattern matching `instanceof` here

Replaced the casting conversion with the pattern matching as you suggested, thank you

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From jlu at openjdk.org  Wed Jan 18 19:02:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 19:02:39 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator [v3]
In-Reply-To: <dyok5i_MI0NkVImu5NsZuStJ6EaLJdtwTqXpOtgxiQI=.5c3ee77b-8b2a-42f6-beef-d1b08db74389@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
 <RUdPSJEyMKmbtfs92E58JFlt_v5eL6DY9c456P1h1I0=.b457f53f-d2d4-4a45-9994-338c1a951d58@github.com>
 <dyok5i_MI0NkVImu5NsZuStJ6EaLJdtwTqXpOtgxiQI=.5c3ee77b-8b2a-42f6-beef-d1b08db74389@github.com>
Message-ID: <JR029dENinszKX7hha3sKMwGOx4RRfUZVtyWwePz5yU=.186ba699-e71e-43e3-b6f3-616b44c649b4@github.com>

On Tue, 17 Jan 2023 23:55:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CollationElementIterator.java line 87:
>> 
>>> 85:  *      CollationElementIterator collationElementIterator = ruleBasedCollator.getCollationElementIterator(testString);
>>> 86:  *      int primaryOrder = CollationElementIterator.primaryOrder(collationElementIterator.next());
>>> 87:  *          :
>> 
>> I believe this is a typo, and have removed it
>
> My guess is that this was meant as a vertical ellipsis, so instead of removing it, you can replace it with `?`.

Makes sense, replaced it with `\u22ee` as you suggested and it displays `?` properly when the docs are compiled.

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From naoto at openjdk.org  Wed Jan 18 19:14:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jan 2023 19:14:18 GMT
Subject: RFR: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator [v3]
In-Reply-To: <sAY0ZDybSXBhaAqZnQkC8JO5Khqx8QnI4nanA7MDxL0=.09d0ae02-11b1-4fed-a0f1-5b5a020b79e4@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
 <sAY0ZDybSXBhaAqZnQkC8JO5Khqx8QnI4nanA7MDxL0=.09d0ae02-11b1-4fed-a0f1-5b5a020b79e4@github.com>
Message-ID: <RnIcPUL7KxQCcQHQo6F863UXcRn61l_YFskt6OtKlKE=.0db89708-990a-45c3-8e01-143a16af775c@github.com>

On Wed, 18 Jan 2023 19:02:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> 
>> Additionally, removed a floating colon in the code example
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unicode vertical ellipsis

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From jlu at openjdk.org  Wed Jan 18 20:02:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 20:02:39 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
Message-ID: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Additionally, the code examples have been slightly tweaked to increase readability.

-------------

Commit messages:
 - Minor tweak to second code block
 - Swap to snippet, (c) year, update first code block

Changes: https://git.openjdk.org/jdk/pull/12080/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12080&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300586
  Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12080.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12080/head:pull/12080

PR: https://git.openjdk.org/jdk/pull/12080

From iris at openjdk.org  Wed Jan 18 20:21:59 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Jan 2023 20:21:59 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
Message-ID: <kz79kTyt9-qUKKf9bCi0lSW-Gbsxoz-XbqTAuyBkOpg=.d6410e2d-ba9a-4ead-b4bf-1c4e1b77a6e4@github.com>

On Wed, 18 Jan 2023 19:36:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, the code examples have been slightly tweaked to increase readability.

Marked as reviewed by iris (Reviewer).

src/java.base/share/classes/java/text/Collator.java line 83:

> 81:  *     System.out.println("abc is greater than or equal to ABC");
> 82:  * }
> 83:  * }

I don't think you need a second '}' here.

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From jlu at openjdk.org  Wed Jan 18 20:47:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 20:47:48 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <kz79kTyt9-qUKKf9bCi0lSW-Gbsxoz-XbqTAuyBkOpg=.d6410e2d-ba9a-4ead-b4bf-1c4e1b77a6e4@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
 <kz79kTyt9-qUKKf9bCi0lSW-Gbsxoz-XbqTAuyBkOpg=.d6410e2d-ba9a-4ead-b4bf-1c4e1b77a6e4@github.com>
Message-ID: <yMF25MBtgjceWdioAKrPl8mXt1ycDmXD3rBEe1OfMs0=.1a3a2425-f710-4c57-8a7b-c44323385b9c@github.com>

On Wed, 18 Jan 2023 20:19:03 GMT, Iris Clark <iris at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> Additionally, the code examples have been slightly tweaked to increase readability.
>
> src/java.base/share/classes/java/text/Collator.java line 83:
> 
>> 81:  *     System.out.println("abc is greater than or equal to ABC");
>> 82:  * }
>> 83:  * }
> 
> I don't think you need a second '}' here.

The first `}` is for closing the else statement and the second `}` is for closing the `{snippet`

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From iris at openjdk.org  Wed Jan 18 21:09:29 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Jan 2023 21:09:29 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <yMF25MBtgjceWdioAKrPl8mXt1ycDmXD3rBEe1OfMs0=.1a3a2425-f710-4c57-8a7b-c44323385b9c@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
 <kz79kTyt9-qUKKf9bCi0lSW-Gbsxoz-XbqTAuyBkOpg=.d6410e2d-ba9a-4ead-b4bf-1c4e1b77a6e4@github.com>
 <yMF25MBtgjceWdioAKrPl8mXt1ycDmXD3rBEe1OfMs0=.1a3a2425-f710-4c57-8a7b-c44323385b9c@github.com>
Message-ID: <t2ADlh6QK8a7VV34A99Nl5qL0LKFSj1cUQRVW4GCtLo=.88585331-a591-44f9-ab19-45d083b9d4bb@github.com>

On Wed, 18 Jan 2023 20:43:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/Collator.java line 83:
>> 
>>> 81:  *     System.out.println("abc is greater than or equal to ABC");
>>> 82:  * }
>>> 83:  * }
>> 
>> I don't think you need a second '}' here.
>
> The first `}` is for closing the else statement and the second `}` is for closing the `{snippet`

I see that now!  I didn't look up far enough.  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From jlu at openjdk.org  Wed Jan 18 21:13:27 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 21:13:27 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <t2ADlh6QK8a7VV34A99Nl5qL0LKFSj1cUQRVW4GCtLo=.88585331-a591-44f9-ab19-45d083b9d4bb@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
 <kz79kTyt9-qUKKf9bCi0lSW-Gbsxoz-XbqTAuyBkOpg=.d6410e2d-ba9a-4ead-b4bf-1c4e1b77a6e4@github.com>
 <yMF25MBtgjceWdioAKrPl8mXt1ycDmXD3rBEe1OfMs0=.1a3a2425-f710-4c57-8a7b-c44323385b9c@github.com>
 <t2ADlh6QK8a7VV34A99Nl5qL0LKFSj1cUQRVW4GCtLo=.88585331-a591-44f9-ab19-45d083b9d4bb@github.com>
Message-ID: <wrm4xoNn2Hu-pfdNo1bCyK_DnYrqnwo9Y_dxtOslPD0=.7a6fe12c-4d07-46a5-9bdb-9c5b6b67958b@github.com>

On Wed, 18 Jan 2023 21:07:01 GMT, Iris Clark <iris at openjdk.org> wrote:

>> The first `}` is for closing the else statement and the second `}` is for closing the `{snippet`
>
> I see that now!  I didn't look up far enough.  Thanks!

No worries, thank you for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From lancea at openjdk.org  Wed Jan 18 21:24:27 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Jan 2023 21:24:27 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
Message-ID: <ODoEEngF7A621aL5s6H7lEMWIQzV6z6wxGmM8kolI0c=.3bcad538-2265-45fa-a803-e047f715d4bb@github.com>

On Wed, 18 Jan 2023 19:36:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, the code examples have been slightly tweaked to increase readability.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From darcy at openjdk.org  Wed Jan 18 21:35:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Jan 2023 21:35:24 GMT
Subject: RFR: JDK-8300594: Use generalized see and link tags in
 UnicastRemoteObject
Message-ID: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>

Use improved anchor syntax in UnicastRemoteObject.

-------------

Commit messages:
 - JDK-8300594: Use generalized see and link tags in UnicastRemoteObject

Changes: https://git.openjdk.org/jdk/pull/12083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300594
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12083.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12083/head:pull/12083

PR: https://git.openjdk.org/jdk/pull/12083

From martin at openjdk.org  Wed Jan 18 21:53:30 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 18 Jan 2023 21:53:30 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <-l8ZtfbA6ZJcdx-QW7zOUFZK500B0oRQaPA7Ch2OQSs=.f0a7364d-3f0e-449d-9ac5-f9e530a666b6@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

Like other reviewers, changing the performance tradeoffs in BitSet make me uncomfortable. 

30 years of code has adapted to the current performance tradeoffs.  Those users who really need O(1) cardinality() can fairly easily implement it in client code (and probably have).

The spirit of BitSet is space efficiency, and adding another field negates that.

cardinality() is O(N) but in practice should be very efficient due to linear traversal and (presumably) the use of hardware bitcount instructions for each word (fix that if not true).

There may be a case for a BitSet rewrite (e.g. to support large sparse bitsets) once we have compact value types.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From rriggs at openjdk.org  Wed Jan 18 22:03:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jan 2023 22:03:28 GMT
Subject: RFR: JDK-8300594: Use generalized see and link tags in
 UnicastRemoteObject
In-Reply-To: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
References: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
Message-ID: <unughEB-VJGr6XAivd3wTr2mHIrlfFpAYePeLHUFBG4=.0b933486-205f-46ff-bc34-23cfec5b9ad0@github.com>

On Wed, 18 Jan 2023 21:27:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use improved anchor syntax in UnicastRemoteObject.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12083

From jwilhelm at openjdk.org  Wed Jan 18 22:07:58 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 18 Jan 2023 22:07:58 GMT
Subject: RFR: Merge jdk20
Message-ID: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8300275: SegmentScope.isAccessibleBy returning incorrect values
 - 8300195: Fall-through issue occurs when using record pattern in switch statements
 - 8295723: security/infra/wycheproof/RunWycheproof.java fails with Assertion Error
 - 8295687: Better BMP bounds
 - 8293742: Better Banking of Sounds
 - 8293554: Enhanced DH Key Exchanges
 - 8287411: Enhance DTLS Performance
 - 8293717: Objective view of ObjectView
 - 8293734: Improve BMP image handling
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8b70c432...77fb81ec

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12085&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12085&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12085/files
  Stats: 564 lines in 27 files changed: 332 ins; 117 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/12085.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12085/head:pull/12085

PR: https://git.openjdk.org/jdk/pull/12085

From tvaleev at openjdk.org  Wed Jan 18 22:09:30 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 18 Jan 2023 22:09:30 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v4]
In-Reply-To: <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
Message-ID: <uUWhRK9Y8Hx-pwUY1P2tdLWnJsBcf59CzBtk5WKhwak=.8602f56e-534d-41b8-ad91-e40698b59f16@github.com>

On Sun, 15 Jan 2023 07:52:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Copyright year and @since tag updated
>  - Fixes according to review
>    
>    1. Reduce duplication in tests
>    2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>    3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>  - Remove Random -> ThreadLocalRandom change
>  - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

Hm... is something still missing?

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From smarks at openjdk.org  Wed Jan 18 22:34:30 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Jan 2023 22:34:30 GMT
Subject: RFR: JDK-8300594: Use generalized see and link tags in
 UnicastRemoteObject
In-Reply-To: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
References: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
Message-ID: <AHoXiO63V7Q3ajJ8gB461DzT7T912GXVy9_GxzLRrUI=.49540881-17d4-4066-a04d-7881e4a151b6@github.com>

On Wed, 18 Jan 2023 21:27:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use improved anchor syntax in UnicastRemoteObject.

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12083

From darcy at openjdk.org  Wed Jan 18 22:47:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Jan 2023 22:47:32 GMT
Subject: Integrated: JDK-8300594: Use generalized see and link tags in
 UnicastRemoteObject
In-Reply-To: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
References: <xE0A1tajx-riITaXzhNgoB3cXH2hLBsiCAF-5-N-Wjc=.368aa774-e4c4-49b8-a844-56d24313233b@github.com>
Message-ID: <ZD5NVI-9olEudx84FBlAnEsDnITFdm1MVkMcFt2NC1M=.cfc7caa2-cd4f-4112-aed2-5229509c9c0f@github.com>

On Wed, 18 Jan 2023 21:27:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use improved anchor syntax in UnicastRemoteObject.

This pull request has now been integrated.

Changeset: 601e0ae7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/601e0ae7da472acb68b53f766b30a688e6bacbcf
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8300594: Use generalized see and link tags in UnicastRemoteObject

Reviewed-by: rriggs, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/12083

From smarks at openjdk.org  Wed Jan 18 22:58:27 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Jan 2023 22:58:27 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v4]
In-Reply-To: <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
Message-ID: <2tcflX_1vdEaW5NZzG-edZd-D2dTtJ4k2SYe1otwwZk=.048b699e-1c89-4719-bccd-9a5be78451cf@github.com>

On Sun, 15 Jan 2023 07:52:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Copyright year and @since tag updated
>  - Fixes according to review
>    
>    1. Reduce duplication in tests
>    2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>    3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>  - Remove Random -> ThreadLocalRandom change
>  - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

The CSR still needs to be Approved.

(Yes, unfortunately, Finalized is not a terminal state. It means the _writing of the proposal_ has been finalized and is ready to be evaluated for approval.)

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From naoto at openjdk.org  Wed Jan 18 23:10:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jan 2023 23:10:28 GMT
Subject: RFR: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
Message-ID: <SANBdSbeX9Dqf63U8vU-HjifipYbX92VyS2RXD15Gqc=.34642bbb-0369-4772-937d-ab4860d40a3c@github.com>

On Wed, 18 Jan 2023 19:36:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, the code examples have been slightly tweaked to increase readability.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From jlu at openjdk.org  Wed Jan 18 23:13:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 23:13:35 GMT
Subject: Integrated: 8300307: Refactor code examples to use @snippet in
 java.text.DateFormat
In-Reply-To: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
References: <P6komW4RpyPmEJAcPV_v9NwFJCaUqRE0Mdmg9fDfRbY=.57413385-dac2-42ac-9365-c6356067c546@github.com>
Message-ID: <_m4XMsnel8gi7FfVjoyduNo6-ATFHdwi7tsoFMLjdB8=.1eb27257-3f39-4fbe-bfb4-ea9c56a26cf3@github.com>

On Tue, 17 Jan 2023 22:35:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements JEP 413: Code Snippets in Java API Documentation for [java.text.DateFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DateFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, missing semi colons were added in the code examples

This pull request has now been integrated.

Changeset: dfe94b89
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfe94b89f82a6a43e2f563bcf93cf5a13930c44e
Stats:     21 lines in 1 file changed: 0 ins; 0 del; 21 mod

8300307: Refactor code examples to use @snippet in java.text.DateFormat

Reviewed-by: lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12053

From jlu at openjdk.org  Wed Jan 18 23:14:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jan 2023 23:14:34 GMT
Subject: Integrated: 8300308: java.text.MessageFormat has incorrect doc comment
In-Reply-To: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
References: <fxdoZ6pIcNeBAs_KeV2wIjicc2gjaPgvKKEnzacIASg=.6f3dfd2f-1725-4e89-aba2-601d0ddc0f97@github.com>
Message-ID: <3Hi4E4IWRxOvIH5yNX4HdCpBJBZAetuEPtUTD1dIVmM=.57cc140e-db79-4db3-a8a5-d5048b3d42ac@github.com>

On Tue, 17 Jan 2023 22:44:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A code example for text.MessageFormat under the **Usage Information** section has a comment with the wrong variable name.
> 
> 
> * Object[] objs = mf.parse(forParsing, new ParsePosition(0));
> * // result now equals {new String("z")}
> 
> 
> The name of the intended variable should be `objs`, not `result`

This pull request has now been integrated.

Changeset: 31a2e02a
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31a2e02afcf4853f71925ec75a9a6427b08b4cbd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8300308: java.text.MessageFormat has incorrect doc comment

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12054

From jwilhelm at openjdk.org  Wed Jan 18 23:32:35 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 18 Jan 2023 23:32:35 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>
References: <aoXMpcOdw9mIXTxDzeZ_BL-vPIIxG7Cno_7ULOPDUcA=.587db5a6-79dc-4420-b76f-161ec629277d@github.com>
Message-ID: <WxP2Ie203v7YoiY0G-tY2xbu4Xnajzc2aRYwLBvaUtY=.ef8aa6e1-64b4-4e60-8898-4aaf24188522@github.com>

On Wed, 18 Jan 2023 21:56:13 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: fc9f8baf
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc9f8baf56a8888362ad60d0e6dc8953690b80d3
Stats:     564 lines in 27 files changed: 332 ins; 117 del; 115 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12085

From dholmes at openjdk.org  Thu Jan 19 00:17:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jan 2023 00:17:29 GMT
Subject: RFR: 8292635: Run ArchivedEnumTest.java in jdk tier testing [v2]
In-Reply-To: <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
 <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
Message-ID: <NQKkEYtH9y-DcEwQ3-JOwtJVe-EAWOAxyA148eR48hw=.b17d32e6-6035-4bd1-b864-3e2e0d0d5e43@github.com>

On Tue, 17 Jan 2023 17:40:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Moving the `ArchivedEnumTest.java` from `runtime/cds/appcds/cacheObject` to `jdk/internal/misc/CDS` so that the test will be run in jdk-tier1. This is to avoid inadvertently breakage of the test like in JDK-8292499.
>> 
>> Since jdk tier testing runs with product builds, the CDSHeapVerifier::verify() needs to be enabled with product builds. 
>> Currently, the verify() function only checks built-in classes. 
>> 
>> Testing: jdk-tier1, tier3, tier4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable CDSHeapVerifier::verify() for non-debug build

Thanks for the updates to JBS and the PR regarding the change in verification behaviour.

Looks good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11999

From ccheung at openjdk.org  Thu Jan 19 00:23:42 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 19 Jan 2023 00:23:42 GMT
Subject: RFR: 8292635: Run ArchivedEnumTest.java in jdk tier testing [v2]
In-Reply-To: <KQ88OGCdjM4Mr-1XtLBtPps3ypxVexT1SxJH_oeqx2M=.3b935652-72db-4ba6-b497-9024eb70c28e@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
 <S2sUaWS4luHXLPiEzquKiHGGYx16n9NUlFdvgpRMLLs=.896efbf4-3f09-4f81-9970-22ea79fdce6c@github.com>
 <KQ88OGCdjM4Mr-1XtLBtPps3ypxVexT1SxJH_oeqx2M=.3b935652-72db-4ba6-b497-9024eb70c28e@github.com>
Message-ID: <erApvdXGGonllenvzpe-jqboUcQMwDZxGF1nqpj7TZ4=.45e6edf2-a9c6-46e2-a31f-6e3c41196e67@github.com>

On Tue, 17 Jan 2023 18:58:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enable CDSHeapVerifier::verify() for non-debug build
>
> LGTM

Thanks @iklam and @dholmes-ora for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/11999

From ccheung at openjdk.org  Thu Jan 19 00:23:42 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 19 Jan 2023 00:23:42 GMT
Subject: Integrated: 8292635: Run ArchivedEnumTest.java in jdk tier testing
In-Reply-To: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
References: <GEey2qTGQ37RInC02_KLfMZkLUS9eJkALKmgmFo5-C8=.11c677d3-76cd-4819-bb6b-ca6dcd15ae75@github.com>
Message-ID: <egEJITRih-zYVeyoUgZHJ67YWYYOnpdmhDq0lSGe8p8=.3e442440-e5c6-405d-b90a-c88c09cdc511@github.com>

On Fri, 13 Jan 2023 21:07:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Moving the `ArchivedEnumTest.java` from `runtime/cds/appcds/cacheObject` to `jdk/internal/misc/CDS` so that the test will be run in jdk-tier1. This is to avoid inadvertently breakage of the test like in JDK-8292499.
> 
> Since jdk tier testing runs with product builds, the CDSHeapVerifier::verify() needs to be enabled with product builds. 
> Currently, the verify() function only checks built-in classes. 
> 
> Testing: jdk-tier1, tier3, tier4.

This pull request has now been integrated.

Changeset: 910dffea
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/910dffea867ea57b6338daf9ed7f6ea81536a934
Stats:     6 lines in 5 files changed: 1 ins; 2 del; 3 mod

8292635: Run ArchivedEnumTest.java in jdk tier testing

Reviewed-by: iklam, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/11999

From yadongwang at openjdk.org  Thu Jan 19 01:22:37 2023
From: yadongwang at openjdk.org (Yadong Wang)
Date: Thu, 19 Jan 2023 01:22:37 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v8]
In-Reply-To: <mLpfUcoaw_6CsS8BZD0M4sU67gPGMQ5SgonOX1UpWvg=.71ec8b24-e124-4afa-8f26-59004173f307@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <mLpfUcoaw_6CsS8BZD0M4sU67gPGMQ5SgonOX1UpWvg=.71ec8b24-e124-4afa-8f26-59004173f307@github.com>
Message-ID: <sZCipWwbcFi6Q8xetxonJqjjbPC7IOpXcTDqOIuMRQg=.2e4c7bae-d2b5-4e1c-9951-46a6190d82ec@github.com>

On Wed, 18 Jan 2023 11:11:30 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Add experimental Foreign Function & Memory API support for RISC-V.
>> 
>> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
>> 
>> Testing:
>> 
>> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
>> - [x] jdk_foreign with release/fastdebug build on linux-x64
>> - [x] jdk_foreign with release/fastdebug build on linux-aarch64
>
> Feilong Jiang 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:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
>  - more code style adjustment
>  - fix comment & code adjustment
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
>  - fix callArranger
>  - fix callArranger
>  - fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv
>  - code adjustment and remove unnecessary static
>  - sync with JDK-8296477
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/0245ec81...feac5fa8

lgtm

-------------

Marked as reviewed by yadongwang (Author).

PR: https://git.openjdk.org/jdk/pull/11004

From fjiang at openjdk.org  Thu Jan 19 01:27:26 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 19 Jan 2023 01:27:26 GMT
Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory
 API (Preview) [v5]
In-Reply-To: <vV6yIgG-Q4EKobuFlIAYZ8mndQ9VsKHTPRoqA0Mlxtw=.cdf8dcdf-f081-45c0-aecc-c9475a756595@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
 <XT8kAZUbTWBFe4XK2ylbiVYwPoKYHEAkzzVInlKQOl8=.8c37d279-864f-4d1a-8e08-6c2271cae960@github.com>
 <vV6yIgG-Q4EKobuFlIAYZ8mndQ9VsKHTPRoqA0Mlxtw=.cdf8dcdf-f081-45c0-aecc-c9475a756595@github.com>
Message-ID: <69LvUbE51AIQC5P9WBhyYS9Cy5RkPwx8Po_N25jsNO0=.c151cb06-d444-4eae-b51b-e4b4226d59f7@github.com>

On Sat, 14 Jan 2023 10:20:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix callArranger
>
> Marked as reviewed by jvernee (Reviewer).

@JornVernee @RealFYang @shipilev @yadongw -- Thank you all for the review! I'm going to integrate it then.

-------------

PR: https://git.openjdk.org/jdk/pull/11004

From smarks at openjdk.org  Thu Jan 19 01:33:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 19 Jan 2023 01:33:35 GMT
Subject: RFR: 8038146: Clarify Map.Entry's connection to the underlying map
 [v2]
In-Reply-To: <lPhKYWfmQfSG27tZitJPu1DYQMtMQQ4fhqRQyUGDwak=.fbe883c0-859a-44a9-b41a-c2ac140c493b@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
 <lPhKYWfmQfSG27tZitJPu1DYQMtMQQ4fhqRQyUGDwak=.fbe883c0-859a-44a9-b41a-c2ac140c493b@github.com>
Message-ID: <Z0G4fG-kdZZeZvnPl7nBCUCx4emu8uM8mrievP_2f4E=.91be8f5a-b8bf-4539-8281-07c19a82b5ef@github.com>

On Sat, 14 Jan 2023 03:56:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates from Alan.

Please review CSR [JDK-8300622](https://bugs.openjdk.org/browse/JDK-8300622).

-------------

PR: https://git.openjdk.org/jdk/pull/11956

From fjiang at openjdk.org  Thu Jan 19 01:36:36 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 19 Jan 2023 01:36:36 GMT
Subject: Integrated: 8293841: RISC-V: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
References: <PLxD7L7wDieoSCXrl9lobH-0gEBkvfwzon5YMX6LcU0=.7c0a7e99-1345-47c8-b1d5-981ebe2534b3@github.com>
Message-ID: <0-s0h5-Y5OYozZSQUxCi86Be9JI2uI2Mu7IaQuBOOsE=.62dd2b76-0de8-4590-a759-03f940b9f790@github.com>

On Sat, 5 Nov 2022 03:48:01 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> Add experimental Foreign Function & Memory API support for RISC-V.
> 
> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841)
> 
> Testing:
> 
> - [x] jdk_foreign with release/fastdebug build on linux-riscv64
> - [x] jdk_foreign with release/fastdebug build on linux-x64
> - [x] jdk_foreign with release/fastdebug build on linux-aarch64

This pull request has now been integrated.

Changeset: 24cdcd4c
Author:    Feilong Jiang <fjiang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24cdcd4c70dd538fd6c6c9f05da480ea65463209
Stats:     2846 lines in 64 files changed: 2721 ins; 2 del; 123 mod

8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview)

Co-authored-by: Weikai He <weikai at isrc.iscas.ac.cn>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Reviewed-by: jvernee, fyang, shade, yadongwang

-------------

PR: https://git.openjdk.org/jdk/pull/11004

From qamai at openjdk.org  Thu Jan 19 03:40:28 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 19 Jan 2023 03:40:28 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <Vzn2_9yKiEsEjgTbnkR0zuhmszw9Pl8cHakHFzWxht0=.d7f252ee-eb52-4260-8a71-7334b2af480d@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 219:

> 217:     @ForceInline
> 218:     public VectorMask<E> indexInRange(int offset, int limit) {
> 219:         if (offset < 0) {

These fast-paths penalise every usage of `VectorMask::indexInRange`, especially the common use case of tail processing an array. So I don't think it is needed, the user can implement it themselves if their use cases find it beneficial. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From xgong at openjdk.org  Thu Jan 19 03:48:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 19 Jan 2023 03:48:27 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <Vzn2_9yKiEsEjgTbnkR0zuhmszw9Pl8cHakHFzWxht0=.d7f252ee-eb52-4260-8a71-7334b2af480d@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <Vzn2_9yKiEsEjgTbnkR0zuhmszw9Pl8cHakHFzWxht0=.d7f252ee-eb52-4260-8a71-7334b2af480d@github.com>
Message-ID: <6nwhsKi38nU39cIa68m142xveEfBTgh8Q-nbaLaVaps=.32403276-e3e5-4296-9d03-224ba28c0346@github.com>

On Thu, 19 Jan 2023 03:37:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 219:
> 
>> 217:     @ForceInline
>> 218:     public VectorMask<E> indexInRange(int offset, int limit) {
>> 219:         if (offset < 0) {
> 
> These fast-paths penalise every usage of `VectorMask::indexInRange`, especially the common use case of tail processing an array. So I don't think it is needed, the user can implement it themselves if their use cases find it beneficial. Thanks.

This "offset < 0" path can be optimized out by compiler if the "offset >= 0" in the common cases (i.e. normal loop with no tail loop).

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From qamai at openjdk.org  Thu Jan 19 03:54:26 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 19 Jan 2023 03:54:26 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <6nwhsKi38nU39cIa68m142xveEfBTgh8Q-nbaLaVaps=.32403276-e3e5-4296-9d03-224ba28c0346@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <Vzn2_9yKiEsEjgTbnkR0zuhmszw9Pl8cHakHFzWxht0=.d7f252ee-eb52-4260-8a71-7334b2af480d@github.com>
 <6nwhsKi38nU39cIa68m142xveEfBTgh8Q-nbaLaVaps=.32403276-e3e5-4296-9d03-224ba28c0346@github.com>
Message-ID: <kli33jthRRCWKoFpw-D8NPGwF7JuMsk1ZS2lbaVk9wc=.f5d4f8a6-dd78-4035-ace0-352baf7d34e3@github.com>

On Thu, 19 Jan 2023 03:45:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 219:
>> 
>>> 217:     @ForceInline
>>> 218:     public VectorMask<E> indexInRange(int offset, int limit) {
>>> 219:         if (offset < 0) {
>> 
>> These fast-paths penalise every usage of `VectorMask::indexInRange`, especially the common use case of tail processing an array. So I don't think it is needed, the user can implement it themselves if their use cases find it beneficial. Thanks.
>
> This "offset < 0" path can be optimized out by compiler if the "offset >= 0" in the common cases (i.e. normal loop with no tail loop).

Yes but I don't think it is common enough to deserve special treatment. A fast path should be common for this branch otherwise we are regressing the common path for the corner cases.

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From xgong at openjdk.org  Thu Jan 19 06:06:31 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 19 Jan 2023 06:06:31 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <kli33jthRRCWKoFpw-D8NPGwF7JuMsk1ZS2lbaVk9wc=.f5d4f8a6-dd78-4035-ace0-352baf7d34e3@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <Vzn2_9yKiEsEjgTbnkR0zuhmszw9Pl8cHakHFzWxht0=.d7f252ee-eb52-4260-8a71-7334b2af480d@github.com>
 <6nwhsKi38nU39cIa68m142xveEfBTgh8Q-nbaLaVaps=.32403276-e3e5-4296-9d03-224ba28c0346@github.com>
 <kli33jthRRCWKoFpw-D8NPGwF7JuMsk1ZS2lbaVk9wc=.f5d4f8a6-dd78-4035-ace0-352baf7d34e3@github.com>
Message-ID: <_zdjkFZ-KdNX8lL7vV_XrHwgqy1bnlx_0aP4qvk40ys=.3119804b-486b-45e9-9e01-cd1937f1dd25@github.com>

On Thu, 19 Jan 2023 03:51:28 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This "offset < 0" path can be optimized out by compiler if the "offset >= 0" in the common cases (i.e. normal loop with no tail loop).
>
> Yes but I don't think it is common enough to deserve special treatment. A fast path should be common for this branch otherwise we are regressing the common path for the corner cases.

The special handling here is necessary for me, because we do not have the instruction supports in compiler intrinsification. Besides, the original API implementation also has the special handle for "offset < 0", which means this API itself accepts the negative offset as the valid argument.  We have to cover it here as well to make the implementation comprehensive.

 Maybe I misunderstood what you mean. Could you please give an alternative solution besides  the current implementation for such corner cases? Thanks in advance!

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From alanb at openjdk.org  Thu Jan 19 07:02:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Jan 2023 07:02:41 GMT
Subject: Integrated: 8208077: File.listRoots performance degradation
In-Reply-To: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
References: <N6rD9jTOCrOyBeIPw_hHiuoKtB2P88ppoSsNZDbBW0M=.98c1878e-dfb6-4b45-8bfa-0b576d5ad425@github.com>
Message-ID: <-idZ6EXk7OGAwNIZLaldYhkCiFQke8wuQRTX_MLVLW8=.ecc7191b-dcca-4647-8c72-4fc84feaebba@github.com>

On Wed, 18 Jan 2023 14:16:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The Windows implementation of File.listRoots was changed in JDK 10 to test the root directory of each "logical drive" to see that it exists. The motive was to filter out drive letters corresponding to removable media where the media is not present. This is problematic for a number of reasons that include performance (esp. for mapped drives), inconsistency with FileSystem::getRootDirectories, and surprising behavior when media is re-inserted. After re-examining this area again, the best thing seems to be just undo this change so that File.listRoots doesn't attempt to do the problematic filtering.

This pull request has now been integrated.

Changeset: 5b0af1a8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b0af1a80bb4d2a81cda7e26a6ad0db43e679519
Stats:     29 lines in 2 files changed: 17 ins; 1 del; 11 mod

8208077: File.listRoots performance degradation

Reviewed-by: lancea, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12072

From redestad at openjdk.org  Thu Jan 19 09:49:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Jan 2023 09:49:12 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <O28fzZHNH9u_7MPG3IuJS27_4FJrKB_PTq6h_eXxgIU=.c9b6675e-9f00-4f57-8068-28ca5fea7583@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the same directory. It's not exactly necessary for this use case to add such a benchmark, but I think there's value in verifying that optimizing `checkedHash` improves `ZipFile` setup and adding the micro might allow us to find further opportunities down the line.

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From redestad at openjdk.org  Thu Jan 19 11:53:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Jan 2023 11:53:12 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
Message-ID: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>

Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.

After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.

-------------

Commit messages:
 - Miscellaneous hashCode improvements in java.base

Changes: https://git.openjdk.org/jdk/pull/12093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300647
  Stats: 44 lines in 3 files changed: 3 ins; 33 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12093/head:pull/12093

PR: https://git.openjdk.org/jdk/pull/12093

From duke at openjdk.org  Thu Jan 19 12:31:43 2023
From: duke at openjdk.org (fabioromano1)
Date: Thu, 19 Jan 2023 12:31:43 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <-l8ZtfbA6ZJcdx-QW7zOUFZK500B0oRQaPA7Ch2OQSs=.f0a7364d-3f0e-449d-9ac5-f9e530a666b6@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
 <-l8ZtfbA6ZJcdx-QW7zOUFZK500B0oRQaPA7Ch2OQSs=.f0a7364d-3f0e-449d-9ac5-f9e530a666b6@github.com>
Message-ID: <FRCn3xp46EAl6csr2GqQjnlfFbFDSAcjcpHox9KNq7U=.688be20e-2663-4b62-8fcf-1fe5e2b4b958@github.com>

On Wed, 18 Jan 2023 21:51:02 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> Like other reviewers, changing the performance tradeoffs in BitSet make me uncomfortable.
> 
> 30 years of code has adapted to the current performance tradeoffs. Those users who really need O(1) cardinality() can fairly easily implement it in client code (and probably have).
> 
> The spirit of BitSet is space efficiency, and adding another field negates that.
> 
> cardinality() is O(N) but in practice should be very efficient due to linear traversal and (presumably) the use of hardware bitcount instructions for each word (fix that if not true).
> 
> There may be a case for a BitSet rewrite (e.g. to support large sparse bitsets) once we have compact value types.

Leaving to the client the responsibility of implementation isn't against the principle of information hiding and encapsulation?

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From jlaskey at openjdk.org  Thu Jan 19 13:27:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 19 Jan 2023 13:27:23 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <2YN9sf8W-Oaq6nMZ8EHcKttrR93UTqlV8GS_r4AN5iM=.d07195e2-d825-4e29-aaf4-fdba82ffacc1@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

Libraries cannot be all things to all users. A library provides a service that would be difficult for a majority of users to implement on their own. Sometimes a library needs specialization for certain use cases. That is why we use subclassing and wrappers to extend existing libraries.

I think you will find that most BitSet users (including the JDK itself) want basic bit operations with a minimal overhead. If there was additional overhead, many would then roll their own versions to avoid that overhead. We have conflicting goals.

BitSet has served all JDK users well since JDK 1.0. I think your concerns are valid, but better cardinality would be best implemented as a subclass (CardinalBitSet?) of BitSet. Once constructed, you could then propose the addition to java.util with a CSR. 

If you want to make a case for `includes(BitSet)` that should be proposed as a separate CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From jdowland at openjdk.org  Thu Jan 19 13:29:48 2023
From: jdowland at openjdk.org (Jonathan Dowland)
Date: Thu, 19 Jan 2023 13:29:48 GMT
Subject: Integrated: 8300119: CgroupMetrics.getTotalMemorySize0() can report
 invalid results on 32 bit systems
In-Reply-To: <FyT__JTrsOsswaQlvPCOk-3mSXK0igHJAl67X9BIhtk=.a276d057-d5b1-435d-8f94-69aea63ba876@github.com>
References: <FyT__JTrsOsswaQlvPCOk-3mSXK0igHJAl67X9BIhtk=.a276d057-d5b1-435d-8f94-69aea63ba876@github.com>
Message-ID: <018boAck_yCHnlWwBwPifsE4Od4q2l0bGoRWMfSF9I8=.31f266d4-2430-4316-9708-23c1ce87228f@github.com>

On Wed, 18 Jan 2023 13:20:06 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

> This is a fix for https://bugs.openjdk.org/browse/JDK-8300119 (CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems). Thanks to @jerboaa Severin Gehwolf for figuring out the solution.
> 
> The problem is demonstrated by test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which fails on 32-bit x86 in HEAD, and passes after applying this patch.
> 
> I tested this on an amd64 system with a cross-compiled JDK. I needed to override the default docker container for the test, to get one with a 32-bit userland. (the precise choice was also dictated by ABI matching my main development machine):
> 
> 
> $JT_HOME/bin/jtreg -v -Djdk.test.docker.retain.image=true -Djdk.test.docker.image.name=i386/debian -Djdk.test.docker.image.version=testing-slim -jdk:$JAVA_HOME test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java

This pull request has now been integrated.

Changeset: dea58efb
Author:    Jonathan Dowland <jdowland at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dea58efb6280bb1d94daf208ac909aa013439397
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems

Reviewed-by: sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/12069

From redestad at openjdk.org  Thu Jan 19 13:46:26 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Jan 2023 13:46:26 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
 [v2]
In-Reply-To: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
Message-ID: <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>

> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
> 
> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12093/files
  - new: https://git.openjdk.org/jdk/pull/12093/files/5f36ebd7..b1507e69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12093&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12093/head:pull/12093

PR: https://git.openjdk.org/jdk/pull/12093

From duke at openjdk.org  Thu Jan 19 14:06:18 2023
From: duke at openjdk.org (fabioromano1)
Date: Thu, 19 Jan 2023 14:06:18 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <2YN9sf8W-Oaq6nMZ8EHcKttrR93UTqlV8GS_r4AN5iM=.d07195e2-d825-4e29-aaf4-fdba82ffacc1@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
 <2YN9sf8W-Oaq6nMZ8EHcKttrR93UTqlV8GS_r4AN5iM=.d07195e2-d825-4e29-aaf4-fdba82ffacc1@github.com>
Message-ID: <r1_9kZzkG9OLuJZ1EOAKtdiRBXFTHIaifCxYO9WqDqI=.3cd43597-3726-43b9-91e7-7ab7af30866f@github.com>

On Thu, 19 Jan 2023 13:24:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Libraries cannot be all things to all users. A library provides a service that would be difficult for a majority of users to implement on their own. Sometimes a library needs specialization for certain use cases. That is why we use subclassing and wrappers to extend existing libraries.
> 
> I think you will find that most BitSet users (including the JDK itself) want basic bit operations with a minimal overhead. If there was additional overhead, many would then roll their own versions to avoid that overhead. We have conflicting goals.
> 
> BitSet has served all JDK users well since JDK 1.0. I think your concerns are valid, but better cardinality would be best implemented as a subclass (CardinalBitSet?) of BitSet. Once constructed, you could then propose the addition to java.util with a CSR.
> 
> If you want to make a case for `includes(BitSet)` that should be proposed as a separate CSR.

Ok, thanks a lot for the feedback. I will make a subclass instead. Have a nice day.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Thu Jan 19 14:15:40 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 19 Jan 2023 14:15:40 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
 [v2]
In-Reply-To: <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
 <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
Message-ID: <SjaOe6Vm1GtA6r8KFqDFGz-v0Ta-5RaEnbJfZB2uB_4=.b1c5dfab-64d3-4f44-9316-380df0f0bf0b@github.com>

On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
>> 
>> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 415:

> 413:     }
> 414: 
> 415:     // Replace with general purpose method someday

@cl4es Nice work addressing this 16+ year old comment! ?

-------------

PR: https://git.openjdk.org/jdk/pull/12093

From duke at openjdk.org  Thu Jan 19 14:16:46 2023
From: duke at openjdk.org (fabioromano1)
Date: Thu, 19 Jan 2023 14:16:46 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <r1_9kZzkG9OLuJZ1EOAKtdiRBXFTHIaifCxYO9WqDqI=.3cd43597-3726-43b9-91e7-7ab7af30866f@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
 <2YN9sf8W-Oaq6nMZ8EHcKttrR93UTqlV8GS_r4AN5iM=.d07195e2-d825-4e29-aaf4-fdba82ffacc1@github.com>
 <r1_9kZzkG9OLuJZ1EOAKtdiRBXFTHIaifCxYO9WqDqI=.3cd43597-3726-43b9-91e7-7ab7af30866f@github.com>
Message-ID: <PB4fLRCQWi7sFWa8bL0mlj1-K09usaD_y5CA0tBgIAo=.6c82e0ad-7f6a-4188-aba1-6cd36a8a39fd@github.com>

On Thu, 19 Jan 2023 14:03:38 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Libraries cannot be all things to all users. A library provides a service that would be difficult for a majority of users to implement on their own. Sometimes a library needs specialization for certain use cases. That is why we use subclassing and wrappers to extend existing libraries.
> 
> I think you will find that most BitSet users (including the JDK itself) want basic bit operations with a minimal overhead. If there was additional overhead, many would then roll their own versions to avoid that overhead. We have conflicting goals.
> 
> BitSet has served all JDK users well since JDK 1.0. I think your concerns are valid, but better cardinality would be best implemented as a subclass (CardinalBitSet?) of BitSet. Once constructed, you could then propose the addition to java.util with a CSR.
> 
> If you want to make a case for `includes(BitSet)` that should be proposed as a separate CSR.

I think it will be better to call it "NaturalsBitSet" to highlight the fact that the class represents a set of non-negative integers, am I wrong?

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Thu Jan 19 14:40:56 2023
From: duke at openjdk.org (duke)
Date: Thu, 19 Jan 2023 14:40:56 GMT
Subject: Withdrawn: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder()
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <zSTRL-6FnecIL2kh_Nnj-A-XprXNC9nOqatuG48UWbk=.92aadf20-9901-46b0-892f-451521a27ec6@github.com>

On Wed, 17 Aug 2022 11:23:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From stsypanov at openjdk.org  Thu Jan 19 15:11:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 19 Jan 2023 15:11:16 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
 [v2]
In-Reply-To: <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
 <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
Message-ID: <n--mZU3I8wsgJUZIlpE7fUvpuOJ39ZOX7QB0y3HjYZk=.a696e43d-e53c-4c8a-8c3f-0d860dc1551b@github.com>

On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
>> 
>> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal

Marked as reviewed by stsypanov (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/12093

From rgiulietti at openjdk.org  Thu Jan 19 15:27:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Jan 2023 15:27:04 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
Message-ID: <xFdQ_2TIdFhPwIe1ABNwR9IrTdC9fiN-lSnY4UZ9cO8=.5926e15c-1361-41f8-8597-7fdeebaf1f8d@github.com>

> - Strengthen a computation that could overflow.
> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12027/files
  - new: https://git.openjdk.org/jdk/pull/12027/files/8ae8f86e..64c2dfc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12027&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12027&range=00-01

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12027.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12027/head:pull/12027

PR: https://git.openjdk.org/jdk/pull/12027

From rriggs at openjdk.org  Thu Jan 19 15:29:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 19 Jan 2023 15:29:04 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
 [v2]
In-Reply-To: <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
 <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
Message-ID: <xgmrvYPitrnZKY0hV3HtNmu0sU5i5b5_AOHbJgHSyns=.cd115921-2d54-40b4-92a6-fc4c48de2663@github.com>

On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
>> 
>> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12093

From rgiulietti at openjdk.org  Thu Jan 19 15:31:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Jan 2023 15:31:17 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <V0HVrdFWi7OwnruwvhKRW3_gIC_-0cfDF_Nkx3lJbHA=.2326113d-053b-4985-83c3-0816b66cdbd6@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
 <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
 <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
 <V0HVrdFWi7OwnruwvhKRW3_gIC_-0cfDF_Nkx3lJbHA=.2326113d-053b-4985-83c3-0816b66cdbd6@github.com>
Message-ID: <tO4IlmugYsFGchsd8hXPDiUoBoqUhbvY1MD_5pKC1Q0=.9c249fcf-bd60-4206-a275-060535e1d73a@github.com>

On Tue, 17 Jan 2023 14:55:18 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Okay, I see your point and to use apiNote consistently would require "converting" some of the existing text to apiNote too.
>> 
>> I'm still mulling over Pattern.compile throwing OOME. An implNote is probably the right category for this, in which case it can start with "In the the JDK Reference Implementation ...".  I assume the static Pattern.matches needs same, and also Pattern.matcher for the lazy compilation case.
>
> There's no hard limit for the number of combining marks in the Unicode specification, even though in practice it never reaches the implementation limit. A high number of combining marks is thus more akin to a a resource exhaustion condition than to anything else, IMO.
> 
> Even today, compilation of a pattern risks throwing an OOME anyway when trying to generate the permutations. Pre-emptively throwing an OOME just anticipates and extrapolates this behavior beyond the `int` limit of array lengths.
> 
> Alternatively, compilation (greedy or lazy) could throw `PatternSyntaxException`, although there is not really something wrong with syntax.
> 
> I'll add `@implNote` to the other methods you mention.

The CSR will be updated once this PR stabilizes.

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From redestad at openjdk.org  Thu Jan 19 16:53:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Jan 2023 16:53:22 GMT
Subject: RFR: 8300647: Miscellaneous hashCode improvements in java.base
 [v2]
In-Reply-To: <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
 <SNrwfrYRctLBfjgisY-ugVVS4JUIzpGcYZVDWH6uyUE=.cf081e73-deed-45d4-b517-48850a0e8ba8@github.com>
Message-ID: <Jn4bBHwvc-DJXxGYz3TcB2LsUuLNdOVeCGvd1C0soro=.eea243f7-3180-4ebb-828d-ab14c86ec420@github.com>

On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
>> 
>> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ZipFileSystem changes since it's additionally built as a library dependency and can't rely on jdk.internal

Thanks for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12093

From redestad at openjdk.org  Thu Jan 19 16:53:24 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Jan 2023 16:53:24 GMT
Subject: Integrated: 8300647: Miscellaneous hashCode improvements in java.base
In-Reply-To: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
References: <bzI9l77v1uNq75LYTF5o4z0mJK_-wVtXn9j18EzDb7E=.ba37e142-66e4-45e2-8ec2-c94e7e6c19d4@github.com>
Message-ID: <rKwYRyhMV_RjfrardfY3C2eA9RY-5kCdEEz0Zp9sjt8=.3093891f-b681-45e5-8c58-a6fa10296fb0@github.com>

On Thu, 19 Jan 2023 11:45:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Went through the jdk and found a few more places where `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods could be replaced with a plain call to `java.util.Arrays` equivalents. This patch addresses that.
> 
> After this, #12068, and #12077 I think we're reaching the limit of sensible direct use of `AS::vectorizedHashCode`. I've found a few places outside of java.base where `vectorizedHashCode` might be applicable, but none that seem important enough to warrant an export of this method outside of java.base.

This pull request has now been integrated.

Changeset: d85243f0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d85243f02b34d03bd7af63a5bcbc73f500f720df
Stats:     37 lines in 2 files changed: 1 ins; 31 del; 5 mod

8300647: Miscellaneous hashCode improvements in java.base

Reviewed-by: stsypanov, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12093

From eirbjo at gmail.com  Thu Jan 19 19:03:32 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 19 Jan 2023 20:03:32 +0100
Subject: ZIP entry copy without recompression
Message-ID: <CA+pBWhtGWR4yyw26Or9XO3LJuHitqgJeoU_rS8Y_HguUMuN29g@mail.gmail.com>

Hi,

A common use case for java.util.zip in build tools involves copying
entries from a ZipFile or ZipInputStream to a ZipOutputStream without
actually modifying the data.

Example use cases include minification (make a JAR with only the
reachable classes) and merging (combine several JAR files into one
uberjar).

Inflating an entry just to immediately deflate it again with no
modifications seems wasteful.

The following draft PR introduces
ZipFileInflaterInputStream.transferTo which copies compressed ZipFile
data directly to ZipOutputStream's raw data stream:

https://github.com/openjdk/jdk/pull/12099

I'm typically seeing a 15 X improvement when copying xalan.jar to a
ZipOutputStream backed by a buffered FileOutputStream, or 22 X when
backed by OutputStream.nullOutputStream().

The PR current stays completely on the happy path and is mostly there
to experiment and to show the potential performance benefits. There is
currently not much focus on validation or correctness. Copying files
to a different path is not supported, neither is copying from a
ZipInputStream.

I initially considered creating new methods for raw copies, but opted
to minimize changes to public APIs, that's why I'm overriding
transferTo.

The PR is not intended for regular review, but as a starting point for
a discussion about the usefulness of the idea and the general solution
space. If we can reach consensus on such a discussion, I'll probably
be happy to work on a more complete PR.

Cheers,
Eirik.

From mchung at openjdk.org  Thu Jan 19 19:23:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Jan 2023 19:23:24 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should get
 the receiver type from VarHandle
Message-ID: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>

`VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.

-------------

Commit messages:
 - 8297757: Re-examine assumption in VarHandles.getStaticFieldFromBaseAndOffset that base is a Class object

Changes: https://git.openjdk.org/jdk/pull/12100/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297757
  Stats: 36 lines in 2 files changed: 3 ins; 2 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/12100.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12100/head:pull/12100

PR: https://git.openjdk.org/jdk/pull/12100

From pminborg at openjdk.org  Thu Jan 19 20:00:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jan 2023 20:00:20 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
Message-ID: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>

This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

-------------

Commit messages:
 - Remove white spaces
 - Remove white space
 - Fix jcheck issues
 - Update copyright years
 - Reformat javadoc
 - Prepare for review
 - Fix typo
 - Rename methods and parameters
 - Recompose classes and methods
 - Rework BigEndianAtZeroBuffer
 - ... and 2 more: https://git.openjdk.org/jdk/compare/4cd166ff...ce1d5765

Changes: https://git.openjdk.org/jdk/pull/12076/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300236
  Stats: 1939 lines in 11 files changed: 1281 ins; 560 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From rriggs at openjdk.org  Thu Jan 19 20:00:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 19 Jan 2023 20:00:24 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <7UEHdLyxjReJ5wY1N3FQtHk7epdm6DKiNIetIjJB9yA=.63a0f644-3051-4ca4-8e1f-35ac3e3c439a@github.com>

On Wed, 18 Jan 2023 16:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Some comments:

src/java.base/share/classes/jdk/internal/util/Bits.java line 43:

> 41:     }
> 42: 
> 43:     public static final class BigEndian {

Are there other names that improve the readability of the uses?
For example `ByteArray.getShort()` and `ByteArray.getDouble`.

There's been a move to drop `get` and `put` prefixes where they are unnecessary.
Get and put prefixes do make them similar to the existing methods, but...

Is it just a readable to say:
   `float degrees = ByteArray.float(buf);`      // for get
    `ByteArray.int(buf, degrees);`                   // for put

Maybe, maybe not....

src/java.base/share/classes/jdk/internal/util/Bits.java line 161:

> 159:     }
> 160: 
> 161:     public static final class BigEndianAtZero {

I'd merge these methods (with zero offset) in with the previous class; the overloads with offsets are sufficient to distinguish them and it would make discovery more natural. (omitting this class).

src/java.base/share/classes/jdk/internal/util/Bits.java line 284:

> 282: 
> 283:     // Alternative with an internal buffer fixed att offset zero.
> 284:     public static final class BigEndianAtZeroBuffer {

I'd keep it simple an leave the buffer management to the caller. (Omitting this class).

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Thu Jan 19 20:00:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Jan 2023 20:00:25 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <Hx7K6nSJqfJi6QFp4842whQC_IX-21ktGztPkF8HaE4=.cfd8f26c-dc1a-4beb-9453-d7069df31607@github.com>

On Wed, 18 Jan 2023 16:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Performance looks promising for serialization (values in us/operation):

<google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">

? | Java 20 | Java 21 | Improvement
-- | -- | -- | --
SerializeBenchmark.serializeData | 7.283 | 6.793 | 6.7%
SerializeBenchmark.serializeRecord | 7.275 | 6.733 | 7.5%

</google-sheets-html-origin>


![image](https://user-images.githubusercontent.com/7457876/213516307-c39c0467-8cd0-4fd8-9d4b-f56b17e1a4ca.png)

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From duke at openjdk.org  Thu Jan 19 20:04:56 2023
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 19 Jan 2023 20:04:56 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <qTQNWI17la4ClLOgIrqtcQ0BXs4L1e7A4kgADaIS68c=.d6412635-6d5c-4e66-93b8-cc4462c78d32@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

@JimLaskey May I please have a review on this?

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From martin at openjdk.org  Thu Jan 19 20:48:28 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 19 Jan 2023 20:48:28 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <sjbztmszXSuDm7MP5D9cFxLFmBTtO7KAH5yZUnEgXX0=.2210d43f-d9a6-4d51-9e08-f7bcfa7149fa@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

On Thu, Jan 19, 2023 at 4:29 AM fabioromano1 ***@***.***>
wrote:

> Like other reviewers, changing the performance tradeoffs in BitSet make me
> uncomfortable.
>
> 30 years of code has adapted to the current performance tradeoffs. Those
> users who really need O(1) cardinality() can fairly easily implement it in
> client code (and probably have).
>
> The spirit of BitSet is space efficiency, and adding another field negates
> that.
>
> cardinality() is O(N) but in practice should be very efficient due to
> linear traversal and (presumably) the use of hardware bitcount instructions
> for each word (fix that if not true).
>
> There may be a case for a BitSet rewrite (e.g. to support large sparse
> bitsets) once we have compact value types.
>
> Leaving to the client the responsibility of implementation isn't against
> the principle of information hiding and encapsulation?
>
The client already has a pretty good implementation of cardinality().
One can see the effort the JVM engineers put into optimizing bitCounting
arrays of longs.

The proposed change is an example of something that happens a lot -
something helps a particular use case while extracting a small but
perpetual tax on all other users of the JDK, (here including future
maintainers of BitSet).

Adding a redundant field to BitSet increases the risk of not keeping the
new field in sync.  Are we sure we've tested that every mutating method
correctly updates the new field?  What about new methods added in future
years?

---

Just to show that we care about BitSet performance, here's a (start of a)
change that I **would** make:

--- a/src/java.base/share/classes/java/util/BitSet.java
+++ b/src/java.base/share/classes/java/util/BitSet.java
@@ -897,6 +897,8 @@ public class BitSet implements Cloneable,
java.io.Serializable {
      * @since  1.4
      */
     public int cardinality() {
+        final int wordsInUse = this.wordsInUse;
+        final long[] words = this.words;
         int sum = 0;
         for (int i = 0; i < wordsInUse; i++)
             sum += Long.bitCount(words[i]);

I bet that provides a measurable performance improvement, at least with
some current VMs.
But probably warmed up C2 doesn't need this help.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From mchung at openjdk.org  Thu Jan 19 20:50:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Jan 2023 20:50:54 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the iterations of
 warmup loop in VarHandles tests
Message-ID: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>

`java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.

This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.


Before:
make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total

After:
make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total

-------------

Commit messages:
 - 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests

Changes: https://git.openjdk.org/jdk/pull/12104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300693
  Stats: 182 lines in 27 files changed: 54 ins; 30 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/12104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12104/head:pull/12104

PR: https://git.openjdk.org/jdk/pull/12104

From duke at openjdk.org  Thu Jan 19 21:18:51 2023
From: duke at openjdk.org (fabioromano1)
Date: Thu, 19 Jan 2023 21:18:51 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <VCo549fuhs2kC8yVyvS5FYzlS_3pj9MlQwyxmJNqIUk=.e2611efe-b150-4239-a5af-505db9a3a00a@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

> On Thu, Jan 19, 2023 at 4:29 AM fabioromano1 ***@***.***> wrote: Like other reviewers, changing the performance tradeoffs in BitSet make me uncomfortable. 30 years of code has adapted to the current performance tradeoffs. Those users who really need O(1) cardinality() can fairly easily implement it in client code (and probably have). The spirit of BitSet is space efficiency, and adding another field negates that. cardinality() is O(N) but in practice should be very efficient due to linear traversal and (presumably) the use of hardware bitcount instructions for each word (fix that if not true). There may be a case for a BitSet rewrite (e.g. to support large sparse bitsets) once we have compact value types. Leaving to the client the responsibility of implementation isn't against the principle of information hiding and encapsulation?
> The client already has a pretty good implementation of cardinality(). One can see the effort the JVM engineers put into optimizing bitCounting arrays of longs. The proposed change is an example of something that happens a lot - something helps a particular use case while extracting a small but perpetual tax on all other users of the JDK, (here including future maintainers of BitSet). Adding a redundant field to BitSet increases the risk of not keeping the new field in sync. Are we sure we've tested that every mutating method correctly updates the new field? What about new methods added in future years?
> [?](#)
> --- Just to show that we care about BitSet performance, here's a (start of a) change that I **would** make:
> --- a/src/java.base/share/classes/java/util/BitSet.java +++ b/src/java.base/share/classes/java/util/BitSet.java @@ -897,6 +897,8 @@ public class BitSet implements Cloneable, java.io.Serializable { * @SInCE 1.4 */ public int cardinality() { + final int wordsInUse = this.wordsInUse; + final long[] words = this.words; int sum = 0; for (int i = 0; i < wordsInUse; i++) sum += Long.bitCount(words[i]); I bet that provides a measurable performance improvement, at least with some current VMs. But probably warmed up C2 doesn't need this help.

The patch has passed all existing tests of the class. Anyway, I decided to do instead a subclass that implements this enhancement, in order to avoid creating the problems shown here.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From darcy at openjdk.org  Thu Jan 19 22:00:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Jan 2023 22:00:41 GMT
Subject: RFR: JDK-8300698: Missing @since tag for
 ClassFileFormatVersion.RELEASE_21
Message-ID: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>

The addition of the new enum constant for ClassFileFormatVersion.RELEASE_21 neglected to include an @since tag; this should be corrected.

-------------

Commit messages:
 - JDK-8300698: Missing @since tag for ClassFileFormatVersion.RELEASE_21

Changes: https://git.openjdk.org/jdk/pull/12107/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300698
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12107.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12107/head:pull/12107

PR: https://git.openjdk.org/jdk/pull/12107

From rriggs at openjdk.org  Thu Jan 19 22:07:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 19 Jan 2023 22:07:54 GMT
Subject: RFR: JDK-8300698: Missing @since tag for
 ClassFileFormatVersion.RELEASE_21
In-Reply-To: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
References: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
Message-ID: <hKFKj-WnqC3OFSAqoJ_sLMiluz_YidbdLnQ-iVe_DaU=.066a0a97-31f8-4634-b1d7-162c967eb381@github.com>

On Thu, 19 Jan 2023 21:52:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The addition of the new enum constant for ClassFileFormatVersion.RELEASE_21 neglected to include an @since tag; this should be corrected.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12107

From mchung at openjdk.org  Thu Jan 19 22:07:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Jan 2023 22:07:54 GMT
Subject: RFR: JDK-8300698: Missing @since tag for
 ClassFileFormatVersion.RELEASE_21
In-Reply-To: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
References: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
Message-ID: <bjCAyUf34WkeWdPwOVdKSe93ntE2CQ4A2xpqDoYcusc=.fe190154-c4fa-4c2a-90be-0fbf3198842f@github.com>

On Thu, 19 Jan 2023 21:52:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The addition of the new enum constant for ClassFileFormatVersion.RELEASE_21 neglected to include an @since tag; this should be corrected.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12107

From darcy at openjdk.org  Thu Jan 19 22:14:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Jan 2023 22:14:58 GMT
Subject: Integrated: JDK-8300698: Missing @since tag for
 ClassFileFormatVersion.RELEASE_21
In-Reply-To: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
References: <mCcQvbdgDUVUDuumjzlid4729pHDUDcRqBb7hxDTaJw=.c50ed974-6c21-4f54-b4d8-6d9a60f9eca5@github.com>
Message-ID: <Ifi6ZLyO2oImNSuCL8w1BCUTlkVEeYgXOUFVE1W8FmI=.b5ffbc13-9a27-430e-9668-c3f14895f2d3@github.com>

On Thu, 19 Jan 2023 21:52:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The addition of the new enum constant for ClassFileFormatVersion.RELEASE_21 neglected to include an @since tag; this should be corrected.

This pull request has now been integrated.

Changeset: f2a1eb98
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2a1eb980437b43cde222755dbf427d7916cf9e2
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8300698: Missing @since tag for ClassFileFormatVersion.RELEASE_21

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12107

From jlu at openjdk.org  Thu Jan 19 22:34:02 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Jan 2023 22:34:02 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in java.text.CollationKey
 and java.text.CompactNumberFormat
Message-ID: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)

-------------

Commit messages:
 - Use linkplain for plain text internal links
 - Swap to snippet

Changes: https://git.openjdk.org/jdk/pull/12108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300589
  Stats: 15 lines in 2 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12108.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12108/head:pull/12108

PR: https://git.openjdk.org/jdk/pull/12108

From jlu at openjdk.org  Thu Jan 19 22:38:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Jan 2023 22:38:51 GMT
Subject: Integrated: 8300356: Refactor code examples to use @snippet in
 java.text.CollationElementIterator
In-Reply-To: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
References: <KDDtgTJP0cm7RDWaJYp60VQBp3RHUkmRQJMQvnF3TuY=.fabeb307-737e-45d7-8e89-182eadc5c2af@github.com>
Message-ID: <MHp5Bstl2mtdFhlCwOIrO05z2ZCSIEIqJ1MQjj7QHDA=.fa787742-5553-41aa-95e7-489512d285b5@github.com>

On Tue, 17 Jan 2023 23:14:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationElementIterator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationElementIterator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> 
> Additionally, removed a floating colon in the code example

This pull request has now been integrated.

Changeset: fbbb27e7
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbbb27e77085c346a251e75527af8b21e76f7fc5
Stats:     12 lines in 1 file changed: 0 ins; 2 del; 10 mod

8300356: Refactor code examples to use @snippet in java.text.CollationElementIterator

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12055

From martin at openjdk.org  Thu Jan 19 22:39:33 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 19 Jan 2023 22:39:33 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <eHKH6c1a42JZYuwlrrYdu9Iq8Pdp6_4c0PTiXKoA6gw=.b34e1228-d724-47c9-bb24-bc51dbe6cf49@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

On Thu, Jan 19, 2023 at 1:15 PM fabioromano1 ***@***.***>
wrote:

> The patch has passed all existing tests of the class
>
Existing tests are very unlikely to be good enough when introducing a new
invariant that all mutating methods need to maintain.

As an example of what to look out for, you want to eliminate the
possibility of an exception being thrown between the update of the long[]
and the update of the cardinality field, and testing for that sort of thing
is rarely done well.

> Message ID: ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From jlu at openjdk.org  Thu Jan 19 22:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Jan 2023 22:39:42 GMT
Subject: Integrated: 8300586: Refactor code examples to use @snippet in
 java.text.Collator
In-Reply-To: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
References: <Sd4Zr44jesiUE22boqoHYrlW0ytKOnOhQpaTRO5WGgY=.8ac4e892-484b-4117-8e84-1d905e4080f2@github.com>
Message-ID: <RrMb4srzePT9nxOaukek27LIq5qepwF2paxTHEEXN_U=.42a3bfc7-3e42-4667-934d-9d722e8bbe95@github.com>

On Wed, 18 Jan 2023 19:36:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.Collator](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/Collator.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, the code examples have been slightly tweaked to increase readability.

This pull request has now been integrated.

Changeset: 9b97699b
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b97699be50966672d382a6f288a543ab42bdfd0
Stats:     10 lines in 1 file changed: 1 ins; 0 del; 9 mod

8300586: Refactor code examples to use @snippet in java.text.Collator

Reviewed-by: iris, lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12080

From lancea at openjdk.org  Thu Jan 19 22:53:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 19 Jan 2023 22:53:30 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat
In-Reply-To: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
Message-ID: <DG0E2s2qg8efg-_3hSgfb1P8jB7QKizRWofuSJftI2Y=.1cfc5253-bc25-4ac5-adbe-2f7709978cdf@github.com>

On Thu, 19 Jan 2023 22:25:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From psandoz at openjdk.org  Thu Jan 19 23:04:05 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Jan 2023 23:04:05 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle
In-Reply-To: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
Message-ID: <koTtileWG8qqxg1o1w2rlIh_RpvOzVtSaT7pTkwcNOM=.e8cbc0d0-8ccf-4c4b-af7a-4f1116c9fb99@github.com>

On Thu, 19 Jan 2023 19:14:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 187:

> 185:     // Required by instance static field handles
> 186:     static Field getStaticFieldFromBaseAndOffset(Class<?> receiverType,
> 187:                                                  Object base,

`base` is now unused.

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From jrose at openjdk.org  Thu Jan 19 23:16:33 2023
From: jrose at openjdk.org (John R Rose)
Date: Thu, 19 Jan 2023 23:16:33 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
Message-ID: <GuI8QaTmVRjWZ9JziuRhqpL-RIL5Zu0PFTqi6mV665A=.0c29d8dd-fcca-47ac-a637-658819d49842@github.com>

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

I'll pile on:  This optimization doesn't buy much in today's world, where most machines execute `bitCount` in one cycle.  It saves a trivial loop.  Over very large bitsets that saves something, but most bitsets are likely to be medium to small (across all use cases).  And for large bitsets, if there is a problem with cardinality testing, the user should provide for it separately.  Perhaps as a class which contains a bitset, plus the extra cached information.  You might also cache the index of the first and last words containing a set bit.  There's no end to what one might cache:  It's data, and you can derive information from it.  That's a job for users, not for the library.

Also, as folks have noted, adding a speedup in one place pushes slowdowns in other places.  Worst of all, there are new race conditions in the "improved" data structure.

I don't recommend this change.  If the data structure were immutable, I might think otherwise (as String caches its hashcode), but the race conditions really spoil it for me.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From naoto at openjdk.org  Thu Jan 19 23:24:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 19 Jan 2023 23:24:41 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat
In-Reply-To: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
Message-ID: <eFzT02Pu3tmw1qawGr9zEkCIByVdbB11UR3ZW1PzZM0=.6fd9a1b9-83c2-4b09-bcf2-1e81ee798bf4@github.com>

On Thu, 19 Jan 2023 22:25:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)

Looks good. Minor suggestions follow.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 387:

> 385:      * @param symbols the set of symbols to be used
> 386:      * @param compactPatterns an array of
> 387:      *        {@linkplain CompactNumberFormat##compact_number_patterns

Can eliminate `CompactNumberFormat` here.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 415:

> 413:      * @param symbols the set of symbols to be used
> 414:      * @param compactPatterns an array of
> 415:      *        {@linkplain CompactNumberFormat##compact_number_patterns

Same as above.

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From jlu at openjdk.org  Thu Jan 19 23:29:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Jan 2023 23:29:07 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat
In-Reply-To: <eFzT02Pu3tmw1qawGr9zEkCIByVdbB11UR3ZW1PzZM0=.6fd9a1b9-83c2-4b09-bcf2-1e81ee798bf4@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
 <eFzT02Pu3tmw1qawGr9zEkCIByVdbB11UR3ZW1PzZM0=.6fd9a1b9-83c2-4b09-bcf2-1e81ee798bf4@github.com>
Message-ID: <_mm0YTshrJ-ORuMA8TQYvAvIZQujtuMmFNcnmQ_xdm4=.944b2a8a-cdc5-4d93-b4a5-7a8787af1300@github.com>

On Thu, 19 Jan 2023 23:20:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 387:
> 
>> 385:      * @param symbols the set of symbols to be used
>> 386:      * @param compactPatterns an array of
>> 387:      *        {@linkplain CompactNumberFormat##compact_number_patterns
> 
> Can eliminate `CompactNumberFormat` here.

Ah good point, it's the same file. Will make the change, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From mchung at openjdk.org  Thu Jan 19 23:37:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Jan 2023 23:37:17 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle [v2]
In-Reply-To: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
Message-ID: <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>

> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  remove the base parameter which is unused

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12100/files
  - new: https://git.openjdk.org/jdk/pull/12100/files/d1e1f9f0..5616f777

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12100&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12100&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12100.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12100/head:pull/12100

PR: https://git.openjdk.org/jdk/pull/12100

From psandoz at openjdk.org  Thu Jan 19 23:37:19 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Jan 2023 23:37:19 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle [v2]
In-Reply-To: <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
 <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
Message-ID: <jGUrmIuXG2kOgkqwFGwSm7n62Py7EmlIYd3-zNyFcTg=.d92a9c34-f73e-40f4-8a1d-58bfee31236c@github.com>

On Thu, 19 Jan 2023 23:34:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the base parameter which is unused

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From mchung at openjdk.org  Thu Jan 19 23:37:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Jan 2023 23:37:22 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle [v2]
In-Reply-To: <koTtileWG8qqxg1o1w2rlIh_RpvOzVtSaT7pTkwcNOM=.e8cbc0d0-8ccf-4c4b-af7a-4f1116c9fb99@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
 <koTtileWG8qqxg1o1w2rlIh_RpvOzVtSaT7pTkwcNOM=.e8cbc0d0-8ccf-4c4b-af7a-4f1116c9fb99@github.com>
Message-ID: <7C6TuMsC9-24fPmwesyRrHCpB4bzCyg-NAgBgya2XP0=.7e7e22c8-9881-4680-88ee-a26ad74200a5@github.com>

On Thu, 19 Jan 2023 23:01:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove the base parameter which is unused
>
> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 187:
> 
>> 185:     // Required by instance static field handles
>> 186:     static Field getStaticFieldFromBaseAndOffset(Class<?> receiverType,
>> 187:                                                  Object base,
> 
> `base` is now unused.

Removed.  Thanks for catching it.

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From ysr at openjdk.org  Fri Jan 20 01:21:50 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 20 Jan 2023 01:21:50 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <RO_9w_DOPD79FbA-ASNRYjxjttEA7wFrFBXzcwqnpyU=.688d0538-96c8-41ef-966b-472639d8e951@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

cc @jddarcy ... as another potential reviewer. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From smarks at openjdk.org  Fri Jan 20 01:58:40 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 20 Jan 2023 01:58:40 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
 <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
 <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
Message-ID: <vxDChtEn7VusYDIzz0lVCBsoAyi_f2oi2nKDb5s4kDM=.1a721ab5-0144-4a78-b445-d0a8241dfc29@github.com>

On Tue, 17 Jan 2023 12:23:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The choice of a `<p>` paragraph rather than `@apiNote` is for consistency with similar commentary paragraphs in the specs of `CASE_INSENSITIVE`, `UNICODE_CASE`, and `UNICODE_CHARACTER_CLASS`.
>> 
>> I have no problems in using `@apiNote` instead, but then it would be better to apply the same for the other mentioned flags as well.
>
> Okay, I see your point and to use apiNote consistently would require "converting" some of the existing text to apiNote too.
> 
> I'm still mulling over Pattern.compile throwing OOME. An implNote is probably the right category for this, in which case it can start with "In the the JDK Reference Implementation ...".  I assume the static Pattern.matches needs same, and also Pattern.matcher for the lazy compilation case.

@AlanBateman

I had previously discussed with @rgiulietti whether OOME or PatternSyntaxException was more appropriate. The issue is that you might try to compile a pattern that contains a character with N combining diacritics, and it might work fine. But if you change that character to have N+1 combining diacritics, it might throw OOME. There's no syntax difference, but rather the issue is hitting an internal implementation limit.

There's a bit of a precedent for throwing OOME in such cases. Various places in the library try to grow arrays. If the required array size is greater than MAX_VALUE, the library pre-emptively throws OOME without even trying to allocate the array.

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From smarks at openjdk.org  Fri Jan 20 02:12:13 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 20 Jan 2023 02:12:13 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <xFdQ_2TIdFhPwIe1ABNwR9IrTdC9fiN-lSnY4UZ9cO8=.5926e15c-1361-41f8-8597-7fdeebaf1f8d@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <xFdQ_2TIdFhPwIe1ABNwR9IrTdC9fiN-lSnY4UZ9cO8=.5926e15c-1361-41f8-8597-7fdeebaf1f8d@github.com>
Message-ID: <eTR1CUGaUSKihANnYfPKvQck6OCFu7hFnec07MLRIuE=.444afd74-8d20-4951-89d3-08e9eb850df0@github.com>

On Thu, 19 Jan 2023 15:27:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> - Strengthen a computation that could overflow.
>> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From smarks at openjdk.org  Fri Jan 20 02:12:15 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 20 Jan 2023 02:12:15 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <vxDChtEn7VusYDIzz0lVCBsoAyi_f2oi2nKDb5s4kDM=.1a721ab5-0144-4a78-b445-d0a8241dfc29@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <Ll3a8Qn-lua7p7g55K1A8foQl74NK5mDFyt-6SVsWi4=.973f4e91-64a8-48d2-af52-e75a3cd46d59@github.com>
 <DzIbrU6gEqkZU4QT54RPB4W9Cs0wEZXOJkv7pBl92Rg=.74db37b3-f7b8-4a6e-97d6-c6ee70ce62a5@github.com>
 <PJ8zKoNYFj9iKpVYUJaxjyX9AmDD06y73FjFJjAXgB4=.c91a1a50-c562-4896-bfe1-a9990b725905@github.com>
 <vxDChtEn7VusYDIzz0lVCBsoAyi_f2oi2nKDb5s4kDM=.1a721ab5-0144-4a78-b445-d0a8241dfc29@github.com>
Message-ID: <drVzrWDBYi0KLrDJ0wiKTdTc2KdDvRSSDwbufxkwO-M=.50e8f43d-b9f6-43cf-ba56-1d5697da62b2@github.com>

On Fri, 20 Jan 2023 01:56:16 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Okay, I see your point and to use apiNote consistently would require "converting" some of the existing text to apiNote too.
>> 
>> I'm still mulling over Pattern.compile throwing OOME. An implNote is probably the right category for this, in which case it can start with "In the the JDK Reference Implementation ...".  I assume the static Pattern.matches needs same, and also Pattern.matcher for the lazy compilation case.
>
> @AlanBateman
> 
> I had previously discussed with @rgiulietti whether OOME or PatternSyntaxException was more appropriate. The issue is that you might try to compile a pattern that contains a character with N combining diacritics, and it might work fine. But if you change that character to have N+1 combining diacritics, it might throw OOME. There's no syntax difference, but rather the issue is hitting an internal implementation limit.
> 
> There's a bit of a precedent for throwing OOME in such cases. Various places in the library try to grow arrays. If the required array size is greater than MAX_VALUE, the library pre-emptively throws OOME without even trying to allocate the array.

> "In the the JDK Reference Implementation ..."

I'm still not sure of the right style for the JDK to refer to itself. This is really the "Java SE Reference Implementation". Or perhaps it should just be "OpenJDK". Regardless, this kind of wording would stick out in a funny way, as it's not used very frequently. I'm content not having such a preamble. Having the text within `@implNote` is probably sufficient.

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From dholmes at openjdk.org  Fri Jan 20 04:55:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Jan 2023 04:55:41 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests
In-Reply-To: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
Message-ID: <7K2v2uCaBKMq4TaXSQLoMqX6KSs6wbmIjxc81z2IFhY=.9c7f4b8f-9859-4688-b6ad-47942cf72b68@github.com>

On Thu, 19 Jan 2023 20:43:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
> 
> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
> 
> 
> Before:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
> 
> After:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total

test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java line 284:

> 282: 
> 283:     // CompileThresholdScaling is set to 0.1 and ITERS to 2000 to reduce
> 284:     // the test execution

Wouldn't this be clearer as an `@comment` in the test header prior to the `@run` statements that use the variables?

-------------

PR: https://git.openjdk.org/jdk/pull/12104

From alanb at openjdk.org  Fri Jan 20 06:59:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jan 2023 06:59:29 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle [v2]
In-Reply-To: <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
 <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
Message-ID: <zuGDrLGM3GGYxDUNlluHIAs8XP-23kT4xiU_XK0BniI=.d9644f9e-1386-454d-b0b9-6a742e4fd70c@github.com>

On Thu, 19 Jan 2023 23:37:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the base parameter which is unused

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From duke at openjdk.org  Fri Jan 20 08:00:31 2023
From: duke at openjdk.org (fabioromano1)
Date: Fri, 20 Jan 2023 08:00:31 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v5]
In-Reply-To: <GuI8QaTmVRjWZ9JziuRhqpL-RIL5Zu0PFTqi6mV665A=.0c29d8dd-fcca-47ac-a637-658819d49842@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
 <Xv7MAeM0uv-Hi9oEHVKoqFguVv-g7GsE6vrO_p3x9Qw=.508ba893-dccc-4f93-8316-162518dce4e4@github.com>
 <GuI8QaTmVRjWZ9JziuRhqpL-RIL5Zu0PFTqi6mV665A=.0c29d8dd-fcca-47ac-a637-658819d49842@github.com>
Message-ID: <mg5tDRZLBneb-QiEnhJI4zIwf_B2RsJMuuD_GaCVZg4=.7147757e-7af1-4352-928c-405df274f77a@github.com>

On Thu, 19 Jan 2023 23:14:12 GMT, John R Rose <jrose at openjdk.org> wrote:

> I'll pile on: This optimization doesn't buy much in today's world, where most machines execute `bitCount` in one cycle. It saves a trivial loop. Over very large bitsets that saves something, but most bitsets are likely to be medium to small (across all use cases). And for large bitsets, if there is a problem with cardinality testing, the user should provide for it separately. Perhaps as a class which contains a bitset, plus the extra cached information. You might also cache the index of the first and last words containing a set bit. There's no end to what one might cache: It's data, and you can derive information from it. That's a job for users, not for the library.
> 
> Also, as folks have noted, adding a speedup in one place pushes slowdowns in other places. Worst of all, there are new race conditions in the "improved" data structure.
> 
> I don't recommend this change. If the data structure were immutable, I might think otherwise (as String caches its hashcode), but the race conditions really spoil it for me.

As @cl4es noted, race conditions are not a problem, since BitSet is not a thread-safe class. Anyway, I decided to do instead a subclass that implements this enhancement, in order to avoid creating the problems shown here.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From rgiulietti at openjdk.org  Fri Jan 20 09:10:28 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 20 Jan 2023 09:10:28 GMT
Subject: RFR: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern [v2]
In-Reply-To: <xFdQ_2TIdFhPwIe1ABNwR9IrTdC9fiN-lSnY4UZ9cO8=.5926e15c-1361-41f8-8597-7fdeebaf1f8d@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
 <xFdQ_2TIdFhPwIe1ABNwR9IrTdC9fiN-lSnY4UZ9cO8=.5926e15c-1361-41f8-8597-7fdeebaf1f8d@github.com>
Message-ID: <nIXHMJWKst8HZoDaA57mxTjR9RPxHlb5QTNKh0EYpz0=.15eca0f6-9a81-4333-b2c7-5d42858b3fec@github.com>

On Thu, 19 Jan 2023 15:27:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> - Strengthen a computation that could overflow.
>> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern

The [CSR](https://bugs.openjdk.org/browse/JDK-8300209) is ready for review.

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From alanb at openjdk.org  Fri Jan 20 11:13:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jan 2023 11:13:28 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <sJymL4dGb-pt1BOOWtf20pyDq-PKMByzk-lv2raWRnA=.b49e56fe-ab81-4ec0-a6dc-afecc04e45f8@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From alanb at openjdk.org  Fri Jan 20 11:13:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jan 2023 11:13:30 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <O28fzZHNH9u_7MPG3IuJS27_4FJrKB_PTq6h_eXxgIU=.c9b6675e-9f00-4f57-8068-28ca5fea7583@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
 <O28fzZHNH9u_7MPG3IuJS27_4FJrKB_PTq6h_eXxgIU=.c9b6675e-9f00-4f57-8068-28ca5fea7583@github.com>
Message-ID: <C1hBiWxu20d3ORDa6E-EXMeqGVSa5F6jC9lYCZvm6QE=.d994559d-ee95-4abf-bcf7-12a97a1ac76f@github.com>

On Thu, 19 Jan 2023 09:46:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the same directory. It's not exactly necessary for this use case to add such a benchmark, but I think there's value in verifying that optimizing `checkedHash` improves `ZipFile` setup and adding the micro might allow us to find further opportunities down the line.

I've no doubt it improves checkedHash, it's just that open the zip file and reading in the CEN probably dominates when not in the file system cache.

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From lancea at openjdk.org  Fri Jan 20 11:28:29 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Jan 2023 11:28:29 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <W41khs1GzpWZpMyMm6CKI8eREAiyTGovbH7yxSncX-0=.3c3b59a1-0735-4e01-ad08-6e502fa832b2@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 69:

> 67: 
> 68:                 ename += "long-entry-name-"  + (random.nextInt(90000) + 10000)  + "-" + i;
> 69:                 zos.putNextEntry(new ZipEntry(ename));

Would it be worth to add some random sized data when the entries are created to allow for getting a bit more insight, or  perhaps do that in a separate benchmark>

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From jvernee at openjdk.org  Fri Jan 20 11:31:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Jan 2023 11:31:30 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests
In-Reply-To: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
Message-ID: <94DhDNzEhNvjdW-rFYXwzYbUSoQiVCM20C4zvTPxomA=.dffcadde-2328-4e8f-914f-fb5c6f66cc0a@github.com>

On Thu, 19 Jan 2023 20:43:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
> 
> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
> 
> 
> Before:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
> 
> After:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12104

From redestad at openjdk.org  Fri Jan 20 11:46:27 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Jan 2023 11:46:27 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <C1hBiWxu20d3ORDa6E-EXMeqGVSa5F6jC9lYCZvm6QE=.d994559d-ee95-4abf-bcf7-12a97a1ac76f@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
 <O28fzZHNH9u_7MPG3IuJS27_4FJrKB_PTq6h_eXxgIU=.c9b6675e-9f00-4f57-8068-28ca5fea7583@github.com>
 <C1hBiWxu20d3ORDa6E-EXMeqGVSa5F6jC9lYCZvm6QE=.d994559d-ee95-4abf-bcf7-12a97a1ac76f@github.com>
Message-ID: <4B70ZXaRM2xrMkafrLTYQz9FgsvK13J2XQpO6FTyJNY=.49000c80-5fa0-4402-b2ea-51110e3b75f5@github.com>

On Fri, 20 Jan 2023 11:10:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the same directory. It's not exactly necessary for this use case to add such a benchmark, but I think there's value in verifying that optimizing `checkedHash` improves `ZipFile` setup and adding the micro might allow us to find further opportunities down the line.
> 
> I've no doubt it improves checkedHash, it's just that open the zip file and reading in the CEN probably dominates when not in the file system cache.

Right, the micro is a poor proxy for real-world implications since time to open a zip file very much depends on the filesystem speed but this is sort of by design. We have separate startup tests that tries to emulate more "cold start" scenarios, which micros like this are complementary to and not a substitute for.

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From redestad at openjdk.org  Fri Jan 20 11:52:30 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Jan 2023 11:52:30 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <W41khs1GzpWZpMyMm6CKI8eREAiyTGovbH7yxSncX-0=.3c3b59a1-0735-4e01-ad08-6e502fa832b2@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
 <W41khs1GzpWZpMyMm6CKI8eREAiyTGovbH7yxSncX-0=.3c3b59a1-0735-4e01-ad08-6e502fa832b2@github.com>
Message-ID: <k6XfIrziJI5x3vMRfN-xT8U2BHD5Qeqlgu2iKYiUwcc=.66cf9054-925d-4d7f-97af-989c981da29b@github.com>

On Fri, 20 Jan 2023 11:25:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
>> 
>> Before:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
>> 
>> After:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op
>
> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 69:
> 
>> 67: 
>> 68:                 ename += "long-entry-name-"  + (random.nextInt(90000) + 10000)  + "-" + i;
>> 69:                 zos.putNextEntry(new ZipEntry(ename));
> 
> Would it be worth to add some random sized data when the entries are created to allow for getting a bit more insight, or  perhaps do that in a separate benchmark>

I was experimenting with varying the entry names length to see what - if any - impact it had and saw a small effect on the micro. It does make more sense to vary lengths now that very long names will take different paths in the vectorized intrinsic. I'll see what I can do without overengineering this.

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From redestad at openjdk.org  Fri Jan 20 12:19:50 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Jan 2023 12:19:50 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder [v2]
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <iGhC2WYtZkfCY9nF42qr13RRJH14sQOiXq9sjFbS114=.aaf4005b-f4c6-45bc-9e62-3713f876f3d4@github.com>

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Vary dir and entry name lengths across a wider spread, keeping most entries short but making the longest paths longer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12077/files
  - new: https://git.openjdk.org/jdk/pull/12077/files/0c7f0f4f..369537c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12077&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12077&range=00-01

  Stats: 9 lines in 1 file changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12077.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12077/head:pull/12077

PR: https://git.openjdk.org/jdk/pull/12077

From redestad at openjdk.org  Fri Jan 20 12:19:51 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Jan 2023 12:19:51 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <KDCDyyE7MUFmWDgberfSN2cSpdsu0LviaA8GbmWe7e8=.ed235b1d-6d64-4201-8fd2-bffd904cf002@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

Updated micro to vary entry sizes more to ensure we exercise the different code paths through the `hashCode` intrinsic. The new setup generates both longer and shorter entries than before, weighting up the average length a bit by increasing the spread. The longer entries see a proportionately larger speed-up, as expected since they benefit from vectorization. Removed some pointless randomness.

Baseline:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   98832.801 ? 2155.928  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  187373.545 ? 2296.779  ns/op


Patched:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   85574.648 ?  920.477  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  160493.277 ? 3450.928  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From jpai at openjdk.org  Fri Jan 20 14:27:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Jan 2023 14:27:29 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <1HhkAm6zOraN3gQyG4W2NWigKTVfiTr7dSD7dTIVf-g=.e8f89c6a-9efd-4823-97ac-cf131cd26314@github.com>

On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Thank you everyone for the review and the suggestions.

> Right now the ModuleTarget class file attribute is not enough but a short term fix might be for jlink to have a simple mapping of known ModuleTarget values to endianness. Overall, it's probably low priority as the most likely users of this will be environments building for embedded platforms.

I'll experiment with the short term fix. For now, I'll put this PR in draft and will reopen when it's ready for review.

-------------

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Fri Jan 20 14:27:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Jan 2023 14:27:33 GMT
Subject: RFR: 8206890: jlink --endian XXX generates unusable image if
 endian-ness does not match architecture
In-Reply-To: <S6HUlJCPs6xE4WZbxuCLjFpho2Uq_ZPT7LpG1PBfAm4=.ed49590f-2c30-4e40-9950-4e3f44919c93@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <S6HUlJCPs6xE4WZbxuCLjFpho2Uq_ZPT7LpG1PBfAm4=.ed49590f-2c30-4e40-9950-4e3f44919c93@github.com>
Message-ID: <jpRl2ubduikpbzYzrOu78Wv0DGdePfdHrC8VoFPS0qE=.811f20fb-985b-4816-af36-50d81a9e7b63@github.com>

On Tue, 17 Jan 2023 17:41:33 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 226:
> 
>> 224:         ByteOrder altByteOrder = bb.order() == ByteOrder.BIG_ENDIAN
>> 225:                 ? ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN;
>> 226:         bb.flip();
> 
> Don't you just want to rewind here?

Hello Jim, you are right `rewind()` would be a better API to use here.

-------------

PR: https://git.openjdk.org/jdk/pull/11943

From sgehwolf at openjdk.org  Fri Jan 20 16:03:58 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 20 Jan 2023 16:03:58 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large
In-Reply-To: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
Message-ID: <iF40s55OjehJ8z0RfB9WDkKbgDt79UzU3TioI1PiFk4=.c47c3e6f-97ba-4c70-9e06-96659867584d@github.com>

On Fri, 20 Jan 2023 15:53:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
> 
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)

Re-running GHA here: https://github.com/jerboaa/jdk/actions/runs/3960838920

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Fri Jan 20 16:02:13 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 20 Jan 2023 16:02:13 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly when
 too large
Message-ID: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>

Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).

Testing:
- [x] Container tests on linux x86_64 with cg v1
- [x] Container tests on linux x86_64 with cg v2
- [ ] GHA (seem to have had some infra issues, so re-running)

-------------

Depends on: https://git.openjdk.org/jdk/pull/12097

Commit messages:
 - 8299858: [Metrics] Swap memory limit reported incorrectly when too large

Changes: https://git.openjdk.org/jdk/pull/12118/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299858
  Stats: 65 lines in 3 files changed: 62 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12118/head:pull/12118

PR: https://git.openjdk.org/jdk/pull/12118

From smarks at openjdk.org  Fri Jan 20 16:37:30 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 20 Jan 2023 16:37:30 GMT
Subject: Integrated: 8038146: Clarify Map.Entry's connection to the underlying
 map
In-Reply-To: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
References: <1F1sZmcA6TAurKcrlUIyZ3IGNq028F4roc6uIUNwO3k=.d9ca5746-4e95-4db7-84cf-0a7bd5953209@github.com>
Message-ID: <tNQN1SadbPh8UUT9usPpJQTIyAa6jIn1O8Pp2Ankw5c=.aace417e-848b-4b4f-840a-c6713b763c47@github.com>

On Thu, 12 Jan 2023 01:50:51 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Also additional verbiage regarding Map.Entry objects in general and their possible connection to an underlying Map.

This pull request has now been integrated.

Changeset: c6d56003
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6d560039682ec52efa6fa7755d2aa86f20e1148
Stats:     77 lines in 4 files changed: 41 ins; 3 del; 33 mod

8038146: Clarify Map.Entry's connection to the underlying map

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11956

From lancea at openjdk.org  Fri Jan 20 16:45:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Jan 2023 16:45:58 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder [v2]
In-Reply-To: <iGhC2WYtZkfCY9nF42qr13RRJH14sQOiXq9sjFbS114=.aaf4005b-f4c6-45bc-9e62-3713f876f3d4@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
 <iGhC2WYtZkfCY9nF42qr13RRJH14sQOiXq9sjFbS114=.aaf4005b-f4c6-45bc-9e62-3713f876f3d4@github.com>
Message-ID: <SjOTACcmFHekHFtO_0BhyP750WypfJ4gncQq1nKYIfw=.17926940-d9bc-435b-8ed9-b6599af83517@github.com>

On Fri, 20 Jan 2023 12:19:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
>> 
>> Before:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
>> 
>> After:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Vary dir and entry name lengths across a wider spread, keeping most entries short but making the longest paths longer

Thank you Claes

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12077

From duke at openjdk.org  Fri Jan 20 16:51:42 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 20 Jan 2023 16:51:42 GMT
Subject: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <Hh6j1S4lMXGIkR5I5XHxQ8YE48cMMbyf036MEGY__C8=.0bcae9b8-71cf-4279-a2e1-770ed161676a@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

I opened a new PR: #12119

-------------

PR: https://git.openjdk.org/jdk/pull/11897

From duke at openjdk.org  Fri Jan 20 16:51:42 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 20 Jan 2023 16:51:42 GMT
Subject: Withdrawn: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl
 always copy arrays
In-Reply-To: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
References: <AMUEQPgwdJaZx_XbPlT1fGexTGCAPZ9ahAfZKAjbzeo=.6041cb01-5cbe-4f9c-97ae-8d1f87c8445c@github.com>
Message-ID: <ZKHr96iDZEQ11lWk0U12CTdEKmwt1kiy6_OGGPwV39o=.3ea90f78-7651-43ec-98bd-520944f80dc1@github.com>

On Mon, 9 Jan 2023 03:34:55 GMT, Glavo <duke at openjdk.org> wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They always copy arrays, rather than avoiding copying as much as possible as javadoc says.
> 
> I ran the tier1 test without any new errors.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11897

From mchung at openjdk.org  Fri Jan 20 17:28:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 20 Jan 2023 17:28:56 GMT
Subject: Integrated: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle
In-Reply-To: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
Message-ID: <8JHZBzJYEpKrY_OvtnzlW7P-5-CcMhJGzINFp4mTAuk=.15ccdbfe-736d-4e15-9d04-ff4d884d2a69@github.com>

On Thu, 19 Jan 2023 19:14:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.

This pull request has now been integrated.

Changeset: facd4151
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/facd41511b972e940ecab3bc57f5f23efca43343
Stats:     35 lines in 2 files changed: 2 ins; 2 del; 31 mod

8297757: VarHandles.getStaticFieldFromBaseAndOffset should get the receiver type from VarHandle

Reviewed-by: psandoz, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From jlu at openjdk.org  Fri Jan 20 17:31:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Jan 2023 17:31:26 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat [v2]
In-Reply-To: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
Message-ID: <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Class can be removed for CNPatterns link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12108/files
  - new: https://git.openjdk.org/jdk/pull/12108/files/889f582c..0bd91514

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12108&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12108&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12108.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12108/head:pull/12108

PR: https://git.openjdk.org/jdk/pull/12108

From naoto at openjdk.org  Fri Jan 20 17:37:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jan 2023 17:37:01 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat [v2]
In-Reply-To: <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
 <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
Message-ID: <MeeNle0GaoXMN0P-zo4Q9O_vO1FVZobdh-uKRRyvano=.b0717bd7-047f-4819-b3e7-c6b342e8d541@github.com>

On Fri, 20 Jan 2023 17:31:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Class can be removed for CNPatterns link

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From lancea at openjdk.org  Fri Jan 20 17:37:02 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Jan 2023 17:37:02 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat [v2]
In-Reply-To: <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
 <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
Message-ID: <cOZRih2TZrl2dpz19g0jiupbDzxEtMttnBiwUdfzCl8=.f84adecd-aa07-45c5-82a7-2e72c9146d01@github.com>

On Fri, 20 Jan 2023 17:31:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Class can be removed for CNPatterns link

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From mchung at openjdk.org  Fri Jan 20 17:45:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 20 Jan 2023 17:45:46 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests [v2]
In-Reply-To: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
Message-ID: <26AmAOOjwZH20rQkIxJpXtt7OaFCrkj2dwgj3tMhKOM=.f4744a47-e80c-4286-891f-7fa690a66393@github.com>

> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
> 
> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
> 
> 
> Before:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
> 
> After:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  move the comment to @comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12104/files
  - new: https://git.openjdk.org/jdk/pull/12104/files/0e003531..82382291

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12104&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12104&range=00-01

  Stats: 128 lines in 27 files changed: 74 ins; 54 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12104.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12104/head:pull/12104

PR: https://git.openjdk.org/jdk/pull/12104

From mchung at openjdk.org  Fri Jan 20 17:45:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 20 Jan 2023 17:45:47 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests [v2]
In-Reply-To: <7K2v2uCaBKMq4TaXSQLoMqX6KSs6wbmIjxc81z2IFhY=.9c7f4b8f-9859-4688-b6ad-47942cf72b68@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
 <7K2v2uCaBKMq4TaXSQLoMqX6KSs6wbmIjxc81z2IFhY=.9c7f4b8f-9859-4688-b6ad-47942cf72b68@github.com>
Message-ID: <uStndBnaW-2xrj-KcG3XrV2khXS8I1Kui-U227kaGps=.1c46c00b-87e4-4aa8-96d5-65d8918d1eb9@github.com>

On Fri, 20 Jan 2023 04:53:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move the comment to @comment
>
> test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java line 284:
> 
>> 282: 
>> 283:     // CompileThresholdScaling is set to 0.1 and ITERS to 2000 to reduce
>> 284:     // the test execution
> 
> Wouldn't this be clearer as an `@comment` in the test header prior to the `@run` statements that use the variables?

Good suggestion.  Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12104

From jlu at openjdk.org  Fri Jan 20 18:05:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Jan 2023 18:05:08 GMT
Subject: RFR: 8300706: Use @snippet in java.text
Message-ID: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>

Some classes / interfaces in java.text have already implemented JEP 413.

This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
- BreakIterator
- CharacterIterator
- DateFormatSymbols
- DecimalFormat
- NumberFormat 

Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

-------------

Commit messages:
 - Snippet for NFormat
 - DecimalFormat changes
 - Example in DFSymbols should end with semicolon
 - Snippet for DFSymbols
 - Minor spacing in CIterator
 - Snippet for CIterator
 - Snippet for BIterator

Changes: https://git.openjdk.org/jdk/pull/12121/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300706
  Stats: 43 lines in 5 files changed: 1 ins; 0 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12121/head:pull/12121

PR: https://git.openjdk.org/jdk/pull/12121

From jlu at openjdk.org  Fri Jan 20 18:05:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Jan 2023 18:05:08 GMT
Subject: RFR: 8300706: Use @snippet in java.text
In-Reply-To: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
Message-ID: <iEJuzK-KkEHDJb8lh6LjoFmpdIiH3YggEA1ptGu4zvU=.3f898ffa-1fe3-4534-818a-85efbfe5993f@github.com>

On Fri, 20 Jan 2023 17:41:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Some classes / interfaces in java.text have already implemented JEP 413.
> 
> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
> - BreakIterator
> - CharacterIterator
> - DateFormatSymbols
> - DecimalFormat
> - NumberFormat 
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

src/java.base/share/classes/java/text/DecimalFormat.java line 343:

> 341:  * <blockquote><pre><strong>{@code
> 342:  * // Print out a number using the localized number, integer, currency,
> 343:  * // and percent format for each locale}</strong>{@code

This comment is originally in strong font within the code example. Replacing both instances of `@ code` with `@ snippet` will just create two separate snippet blocks, one for the comment and one for the code which does not seem ideal.

To maintain the strong font, the comment has to be outside of the code snippet.

If that's not desirable, I think some alternatives are

- Leave the comment in the code snippet and get rid of the strong font 
- Keep the strong font but convert the comment into a normal text description

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From rriggs at openjdk.org  Fri Jan 20 18:25:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jan 2023 18:25:35 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>

On Wed, 18 Jan 2023 16:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

src/java.base/share/classes/java/io/ObjectStreamClass.java line 2486:

> 2484:                 );
> 2485:             } catch (NoSuchMethodException | IllegalAccessException e) {
> 2486:                 throw new InternalError("Can't lookup BigEndian.getXXX", e);

BigEndian -> ByteArrayAccess

src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.util.access;

This is pretty deep; I'd drop the final "access". The package name `jdk.internal.util` is fine.

src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 60:

> 58:     /*
> 59:      * Methods for unpacking primitive values from byte arrays starting at
> 60:      * a given offsets.

Typo: "a given offsets".

src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 64:

> 62: 
> 63:     /**
> 64:      * Gets a {@code boolean} from the provided {@code array} at the given {@code offset}.

This could use the concise javadoc tag that provides both the first line and @return value.  For example,
`{@return Returns a {@code boolean} from the provided {@code array} at the given {@code offset}}`

src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 69:

> 67:      * @param offset where extraction in the array should begin
> 68:      * @return a {@code boolean} from the array
> 69:      * @throws NullPointerException      if the provided {@code array} is {@code null}

With the class level statement about throwing NullPointer, the @throws is not necessary in each method.

src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 614:

> 612:     /*
> 613:      * Methods for packing primitive values into byte arrays starting at offset zero.
> 614:      */

Is the only advantage to the zero offset versions in the API. 
Is there any performance difference?

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From lancea at openjdk.org  Fri Jan 20 18:38:29 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Jan 2023 18:38:29 GMT
Subject: RFR: 8300706: Use @snippet in java.text
In-Reply-To: <iEJuzK-KkEHDJb8lh6LjoFmpdIiH3YggEA1ptGu4zvU=.3f898ffa-1fe3-4534-818a-85efbfe5993f@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
 <iEJuzK-KkEHDJb8lh6LjoFmpdIiH3YggEA1ptGu4zvU=.3f898ffa-1fe3-4534-818a-85efbfe5993f@github.com>
Message-ID: <ZrRbxGaegaypWir5x0ATSDskt_txaHJXtAajqUE1jh8=.9bfdd2e8-a566-474f-853d-170adde911d5@github.com>

On Fri, 20 Jan 2023 17:57:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Some classes / interfaces in java.text have already implemented JEP 413.
>> 
>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
>> - BreakIterator
>> - CharacterIterator
>> - DateFormatSymbols
>> - DecimalFormat
>> - NumberFormat 
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 343:
> 
>> 341:  * <blockquote><pre><strong>{@code
>> 342:  * // Print out a number using the localized number, integer, currency,
>> 343:  * // and percent format for each locale}</strong>{@code
> 
> This comment is originally in strong font within the code example. Replacing both instances of `@ code` with `@ snippet` will just create two separate snippet blocks, one for the comment and one for the code which does not seem ideal.
> 
> To maintain the strong font, the comment has to be outside of the code snippet.
> 
> If that's not desirable, I think some alternatives are
> 
> - Leave the comment in the code snippet and get rid of the strong font 
> - Keep the strong font but convert the comment into a normal text description

I would leave the comment in the code snippet.  I don't see a compelling reason for it to be  as it was originally

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From jlu at openjdk.org  Fri Jan 20 18:47:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Jan 2023 18:47:54 GMT
Subject: RFR: 8300706: Use @snippet in java.text [v2]
In-Reply-To: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
Message-ID: <7W5SmQg-OFxRra67XIaijKQG0KEkx142g2h3EPuzvDE=.4e97a568-22d3-4e6d-a241-ccf541779cbc@github.com>

> Some classes / interfaces in java.text have already implemented JEP 413.
> 
> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
> - BreakIterator
> - CharacterIterator
> - DateFormatSymbols
> - DecimalFormat
> - NumberFormat 
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Drop strong font, put comment back in snippet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12121/files
  - new: https://git.openjdk.org/jdk/pull/12121/files/bf8309ef..5b0bfe85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12121&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12121&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12121/head:pull/12121

PR: https://git.openjdk.org/jdk/pull/12121

From iris at openjdk.org  Fri Jan 20 18:49:32 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 20 Jan 2023 18:49:32 GMT
Subject: RFR: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat [v2]
In-Reply-To: <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
 <baJpAJYWSoOROeIMic8r_qQedtD6U00gh1Fd_wiit18=.9680cfec-36a3-41b9-9874-bd2d8a52ae4d@github.com>
Message-ID: <BZFXx0mzI9Q6ZvE_MdbeRQCLV77pHbesItyvt8VCriI=.5dfbdc18-2d25-4cc7-a9b6-cc93c0eec6b9@github.com>

On Fri, 20 Jan 2023 17:31:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>> 
>> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Class can be removed for CNPatterns link

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From naoto at openjdk.org  Fri Jan 20 19:00:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jan 2023 19:00:26 GMT
Subject: RFR: 8300706: Use @snippet in java.text [v2]
In-Reply-To: <7W5SmQg-OFxRra67XIaijKQG0KEkx142g2h3EPuzvDE=.4e97a568-22d3-4e6d-a241-ccf541779cbc@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
 <7W5SmQg-OFxRra67XIaijKQG0KEkx142g2h3EPuzvDE=.4e97a568-22d3-4e6d-a241-ccf541779cbc@github.com>
Message-ID: <SaVbsdXmVxd6GYbTZRZazZA55KOMlQZobY6jog__wPg=.2659a404-75d1-45c9-8831-04d9f0f97459@github.com>

On Fri, 20 Jan 2023 18:47:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Some classes / interfaces in java.text have already implemented JEP 413.
>> 
>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
>> - BreakIterator
>> - CharacterIterator
>> - DateFormatSymbols
>> - DecimalFormat
>> - NumberFormat 
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop strong font, put comment back in snippet

Your changes look good. I'd clean up the examples themselves taking this opportunity.

src/java.base/share/classes/java/text/DecimalFormat.java line 75:

> 73:  * <blockquote>{@snippet lang=java :
> 74:  * NumberFormat f = NumberFormat.getInstance(loc);
> 75:  * if (f instanceof DecimalFormat) {

Pattern matching `instanceof` should be used.

src/java.base/share/classes/java/text/DecimalFormat.java line 373:

> 371:  *     }
> 372:  * }
> 373:  * }</pre></blockquote>

The example here can utilize enhanced `switch` and pattern matching `instanceof`.

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From naoto at openjdk.org  Fri Jan 20 19:00:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jan 2023 19:00:31 GMT
Subject: RFR: 8300706: Use @snippet in java.text [v2]
In-Reply-To: <ZrRbxGaegaypWir5x0ATSDskt_txaHJXtAajqUE1jh8=.9bfdd2e8-a566-474f-853d-170adde911d5@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
 <iEJuzK-KkEHDJb8lh6LjoFmpdIiH3YggEA1ptGu4zvU=.3f898ffa-1fe3-4534-818a-85efbfe5993f@github.com>
 <ZrRbxGaegaypWir5x0ATSDskt_txaHJXtAajqUE1jh8=.9bfdd2e8-a566-474f-853d-170adde911d5@github.com>
Message-ID: <URy6qQ8du6XaNS2xoyRMoGFFLmbjLkJhf5UFNSbsxsE=.28db0ead-6bd4-42ed-8eae-f34de072cd56@github.com>

On Fri, 20 Jan 2023 18:34:37 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 343:
>> 
>>> 341:  * <blockquote><pre><strong>{@code
>>> 342:  * // Print out a number using the localized number, integer, currency,
>>> 343:  * // and percent format for each locale}</strong>{@code
>> 
>> This comment is originally in strong font within the code example. Replacing both instances of `@ code` with `@ snippet` will just create two separate snippet blocks, one for the comment and one for the code which does not seem ideal.
>> 
>> To maintain the strong font, the comment has to be outside of the code snippet.
>> 
>> If that's not desirable, I think some alternatives are
>> 
>> - Leave the comment in the code snippet and get rid of the strong font 
>> - Keep the strong font but convert the comment into a normal text description
>
> I would leave the comment in the code snippet.  I don't see a compelling reason for it to be  as it was originally

+1

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From jlu at openjdk.org  Fri Jan 20 19:54:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Jan 2023 19:54:44 GMT
Subject: RFR: 8300706: Use @snippet in java.text [v3]
In-Reply-To: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
Message-ID: <C3FhrI7wkLASZ1zJVQ5R7i6PfmuMFgWHkw-H7lyfT1o=.15783d8b-7bb7-4205-83d6-dfb7b2db5944@github.com>

> Some classes / interfaces in java.text have already implemented JEP 413.
> 
> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
> - BreakIterator
> - CharacterIterator
> - DateFormatSymbols
> - DecimalFormat
> - NumberFormat 
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Close catch on same line
 - Use pattern matching instanceOf, expression switch statement, and improve for loop readability
 - Use pattern IOf (1st snippet)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12121/files
  - new: https://git.openjdk.org/jdk/pull/12121/files/5b0bfe85..f5f9632c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12121&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12121&range=01-02

  Stats: 19 lines in 1 file changed: 0 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12121/head:pull/12121

PR: https://git.openjdk.org/jdk/pull/12121

From naoto at openjdk.org  Fri Jan 20 22:08:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jan 2023 22:08:11 GMT
Subject: RFR: 8300706: Use @snippet in java.text [v3]
In-Reply-To: <C3FhrI7wkLASZ1zJVQ5R7i6PfmuMFgWHkw-H7lyfT1o=.15783d8b-7bb7-4205-83d6-dfb7b2db5944@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
 <C3FhrI7wkLASZ1zJVQ5R7i6PfmuMFgWHkw-H7lyfT1o=.15783d8b-7bb7-4205-83d6-dfb7b2db5944@github.com>
Message-ID: <B_LTQLp9jJy7NJK_d27_7XzRUkID-A4vgMph-wOTvEU=.5af9d88d-866e-4ef5-ba57-98b5dc47ac18@github.com>

On Fri, 20 Jan 2023 19:54:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Some classes / interfaces in java.text have already implemented JEP 413.
>> 
>> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
>> - BreakIterator
>> - CharacterIterator
>> - DateFormatSymbols
>> - DecimalFormat
>> - NumberFormat 
>> 
>> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Close catch on same line
>  - Use pattern matching instanceOf, expression switch statement, and improve for loop readability
>  - Use pattern IOf (1st snippet)

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From duke at openjdk.org  Sat Jan 21 00:13:35 2023
From: duke at openjdk.org (fabioromano1)
Date: Sat, 21 Jan 2023 00:13:35 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v6]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <-kSt1LLAfPaDPx3TL44jmnldGAFbnwvqjomDwQldYBQ=.49cd8a04-9319-47f3-9cdb-090b3351fa11@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Moved changes in subclass NaturalsBitSet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/7f860b79..0c3e7cdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=04-05

  Stats: 768 lines in 4 files changed: 618 ins; 103 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Sat Jan 21 00:50:43 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Sat, 21 Jan 2023 00:50:43 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
Message-ID: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>

Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.

Encode performance:
**Old:**

Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms


**New:**

Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms


Decode performance:
**Old:**

Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms

**New:**
Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

-------------

Commit messages:
 - Remove whitespace
 - Fix wrong register usage
 - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Intermediate AVX2 for decode
 - Fix various AVX support function invocations to get Base64 generated for AVX2

Changes: https://git.openjdk.org/jdk/pull/12126/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300808
  Stats: 150 lines in 7 files changed: 134 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From tvaleev at openjdk.org  Sat Jan 21 08:26:31 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 08:26:31 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v5]
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <fxjPA-fVYKAii7y0URfasC8sY64FmOWhMX19TlYLmJg=.9fb7b842-15a5-4427-9aac-b696af27cc2b@github.com>

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  @implSpec added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10520/files
  - new: https://git.openjdk.org/jdk/pull/10520/files/7b4486f8..a465bd79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From aturbanov at openjdk.org  Sat Jan 21 11:32:08 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 21 Jan 2023 11:32:08 GMT
Subject: RFR: 8300208: Optimize Adler32 stub for AVX-512 targets.
In-Reply-To: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
References: <Ad5pn9bNnBp_1QJBvyeMrz0FeCfP5JVEaAoiCbylHT4=.22066237-b7b5-4dc7-9ece-8bb3a44d9b90@github.com>
Message-ID: <kTrFywbx1lVw6-3K3-uMEKtk0AhrrVqLsFf3Bv6uTqI=.7e0fe633-ea86-4978-9a27-9513b5e583f9@github.com>

On Tue, 17 Jan 2023 17:24:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch optimizes Adler32 stub for AVX512 target.
> 
> Main computation loop now uses zero extended lane widening load vector operation.
> 
> New sequence also honors AVX3Thresholds so that implementation uses existing AVX2 instruction sequence on relevant targets
> if input size is smaller than threshold limit (default 4096).
> 
> Following are the result of an [existing JMH micro ](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestAdler32.java)on various targets.
> 
> **System Configurations : Turbo frequency scaling is disabled, all the data is collected at fixed frequency of 2.8 GHz.
> SUT1   : Intel? Xeon? Platinum 8480+ Processor (Sapphire Rapids)? 56C 2S
> SUT2   : Intel(R) Xeon(R) Platinum 8380 CPU (Icelake Server) 40C 2S
> SUT3   : Intel(R) Xeon(R) Platinum 8280 CPU (Cascadelake Server) 28C 2S**
> 
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934730-68717a61-191f-4dba-8c83-2eddf6007a47.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212934945-cada95ad-c93c-487f-bacc-928a2e3b5c21.png)
> 
> ![image](https://user-images.githubusercontent.com/59989778/212935059-511aca3b-c736-40a2-bff6-89caf0664828.png)
> 
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

test/micro/org/openjdk/bench/java/util/TestAdler32.java line 39:

> 37:     private byte[] bytes;
> 38: 
> 39:     @Param({"64", "128", "256", "512", "1024",  "2048", "5012", "8192", "16384", "32768", "65536"})

nit:
Suggestion:

    @Param({"64", "128", "256", "512", "1024", "2048", "5012", "8192", "16384", "32768", "65536"})

-------------

PR: https://git.openjdk.org/jdk/pull/12045

From redestad at openjdk.org  Sat Jan 21 11:53:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 21 Jan 2023 11:53:02 GMT
Subject: RFR: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder [v2]
In-Reply-To: <SjOTACcmFHekHFtO_0BhyP750WypfJ4gncQq1nKYIfw=.17926940-d9bc-435b-8ed9-b6599af83517@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
 <iGhC2WYtZkfCY9nF42qr13RRJH14sQOiXq9sjFbS114=.aaf4005b-f4c6-45bc-9e62-3713f876f3d4@github.com>
 <SjOTACcmFHekHFtO_0BhyP750WypfJ4gncQq1nKYIfw=.17926940-d9bc-435b-8ed9-b6599af83517@github.com>
Message-ID: <y4JOzbXy0YFtKZZ-rAKQDwSuwWPs0TDZ3mS2Zx9DYCk=.a396d8f9-eb99-4611-bc4a-e10f0604c2ba@github.com>

On Fri, 20 Jan 2023 16:42:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Vary dir and entry name lengths across a wider spread, keeping most entries short but making the longest paths longer
>
> Thank you Claes

Thanks @LanceAndersen and @AlanBateman for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From redestad at openjdk.org  Sat Jan 21 12:03:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 21 Jan 2023 12:03:12 GMT
Subject: Integrated: 8300493: Use ArraysSupport.vectorizedHashCode in
 j.u.zip.ZipCoder
In-Reply-To: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
References: <9j6QqB9rpu2xNHY1DwfCH-8UnxwRExgROAn0EidBzAY=.b4b611b7-e94a-4299-83a0-f99ee52b5484@github.com>
Message-ID: <qZQ5yohRsZqQZNLJBgvUkrWVw5RBQmB_XRFK91eddzw=.4ba0e7a8-19f9-424a-81bb-1e55e61e1ab3@github.com>

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
> 
> Before:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ? 1446.716  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ? 2166.673  ns/op
> 
> After:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ?  814.449  ns/op
> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ? 2744.017  ns/op

This pull request has now been integrated.

Changeset: bb42e61a
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb42e61a6176a7f4f9485efa47a248b23b09a16d
Stats:     120 lines in 4 files changed: 103 ins; 8 del; 9 mod

8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12077

From darcy at openjdk.org  Sat Jan 21 18:05:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 21 Jan 2023 18:05:07 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v5]
In-Reply-To: <fxjPA-fVYKAii7y0URfasC8sY64FmOWhMX19TlYLmJg=.9fb7b842-15a5-4427-9aac-b696af27cc2b@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <fxjPA-fVYKAii7y0URfasC8sY64FmOWhMX19TlYLmJg=.9fb7b842-15a5-4427-9aac-b696af27cc2b@github.com>
Message-ID: <gmTJYukM0S-mmAj9soyh8mdzcBKIZdKdyBhZGKFVLCM=.05c33ca8-08bc-4d45-9e1a-3068e59b8c68@github.com>

On Sat, 21 Jan 2023 08:26:31 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @implSpec added

src/java.base/share/classes/java/util/Collections.java line 464:

> 462:      * position, inclusive.<p>
> 463:      *
> 464:      * @implSpec This method runs in linear time.  If the specified list does 

Please also convert the corresponding paragraph in the
shuffle(List<?> list)
method to be an implSpec tag.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Jan 21 18:31:28 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 18:31:28 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:

 - Whitespaces fixed
 - @implSpec added to shuffle(List)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10520/files
  - new: https://git.openjdk.org/jdk/pull/10520/files/a465bd79..37a8c9f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Jan 21 18:31:32 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 18:31:32 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v5]
In-Reply-To: <gmTJYukM0S-mmAj9soyh8mdzcBKIZdKdyBhZGKFVLCM=.05c33ca8-08bc-4d45-9e1a-3068e59b8c68@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <fxjPA-fVYKAii7y0URfasC8sY64FmOWhMX19TlYLmJg=.9fb7b842-15a5-4427-9aac-b696af27cc2b@github.com>
 <gmTJYukM0S-mmAj9soyh8mdzcBKIZdKdyBhZGKFVLCM=.05c33ca8-08bc-4d45-9e1a-3068e59b8c68@github.com>
Message-ID: <TvHHADz3hnsPK3DH73AxODpu1l2X6sbB56nbOWcURWM=.7fef5e3d-6331-4910-83b0-26b77d1d1896@github.com>

On Sat, 21 Jan 2023 18:02:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @implSpec added
>
> src/java.base/share/classes/java/util/Collections.java line 464:
> 
>> 462:      * position, inclusive.<p>
>> 463:      *
>> 464:      * @implSpec This method runs in linear time.  If the specified list does 
> 
> Please also convert the corresponding paragraph in the
> shuffle(List<?> list)
> method to be an implSpec tag.

@jddarcy sure. Should I mention this in CSR?

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Jan 21 18:31:32 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 18:31:32 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v5]
In-Reply-To: <TvHHADz3hnsPK3DH73AxODpu1l2X6sbB56nbOWcURWM=.7fef5e3d-6331-4910-83b0-26b77d1d1896@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <fxjPA-fVYKAii7y0URfasC8sY64FmOWhMX19TlYLmJg=.9fb7b842-15a5-4427-9aac-b696af27cc2b@github.com>
 <gmTJYukM0S-mmAj9soyh8mdzcBKIZdKdyBhZGKFVLCM=.05c33ca8-08bc-4d45-9e1a-3068e59b8c68@github.com>
 <TvHHADz3hnsPK3DH73AxODpu1l2X6sbB56nbOWcURWM=.7fef5e3d-6331-4910-83b0-26b77d1d1896@github.com>
Message-ID: <dWBS40EU2zJhnDMI_EwSMuRKqMDt2xxMY86lnuE1E0A=.b9ddda37-4630-42af-b566-2476b834dd6e@github.com>

On Sat, 21 Jan 2023 18:24:24 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Collections.java line 464:
>> 
>>> 462:      * position, inclusive.<p>
>>> 463:      *
>>> 464:      * @implSpec This method runs in linear time.  If the specified list does 
>> 
>> Please also convert the corresponding paragraph in the
>> shuffle(List<?> list)
>> method to be an implSpec tag.
>
> @jddarcy sure. Should I mention this in CSR?

Ah, I see that you already updated it. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From darcy at openjdk.org  Sat Jan 21 18:35:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 21 Jan 2023 18:35:05 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
Message-ID: <QuVrYmJYdBzFZKV8gI5CRwRwkrpuLElkBOPns7UfjPg=.c46826da-f3d2-4a42-bd40-9e9ab501822d@github.com>

On Sat, 21 Jan 2023 18:31:28 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespaces fixed
>  - @implSpec added to shuffle(List)

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From serb at openjdk.org  Sat Jan 21 19:35:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 19:35:12 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
Message-ID: <YIhkkve0jHcpMS3lC5cg_w1w4XrjBApoWJrR6dKweeQ=.a30e7d69-23ee-4c07-a5a2-461b7856fd4e@github.com>

On Sat, 21 Jan 2023 18:31:28 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespaces fixed
>  - @implSpec added to shuffle(List)

Looks like nobody caught that the build tasks in GActions were broken=(

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From serb at openjdk.org  Sat Jan 21 19:35:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 19:35:14 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v4]
In-Reply-To: <uUWhRK9Y8Hx-pwUY1P2tdLWnJsBcf59CzBtk5WKhwak=.8602f56e-534d-41b8-ad91-e40698b59f16@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <0jefTXilKVR5Toi-qz6octBW7hAg0MnSMAg4APp8eVc=.2afc3c36-e4f0-4159-a02d-76e791099b53@github.com>
 <uUWhRK9Y8Hx-pwUY1P2tdLWnJsBcf59CzBtk5WKhwak=.8602f56e-534d-41b8-ad91-e40698b59f16@github.com>
Message-ID: <ETMqH-TUNC3jCEmZ9OgFTr4VVRlF975g95OLmlv3WDY=.7f27427f-95e1-4a31-9b98-1ee93e106fb2@github.com>

On Wed, 18 Jan 2023 22:06:55 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Copyright year and @since tag updated
>>  - Fixes according to review
>>    
>>    1. Reduce duplication in tests
>>    2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>>    3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>>  - Remove Random -> ThreadLocalRandom change
>>  - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface
>
> Hm... is something still missing?

@amaembo please fix that

 === Output from failing command(s) repeated here ===
* For target jdk_modules_java.base__the.java.base_batch:

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Jan 21 19:35:16 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 19:35:16 GMT
Subject: Integrated: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <pgEB7JnRowEuf4XgA7I7RbnnQC9yAPvst4S_QDTJ0d8=.f8042e5a-a3c2-421c-80b0-57a71c3ab2b3@github.com>

On Sat, 1 Oct 2022 08:06:44 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

This pull request has now been integrated.

Changeset: 67b1c890
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67b1c890b3351c1b1317477dd12316d18c01dd72
Stats:     105 lines in 2 files changed: 99 ins; 0 del; 6 mod

8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

Reviewed-by: smarks, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From serb at openjdk.org  Sat Jan 21 19:41:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 19:41:12 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
Message-ID: <URNhRJzEfLkjLmHdttaz_ZfmiludY7yPV5EuOrlxe0w=.c472bff9-b9f1-4a39-be25-1fc654d9b0d1@github.com>

On Sat, 21 Jan 2023 18:31:28 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespaces fixed
>  - @implSpec added to shuffle(List)

Filed, will create a PR soon.
https://bugs.openjdk.org/browse/JDK-8300817

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From serb at openjdk.org  Sat Jan 21 20:02:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 20:02:36 GMT
Subject: RFR: 8300817: The build is broken after JDK-8294693
Message-ID: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>

The next warning is fixed:

 === Output from failing command(s) repeated here ===
* For target jdk_modules_java.base__the.java.base_batch:

-------------

Commit messages:
 - The build is broken after JDK-8294693

Changes: https://git.openjdk.org/jdk/pull/12129/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300817
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12129.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12129/head:pull/12129

PR: https://git.openjdk.org/jdk/pull/12129

From tvaleev at openjdk.org  Sat Jan 21 20:18:13 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 20:18:13 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <URNhRJzEfLkjLmHdttaz_ZfmiludY7yPV5EuOrlxe0w=.c472bff9-b9f1-4a39-be25-1fc654d9b0d1@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
 <URNhRJzEfLkjLmHdttaz_ZfmiludY7yPV5EuOrlxe0w=.c472bff9-b9f1-4a39-be25-1fc654d9b0d1@github.com>
Message-ID: <_Wr5g6L-iwH3NlJJCziCpxpW4CZWfNKgfP2r5K5EjjY=.e31829a1-0011-426a-bcf1-c55c9af47514@github.com>

On Sat, 21 Jan 2023 19:38:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Whitespaces fixed
>>  - @implSpec added to shuffle(List)
>
> Filed, will create a PR soon.
> https://bugs.openjdk.org/browse/JDK-8300817

@mrserb Oops, sorry, was too eager to integrate :( I see your PR. No action from my side is required, right?

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Jan 21 20:24:02 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 21 Jan 2023 20:24:02 GMT
Subject: RFR: 8300817: The build is broken after JDK-8294693
In-Reply-To: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
References: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
Message-ID: <dsOdGrhJgJWd_Kv76Dhoeh5ZGeDlQ9CwY00fnogzL8c=.28ed4a77-b4b9-4edc-9f6e-91e01baf3542@github.com>

On Sat, 21 Jan 2023 19:40:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The next warning is fixed:
> 
>  === Output from failing command(s) repeated here ===
> * For target jdk_modules_java.base__the.java.base_batch:

Marked as reviewed by tvaleev (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12129

From darcy at openjdk.org  Sat Jan 21 20:24:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 21 Jan 2023 20:24:03 GMT
Subject: RFR: 8300817: The build is broken after JDK-8294693
In-Reply-To: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
References: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
Message-ID: <UYrKT-QeJbqjOhwZRmc6dyKjP_HYZKU7Ttq1B_4-0Ao=.2c7384e2-c8bf-451d-97c7-ed5b99955159@github.com>

On Sat, 21 Jan 2023 19:40:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The next warning is fixed:
> 
>  === Output from failing command(s) repeated here ===
> * For target jdk_modules_java.base__the.java.base_batch:

Thanks for the quick fix.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12129

From stsypanov at openjdk.org  Sat Jan 21 21:20:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sat, 21 Jan 2023 21:20:49 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
Message-ID: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>

Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:

DateTimeFormatter dtf = new DateTimeFormatterBuilder()
  .appendLiteral("Date:")
  .padNext(20, ' ')
  .append(DateTimeFormatter.ISO_DATE)
  .toFormatter();
String text = dtf.format(LocalDateTime.now());

-------------

Commit messages:
 - Improve padding of DateTimeFormatter

Changes: https://git.openjdk.org/jdk/pull/12131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300818
  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From serb at openjdk.org  Sat Jan 21 22:00:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Jan 2023 22:00:09 GMT
Subject: Integrated: 8300817: The build is broken after JDK-8294693
In-Reply-To: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
References: <q1Xx9dmxmBBWRf4yXYm2BZrY3mQDS7IrvGTgzFw10_A=.c66b6950-1a52-4d2f-8ba9-3fe60c2089e5@github.com>
Message-ID: <Gkqp8ki9I-LFS0KoAlX9mgDcIncCQtfytEQjrNvfWx8=.6b2381c4-5599-45fe-b08b-3815869396c5@github.com>

On Sat, 21 Jan 2023 19:40:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The next warning is fixed:
> 
>  === Output from failing command(s) repeated here ===
> * For target jdk_modules_java.base__the.java.base_batch:

This pull request has now been integrated.

Changeset: 3ea4eac1
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ea4eac1450954db095ef56385baa3aceea524ea
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8300817: The build is broken after JDK-8294693

Reviewed-by: tvaleev, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12129

From stsypanov at openjdk.org  Sun Jan 22 09:50:21 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 22 Jan 2023 09:50:21 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov 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 two additional commits since the last revision:

 - Merge branch 'master' into dtfb
 - Improve padding of DateTimeFormatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/b2160f8c..322ae9b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12131&range=00-01

  Stats: 95 lines in 17 files changed: 34 ins; 0 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12131/head:pull/12131

PR: https://git.openjdk.org/jdk/pull/12131

From redestad at openjdk.org  Sun Jan 22 11:40:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 22 Jan 2023 11:40:04 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
Message-ID: <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>

On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into dtfb
>  - Improve padding of DateTimeFormatter

Changes requested by redestad (Reviewer).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2603:

> 2601:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
> 2602:             int preLen = buf.length();
> 2603:             if (!printerParser.format(context, buf)) {

Non-standard as it may be, this style of using `expr == false` instead of `!expr` is a style choice by the original author. I would advice against changing these piecemeal without discussion and agreement that we should consistently enforce the `!expr` style.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2611:

> 2609:                     "Cannot print as output of " + len + " characters exceeds pad width of " + padWidth);
> 2610:             }
> 2611:             buf.insert(preLen, String.valueOf(padChar).repeat(padWidth - len));

Have you checked with a microbenchmark that this added allocation can be elided by JITs and that there's a significant speed-up with your changes? I don't have the necessary domain expertise to assert anything here but I suspect padding widths are typically short. Such as 2 or 4 (for day/month and year fields) so a micro should examine there's no regression for little to no padding. Unlike the original code you call `insert` even if `padWidth - len == 0`. This might be optimized away by JITs, but it'd be good to verify which is best.

-------------

PR: https://git.openjdk.org/jdk/pull/12131

From rgiulietti at openjdk.org  Sun Jan 22 12:54:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 22 Jan 2023 12:54:09 GMT
Subject: Integrated: 8300207: Add a pre-check for the number of canonical
 equivalent permutations in j.u.r.Pattern
In-Reply-To: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
References: <TI6hpgb9Q2M5RAQsgjM3g6UHa_mm8fDNfJTd-EPYGaw=.51fe4346-4e5d-4196-9071-be3dcbb6f197@github.com>
Message-ID: <XP9T7RtqvaEdjjeCp8FEbFKaKguMKwKWstCl-r2I7zA=.fed0820b-ae4c-4f3f-b657-c2f0056d8920@github.com>

On Tue, 17 Jan 2023 09:44:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> - Strengthen a computation that could overflow.
> - Specify that use of CANON_EQ could exhaust memory in the compilation phase.

This pull request has now been integrated.

Changeset: 030b071d
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/030b071db1fb6197a2633a04b20aa95432a903bc
Stats:     37 lines in 1 file changed: 31 ins; 0 del; 6 mod

8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/12027

From duke at openjdk.org  Sun Jan 22 13:09:37 2023
From: duke at openjdk.org (fabioromano1)
Date: Sun, 22 Jan 2023 13:09:37 GMT
Subject: RFR: 8300487: Store cardinality as a field in BitSet [v7]
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <KdFjOFFG1NpntX8EKjSSaovAmz9VZE-rI77bALiciVg=.bfcc73b3-3f50-4aca-9d67-eb84ac030fe3@github.com>

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added tests for NaturalsBitSet class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11837/files
  - new: https://git.openjdk.org/jdk/pull/11837/files/0c3e7cdf..9d9fb06c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11837&range=05-06

  Stats: 1549 lines in 10 files changed: 1438 ins; 57 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/11837.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11837/head:pull/11837

PR: https://git.openjdk.org/jdk/pull/11837

From duke at openjdk.org  Sun Jan 22 13:09:37 2023
From: duke at openjdk.org (fabioromano1)
Date: Sun, 22 Jan 2023 13:09:37 GMT
Subject: Withdrawn: 8300487: Store cardinality as a field in BitSet
In-Reply-To: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
References: <7AmnsCxynjyE90gDEGULkKG0UQfapb31N91B-f9bHYo=.fe48f954-8697-468c-83ac-818118438d0c@github.com>
Message-ID: <dv7t2wWgHiyIdDMw8dIuKmmvce3LhCvc-yNrNApBbTs=.f75804fe-3835-4713-bbdc-7aae1ec90df8@github.com>

On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11837

From stsypanov at openjdk.org  Sun Jan 22 13:10:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 22 Jan 2023 13:10:06 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
Message-ID: <Yo9JKXzjlzfxSnmkpLUFnjWzV6jnee0cogQ9YeLjBoM=.2d84ec9b-669f-471f-96db-5602039d2fb6@github.com>

On Sun, 22 Jan 2023 10:56:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sergey Tsypanov 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2603:
> 
>> 2601:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
>> 2602:             int preLen = buf.length();
>> 2603:             if (!printerParser.format(context, buf)) {
> 
> Non-standard as it may be, this style of using `expr == false` instead of `!expr` is a style choice by the original author. I would advice against changing these piecemeal without discussion and agreement that we should consistently enforce the `!expr` style.

Sure, I'll revert it

-------------

PR: https://git.openjdk.org/jdk/pull/12131

From fabio19298 at gmail.com  Sun Jan 22 13:20:46 2023
From: fabio19298 at gmail.com (Fabio Romano)
Date: Sun, 22 Jan 2023 14:20:46 +0100
Subject: New subclass of BitSet "NaturalsBitSet" to store cardinality in a
 field
Message-ID: <CAEuo5R7T-d87maRNoVKOZ+qwmVnmeV0TYp3wTbb8CkA5V7dgOQ@mail.gmail.com>

This enanchment is useful for applications that make heavy use of BitSet
objects as sets of integers, and therefore they need to make a lot of calls
to cardinality() method, which in BitSet class require linear time in the
number of words in use by the bit set.
This optimization reduces the cost of calling cardinality() to constant
time, as it simply returns the value of the field, and it also try to make
as little effort as possible to update the field, when needed.

Link to the Pull Request: https://github.com/openjdk/jdk/pull/12133
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230122/3a096662/attachment.htm>

From stsypanov at openjdk.org  Sun Jan 22 13:31:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 22 Jan 2023 13:31:05 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
Message-ID: <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>

On Sun, 22 Jan 2023 11:36:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sergey Tsypanov 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2611:
> 
>> 2609:                     "Cannot print as output of " + len + " characters exceeds pad width of " + padWidth);
>> 2610:             }
>> 2611:             buf.insert(preLen, String.valueOf(padChar).repeat(padWidth - len));
> 
> Have you checked with a microbenchmark that this added allocation can be elided by JITs and that there's a significant speed-up with your changes? I don't have the necessary domain expertise to assert anything here but I suspect padding widths are typically short. Such as 2 or 4 (for day/month and year fields) so a micro should examine there's no regression for little to no padding. Unlike the original code you call `insert` even if `padWidth - len == 0`. This might be optimized away by JITs, but it'd be good to verify which is best.

The modified code is called only when a user explicitly calls `padNext(int, char)`, i.e. if I modified the example snippet as

DateTimeFormatter dtf = new DateTimeFormatterBuilder()
  .appendLiteral("Date:")
//.padNext(20, ' ')
  .append(DateTimeFormatter.ISO_DATE)
  .toFormatter();
String text = dtf.format(LocalDateTime.now());

there's no regression.

Right now I cannot build ad-hoc JDK with my changes and check it with JMH, so I'd convert this to draft until I can verify it

-------------

PR: https://git.openjdk.org/jdk/pull/12131

From attila at openjdk.org  Sun Jan 22 15:17:06 2023
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 22 Jan 2023 15:17:06 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap [v2]
In-Reply-To: <r07Yd3aYRKApMnk68W58Ck77FyMMvztPy0xbr9mVgjQ=.f2826176-6a41-488c-a732-a84ef8c1c0ad@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
 <r07Yd3aYRKApMnk68W58Ck77FyMMvztPy0xbr9mVgjQ=.f2826176-6a41-488c-a732-a84ef8c1c0ad@github.com>
Message-ID: <dqNMd2kKFcQkzbzxYD1zO8DKLI_kWYFUommJeltc3Vk=.e3afe402-0281-4a30-b3e3-3c9bd965bb58@github.com>

On Thu, 12 Jan 2023 09:28:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
>> 
>> * Add `@Serial` annotations 
>> * Seal classes and restrict subclassing for internal classes 
>> * Use pattern matching for instance 
>> * Remove redundant modifiers (such as some final declarations) 
>> * Use Objects.requireNonNull for invariant checking 
>> * Use diamond operators instead of explicit types 
>> * Simplify expressions using Math::max
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @Override annotations

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 995:

> 993:         Node<K,V>[] t;
> 994:         if ((t = table) != null) {
> 995:             Traverser<K,V> it = new Traverser<>(t, t.length, 0, t.length);

Using diamond is one way to modernize this code, using `var` would be another, even more concise way. Consider: 
Suggestion:

            var it = new Traverser<K, V>(t, t.length, 0, t.length);

I don't support blindly using `var` everywhere, but I believe when the RHS of the assignment spells out the type that's exactly the kind of usage envisioned for it.

-------------

PR: https://git.openjdk.org/jdk/pull/11924

From attila at openjdk.org  Sun Jan 22 15:23:03 2023
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 22 Jan 2023 15:23:03 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
Message-ID: <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>

On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>        Modifies ImmutableCollections.listCopy:
>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>    
>    Modifies Map.copyOf:
>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.

src/java.base/share/classes/java/util/ImmutableCollections.java line 174:

> 172:             return List.of();
> 173:         } else {
> 174:             return (List<E>)List.of(coll.toArray()); // implicit nullcheck of coll

The comment is no longer relevant here, as it now happens on line 171.

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From itakiguchi at openjdk.org  Sun Jan 22 15:34:37 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 22 Jan 2023 15:34:37 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected
 since jdk18
Message-ID: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>

On jdk17, following testcase works fine on Linux platform.

Testcase

$ cat cstest1.java
import java.nio.charset.*;

public class cstest1 {
  public static void main(String[] args) throws Exception {
    Charset cs = Charset.defaultCharset();
    System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
  }
}


$ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets


But it does not work as expected on jdk18 and jdk21b06

$ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
openjdk version "18.0.2.1" 2022-08-18
OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
UTF-8, class sun.nio.cs.UTF_8, module java.base
$ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
openjdk version "21-ea" 2023-09-19
OpenJDK Runtime Environment (build 21-ea+6-365)
OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
UTF-8, class sun.nio.cs.UTF_8, module java.base


Fixed result is as follows:

$ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
openjdk version "21-internal" 2023-09-19
OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
x-IBM943C

-------------

Commit messages:
 - -Dfile.encoding=Cp943C option does not work as expected since jdk18

Changes: https://git.openjdk.org/jdk/pull/12132/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300819
  Stats: 45 lines in 2 files changed: 44 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12132.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12132/head:pull/12132

PR: https://git.openjdk.org/jdk/pull/12132

From alanb at openjdk.org  Sun Jan 22 19:25:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Jan 2023 19:25:02 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18
In-Reply-To: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
Message-ID: <BGlCdBMsNAo2SlZjPyUcPBMBtwP7tdqbMDrqXWLLSvU=.fd5584ea-ee96-4c91-bd1c-05d079e7d660@github.com>

On Sun, 22 Jan 2023 09:18:37 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On jdk17, following testcase works fine on Linux platform.
> 
> Testcase
> 
> $ cat cstest1.java
> import java.nio.charset.*;
> 
> public class cstest1 {
>   public static void main(String[] args) throws Exception {
>     Charset cs = Charset.defaultCharset();
>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>   }
> }
> 
> 
> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "17.0.6" 2023-01-17
> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
> 
> 
> But it does not work as expected on jdk18 and jdk21b06
> 
> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "18.0.2.1" 2022-08-18
> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "21-ea" 2023-09-19
> OpenJDK Runtime Environment (build 21-ea+6-365)
> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> 
> 
> Fixed result is as follows:
> 
> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
> openjdk version "21-internal" 2023-09-19
> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
> x-IBM943C

I don't think this is the right thing to do.

In terms of setup, there wasn't a documented/supported way to change the default charset in JDK 17 or earlier. JDK 18 was the first release where it documented (via an implNote) that it is possible to start with -Dfile.encoding=COMPAT to derive the default charset from native.encoding (which in turns depends on the locale and charset of the underlying operating system).

The second point is that it is too fragile to assume that Charset.defaultCharset won't be called until after phase 2 of startup. For the system to be reliable, the default charset must be in java.base. The proposed test may work in some cases but it won't work in cases where there are command line options and Java code executed at startup that indirectly uses Charset.defaultCharset.

That said, the change does highlight an issue in StaticProperty.<clinit> where it calls Charset.defaultCharset(), which in turn will StaticProperty.FILE_ENCODING before that class is fully initialized. This is nothing to do with trying to run with -Dfile.encoding=Cp943C of course but this part of the initialization will need to be re-examined to avoid issues.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From dholmes at openjdk.org  Sun Jan 22 22:26:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 22 Jan 2023 22:26:03 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests [v2]
In-Reply-To: <26AmAOOjwZH20rQkIxJpXtt7OaFCrkj2dwgj3tMhKOM=.f4744a47-e80c-4286-891f-7fa690a66393@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
 <26AmAOOjwZH20rQkIxJpXtt7OaFCrkj2dwgj3tMhKOM=.f4744a47-e80c-4286-891f-7fa690a66393@github.com>
Message-ID: <-H88vtmvDF_fTu3jrRvvkBmvb5Ae-1gs_R95QO9eyt4=.012fa760-46a2-46c5-86aa-2cf8138186e6@github.com>

On Fri, 20 Jan 2023 17:45:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
>> 
>> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
>> 
>> 
>> Before:
>> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
>> 
>> After:
>> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the comment to @comment

Looks god. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12104

From itakiguchi at openjdk.org  Sun Jan 22 23:17:10 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 22 Jan 2023 23:17:10 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
Message-ID: <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>

> On jdk17, following testcase works fine on Linux platform.
> 
> Testcase
> 
> $ cat cstest1.java
> import java.nio.charset.*;
> 
> public class cstest1 {
>   public static void main(String[] args) throws Exception {
>     Charset cs = Charset.defaultCharset();
>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>   }
> }
> 
> 
> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "17.0.6" 2023-01-17
> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
> 
> 
> But it does not work as expected on jdk18 and jdk21b06
> 
> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "18.0.2.1" 2022-08-18
> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
> openjdk version "21-ea" 2023-09-19
> OpenJDK Runtime Environment (build 21-ea+6-365)
> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
> UTF-8, class sun.nio.cs.UTF_8, module java.base
> 
> 
> Fixed result is as follows:
> 
> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
> openjdk version "21-internal" 2023-09-19
> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
> x-IBM943C

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12132/files
  - new: https://git.openjdk.org/jdk/pull/12132/files/9e400d60..5e7db0e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12132&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12132&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12132.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12132/head:pull/12132

PR: https://git.openjdk.org/jdk/pull/12132

From itakiguchi at openjdk.org  Sun Jan 22 23:45:01 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 22 Jan 2023 23:45:01 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
Message-ID: <3z88vmjhI12gXAgDiqbw1jwQgxiO2EypjVLg_oHwI44=.660fd803-338f-4769-8e49-db20224c5912@github.com>

On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On jdk17, following testcase works fine on Linux platform.
>> 
>> Testcase
>> 
>> $ cat cstest1.java
>> import java.nio.charset.*;
>> 
>> public class cstest1 {
>>   public static void main(String[] args) throws Exception {
>>     Charset cs = Charset.defaultCharset();
>>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>>   }
>> }
>> 
>> 
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>> 
>> 
>> But it does not work as expected on jdk18 and jdk21b06
>> 
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> 
>> 
>> Fixed result is as follows:
>> 
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18

First, Sorry I forgot to change Copyright date.

@AlanBateman , I appreciate your reply.
In my understanding,

- io stream side can use native.encoding system property.
- Now file.encoding system property is used for non-io stream.

This issue is related #11908 .
I need a solution to use the Cp943C charset as default charset.
Please give me some suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From ecki at zusammenkunft.net  Sun Jan 22 23:57:44 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 23 Jan 2023 00:57:44 +0100
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <3z88vmjhI12gXAgDiqbw1jwQgxiO2EypjVLg_oHwI44=.660fd803-338f-4769-8e49-db20224c5912@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>,
 <3z88vmjhI12gXAgDiqbw1jwQgxiO2EypjVLg_oHwI44=.660fd803-338f-4769-8e49-db20224c5912@github.com>
Message-ID: <E0FD4F08-E617-1D4F-86D0-DD974AE9BCA0@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230123/e98c3cf8/attachment.htm>

From duke at openjdk.org  Mon Jan 23 02:55:35 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 02:55:35 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException
Message-ID: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>

Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

-------------

Commit messages:
 - Modify Arrays.java

Changes: https://git.openjdk.org/jdk/pull/12135/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296935
  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From dholmes at openjdk.org  Mon Jan 23 03:24:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 03:24:47 GMT
Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC
Message-ID: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>

There was one missing update in javac.1 from:

[JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac

otherwise the change is limited to dropping the "-ea".

Thanks.

-------------

Commit messages:
 - Merge branch 'master' into 8290919-manpages
 - 8290919: Update nroff pages in JDK 20 before RC

Changes: https://git.openjdk.org/jdk20/pull/112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290919
  Stats: 29 lines in 28 files changed: 1 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk20/pull/112.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/112/head:pull/112

PR: https://git.openjdk.org/jdk20/pull/112

From smarks at openjdk.org  Mon Jan 23 06:32:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 23 Jan 2023 06:32:06 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <TfCKQa1dgvWbeS4JIi76exOghqsb0vBNk5yApJ8vBkI=.a43771d0-2da7-437f-815e-169b7005063a@github.com>

On Mon, 23 Jan 2023 02:35:19 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

We don't want to change long-standing exception-throwing behavior for these cases. See my comments in [JDK-8296935](https://bugs.openjdk.org/browse/JDK-8296935).

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 06:56:16 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 06:56:16 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v2]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <0oIQNhjNZ82iJvbRhZdHMTyOQP9BRjNVNdGZVxh-Q8Y=.afdfb073-41fe-4a35-abb1-273360ee9945@github.com>

> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Restore the old behavior and document about ASE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/207ec9c8..a2ab0b36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=00-01

  Stats: 33 lines in 1 file changed: 22 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 07:04:21 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:04:21 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v3]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <4Uq-g7p3s5dHhpuvqBBt_MPYzjsOvBb-HmSdjXoYj4c=.57b43b88-ed49-4caf-8c17-3da1f1551ba5@github.com>

> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Update List.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/a2ab0b36..2abca62c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 07:04:22 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:04:22 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException
In-Reply-To: <TfCKQa1dgvWbeS4JIi76exOghqsb0vBNk5yApJ8vBkI=.a43771d0-2da7-437f-815e-169b7005063a@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <TfCKQa1dgvWbeS4JIi76exOghqsb0vBNk5yApJ8vBkI=.a43771d0-2da7-437f-815e-169b7005063a@github.com>
Message-ID: <6GyYDXt-0nhmkv4AOf36JvohMs6_2JWOZIpW9vepATw=.3cae1d0c-2bfe-4c0d-af9e-882784762453@github.com>

On Mon, 23 Jan 2023 06:29:47 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> We don't want to change long-standing exception-throwing behavior for these cases. See my comments in [JDK-8296935](https://bugs.openjdk.org/browse/JDK-8296935).

Understand that, so I restored the current behavior and documented about this.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 07:08:28 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:08:28 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v4]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <UnonF0DZ-3LVhR7Om3Ljncui3ljW-PiYOUpXAaH1tBo=.583ce2bf-3c43-40f3-9f75-bb40459da342@github.com>

> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/2abca62c..22c80631

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 07:12:20 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:12:20 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v5]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <NWoL1NJNcKG7E5mTTQRNp25ieNN_Fl4VDLnDLCY4Lxo=.963cf10f-789b-4ff2-9ccd-1ea6e371afe4@github.com>

> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a `ClassCastException` (as documented in `java.util.List`) when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Change `@apiNote` to `@implNote`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/22c80631..c4b32b88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From iris at openjdk.org  Mon Jan 23 07:18:06 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 23 Jan 2023 07:18:06 GMT
Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC
In-Reply-To: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
References: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
Message-ID: <zTbsPP6FQdxsnX2181x-9yetNohJa3OoX3624PuEaho=.2cbbf84d-5540-4004-bb83-6563eb2ce449@github.com>

On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There was one missing update in javac.1 from:
> 
> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac
> 
> otherwise the change is limited to dropping the "-ea".
> 
> Thanks.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/112

From duke at openjdk.org  Mon Jan 23 07:24:22 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:24:22 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v6]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <dCO58ubH5X1ymWKENIJrVVFzTQRWFD7JCSlhCcAMZ8Y=.e21c165d-ff10-442e-8f87-b945647ecd24@github.com>

> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with two additional commits since the last revision:

 - Restore List.java
 - Fix whitespace error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/c4b32b88..ed1be48a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From dholmes at openjdk.org  Mon Jan 23 07:24:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 07:24:22 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v6]
In-Reply-To: <dCO58ubH5X1ymWKENIJrVVFzTQRWFD7JCSlhCcAMZ8Y=.e21c165d-ff10-442e-8f87-b945647ecd24@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <dCO58ubH5X1ymWKENIJrVVFzTQRWFD7JCSlhCcAMZ8Y=.e21c165d-ff10-442e-8f87-b945647ecd24@github.com>
Message-ID: <bRz43Tv_ey1criZ7IZXaRO7Nynez-TN91npdRAUs1Vg=.35a87144-fbf7-49ec-bb9d-29bebd7810ae@github.com>

On Mon, 23 Jan 2023 07:20:39 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore List.java
>  - Fix whitespace error

Changes requested by dholmes (Reviewer).

src/java.base/share/classes/java/util/Arrays.java line 4116:

> 4114:      *
> 4115:      * @implNote
> 4116:      * Modification methods of the returned list (such as {@link List#set} and

(This got buried in a commit specific message that got lost with the updates.)

My personal preference would be to call out explicitly what happens here:

@implNote
The  {@link List} implementation returned by this method does not conform to the 
specification for List.replaceAll and List.set, in that in the event of encountering an
element of an unsuitable type, ArrayStoreException will be thrown instead of 
ClassCastException.

(with suitable formatting of course). I don't think an example is necessary.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From dholmes at openjdk.org  Mon Jan 23 07:24:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 07:24:27 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v4]
In-Reply-To: <UnonF0DZ-3LVhR7Om3Ljncui3ljW-PiYOUpXAaH1tBo=.583ce2bf-3c43-40f3-9f75-bb40459da342@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <UnonF0DZ-3LVhR7Om3Ljncui3ljW-PiYOUpXAaH1tBo=.583ce2bf-3c43-40f3-9f75-bb40459da342@github.com>
Message-ID: <4BnKGoj4JaTHFtHiAzrjpqvk6_2Sj_HyYQmkLGUVEqo=.0edadfb7-d9a6-44c3-813e-c365b10301ad@github.com>

On Mon, 23 Jan 2023 07:08:28 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error

src/java.base/share/classes/java/util/Arrays.java line 4184:

> 4182:          *
> 4183:          * @throws ArrayStoreException if {@code element} cannot be stored into the array.
> 4184:          */

No javadoc is ever produced for this internal  implementation class, so doc comments here are not needed IMO.

src/java.base/share/classes/java/util/List.java line 591:

> 589:      * @throws ArrayStoreException if this list is backed by an array and
> 590:      *         the class of the specified element prevents it from being 
> 591:      *         stored to the array

This change to the List specification is not warranted or wanted.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Mon Jan 23 07:33:21 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 23 Jan 2023 07:33:21 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v7]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <ZZurFel-Py9rfobJ9aOTKXiN91B7h72kQMFoZWTPvU0=.930c0c30-a314-4992-805b-95237333defd@github.com>

> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Update `implSpec` and remove the docs of the impl.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/ed1be48a..ae050ecc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=05-06

  Stats: 20 lines in 1 file changed: 0 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From alanb at openjdk.org  Mon Jan 23 07:35:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 07:35:07 GMT
Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC
In-Reply-To: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
References: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
Message-ID: <CcuKhKwN8fhfI6JUo2ZNpUhSE3fYU_MvLJPwlQC_RVU=.857d1c1c-5eab-4227-9d82-e336b453b5bc@github.com>

On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There was one missing update in javac.1 from:
> 
> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac
> 
> otherwise the change is limited to dropping the "-ea".
> 
> Thanks.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/112

From dholmes at openjdk.org  Mon Jan 23 07:39:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 07:39:08 GMT
Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC
In-Reply-To: <zTbsPP6FQdxsnX2181x-9yetNohJa3OoX3624PuEaho=.2cbbf84d-5540-4004-bb83-6563eb2ce449@github.com>
References: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
 <zTbsPP6FQdxsnX2181x-9yetNohJa3OoX3624PuEaho=.2cbbf84d-5540-4004-bb83-6563eb2ce449@github.com>
Message-ID: <u1wD_gDb92UKvCJ1F7oeU5B_qheQnCLzhigA0xWrWT4=.e22a7ead-90a2-4067-a7b5-c2d3110d0168@github.com>

On Mon, 23 Jan 2023 07:15:08 GMT, Iris Clark <iris at openjdk.org> wrote:

>> There was one missing update in javac.1 from:
>> 
>> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac
>> 
>> otherwise the change is limited to dropping the "-ea".
>> 
>> Thanks.
>
> Marked as reviewed by iris (Reviewer).

Thanks for the reviews @irisclark  and @AlanBateman !

-------------

PR: https://git.openjdk.org/jdk20/pull/112

From alanb at openjdk.org  Mon Jan 23 07:51:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 07:51:05 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
Message-ID: <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>

On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On jdk17, following testcase works fine on Linux platform.
>> 
>> Testcase
>> 
>> $ cat cstest1.java
>> import java.nio.charset.*;
>> 
>> public class cstest1 {
>>   public static void main(String[] args) throws Exception {
>>     Charset cs = Charset.defaultCharset();
>>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>>   }
>> }
>> 
>> 
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>> 
>> 
>> But it does not work as expected on jdk18 and jdk21b06
>> 
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> 
>> 
>> Fixed result is as follows:
>> 
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18

I'm trying to understand what the real issue is. The java.base module on Linux builds includes SJIS, MS932, and PCK. Is there a Linux configuration in Japanese environments where the default charset in any JDK release is IBM943C? Same question for AIX builds that is the only build that includes IBM943C in java.base.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From dholmes at openjdk.org  Mon Jan 23 07:53:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 07:53:05 GMT
Subject: [jdk20] Integrated: 8290919: Update nroff pages in JDK 20 before RC
In-Reply-To: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
References: <SyU5zAE6E3mMET4AP63fG_w1UpddoQ4AgBIC2eWLeTk=.e225c518-64bc-4683-9a43-52e31ceaae79@github.com>
Message-ID: <KE_2Ova-N0oR1H4fRLDBGDGftIvFdJXnyuI0uIKIBgE=.ae8b19ec-0a7f-410c-a5ae-fb5967780360@github.com>

On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There was one missing update in javac.1 from:
> 
> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac
> 
> otherwise the change is limited to dropping the "-ea".
> 
> Thanks.

This pull request has now been integrated.

Changeset: fd752178
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/fd752178e364fb5deeec062bef3dde1fea1dcbe3
Stats:     29 lines in 28 files changed: 1 ins; 0 del; 28 mod

8290919: Update nroff pages in JDK 20 before RC

Reviewed-by: iris, alanb

-------------

PR: https://git.openjdk.org/jdk20/pull/112

From pminborg at openjdk.org  Mon Jan 23 07:59:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 07:59:05 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
In-Reply-To: <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
Message-ID: <anJvnMQqbN-kKRYFM4wcUmTvgtKS2QukoDEUqlZ6p5c=.fb5fc522-93e1-49d5-8256-84c8b642cf58@github.com>

On Fri, 20 Jan 2023 16:36:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`
>
> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package jdk.internal.util.access;
> 
> This is pretty deep; I'd drop the final "access". The package name `jdk.internal.util` is fine.

Happy to rename to `ByteArray` if we keep the package. The reason for proposing a separate package is that if we later decide to export the class, we are able to `export to` only this package and not all the other classes in `jdk.internal.util'. This could reduce coupling.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From alanb at openjdk.org  Mon Jan 23 08:11:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 08:11:06 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes
In-Reply-To: <anJvnMQqbN-kKRYFM4wcUmTvgtKS2QukoDEUqlZ6p5c=.fb5fc522-93e1-49d5-8256-84c8b642cf58@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
 <anJvnMQqbN-kKRYFM4wcUmTvgtKS2QukoDEUqlZ6p5c=.fb5fc522-93e1-49d5-8256-84c8b642cf58@github.com>
Message-ID: <FadxfT97JhTadbTeHms5atURCY66J8mqpvW3ZYPO4x8=.773d2075-1dbf-4230-984a-8455f6e11d39@github.com>

On Mon, 23 Jan 2023 07:56:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 26:
>> 
>>> 24:  */
>>> 25: 
>>> 26: package jdk.internal.util.access;
>> 
>> This is pretty deep; I'd drop the final "access". The package name `jdk.internal.util` is fine.
>
> Happy to rename to `ByteArray` if we keep the package. The reason for proposing a separate package is that if we later decide to export the class, we are able to `export to` only this package and not all the other classes in `jdk.internal.util'. This could reduce coupling.

"access" in the package/class name does look a bit strange, and could easily get mixed up with the package and classes that are used for shared secrets. I don't think jdk.internal.util.ByteArrays would look out of place. Hopefully it won't need to be exported to many other modules as we need to keep the qualified exports to a minimum.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 08:17:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 08:17:16 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v2]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <njrlaA0rhHOQ7nfgoZ445nWf_l_HMmH02ryKqzlD-F4=.59d25879-322e-4bd7-9cd8-060ff0b583fb@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve doc and fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/ce1d5765..f9280814

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=00-01

  Stats: 69 lines in 2 files changed: 0 ins; 37 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 08:17:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 08:17:18 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v2]
In-Reply-To: <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
Message-ID: <qGmlsHIZN4Ms5fwuuzOfbj7kJ3ZoQKkdyWuP-sLcbgk=.1530560b-ab7b-4de0-94c1-0b792a690298@github.com>

On Fri, 20 Jan 2023 18:21:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve doc and fix typo
>
> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 614:
> 
>> 612:     /*
>> 613:      * Methods for packing primitive values into byte arrays starting at offset zero.
>> 614:      */
> 
> Is the only advantage to the zero offset versions in the API, shorter invocations with fewer parameters? 
> Is there any performance difference?

Very good question. I will take a look at it. A fixed value is inserted in the original var handle so potentially it might improve performance that way too.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 08:48:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 08:48:35 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v3]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <Lpw5HMSr-VGJO9od_KyKCfhSNg08ZcstxY0AN7dEksE=.27c21c06-2991-4022-8c8a-34fd2cbb90ea@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename and move

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/f9280814..badf281d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=01-02

  Stats: 1038 lines in 9 files changed: 470 ins; 470 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 09:33:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 09:33:25 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v4]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <cAKvbh_hm33swtSzPiZfqcBkcWjWGKNedq0zS7sHp3I=.f4e55c9d-3029-492f-b294-0b57af3ab3cb@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/badf281d..3a3dc2e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=02-03

  Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From itakiguchi at openjdk.org  Mon Jan 23 09:47:09 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 23 Jan 2023 09:47:09 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
Message-ID: <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>

On Mon, 23 Jan 2023 07:48:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18
>
> I'm trying to understand what the real issue is. The java.base module on Linux builds includes SJIS, MS932, and PCK. Is there a Linux configuration in Japanese environments where the default charset in any JDK release is IBM943C? Same question for AIX builds that is the only build that includes IBM943C in java.base.

Hello @AlanBateman .
Sorry for your confusion.

Java8 works `-Dfile.encoding=Cp943C` option on Linux. Since many users are migrating from Java8, I'm getting similar requests from my clients. Cp943C is not supported by Linux natively, but some clients want to use same encoding with Linux and AIX.

Japanese AIX environment supports IBM-943(Cp943C)/IBM-eucJP(Cp29626C)/UTF-8 encoding.
Cp943C and Cp29626C are in base.base module on AIX platform.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From pminborg at openjdk.org  Mon Jan 23 10:19:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 10:19:11 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v4]
In-Reply-To: <qGmlsHIZN4Ms5fwuuzOfbj7kJ3ZoQKkdyWuP-sLcbgk=.1530560b-ab7b-4de0-94c1-0b792a690298@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
 <qGmlsHIZN4Ms5fwuuzOfbj7kJ3ZoQKkdyWuP-sLcbgk=.1530560b-ab7b-4de0-94c1-0b792a690298@github.com>
Message-ID: <zn9oSSsk0NbHNn4lD4YsdBzwmZ_PhM21qkkFDLW2uQA=.ee180b80-0e85-42f4-9a99-f861978a6e92@github.com>

On Mon, 23 Jan 2023 08:11:15 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/access/ByteArrayAccess.java line 614:
>> 
>>> 612:     /*
>>> 613:      * Methods for packing primitive values into byte arrays starting at offset zero.
>>> 614:      */
>> 
>> Is the only advantage to the zero offset versions in the API, shorter invocations with fewer parameters? 
>> Is there any performance difference?
>
> Very good question. I will take a look at it. A fixed value is inserted in the original var handle so potentially it might improve performance that way too.

No significant performance increase:


2-parameters
Benchmark                                             Mode  Cnt  Score   Error  Units
PrimitiveFieldSerializationBenchmark.serializeData    avgt    8  6.761 ? 0.126  ns/op
PrimitiveFieldSerializationBenchmark.serializeRecord  avgt    8  6.890 ? 0.093  ns/op

3-parameters
Benchmark                                             Mode  Cnt  Score   Error  Units
PrimitiveFieldSerializationBenchmark.serializeData    avgt    8  6.850 ? 0.074  ns/op
PrimitiveFieldSerializationBenchmark.serializeRecord  avgt    8  6.855 ? 0.057  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 11:25:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 11:25:06 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v4]
In-Reply-To: <zn9oSSsk0NbHNn4lD4YsdBzwmZ_PhM21qkkFDLW2uQA=.ee180b80-0e85-42f4-9a99-f861978a6e92@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <E1vQYMLfs-2sfuFenCAw7YqBRI8ZnXa_CdK7XsftqmI=.7265b5f6-1e3c-4082-b3f9-d74103a35476@github.com>
 <qGmlsHIZN4Ms5fwuuzOfbj7kJ3ZoQKkdyWuP-sLcbgk=.1530560b-ab7b-4de0-94c1-0b792a690298@github.com>
 <zn9oSSsk0NbHNn4lD4YsdBzwmZ_PhM21qkkFDLW2uQA=.ee180b80-0e85-42f4-9a99-f861978a6e92@github.com>
Message-ID: <0k7QdB6KY5rjuiWnVpgfV33F72A9HsW0KEp67hDuju8=.09100a01-2328-45ce-a0bd-11a6ae26ef00@github.com>

On Mon, 23 Jan 2023 10:15:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Very good question. I will take a look at it. A fixed value is inserted in the original var handle so potentially it might improve performance that way too.
>
> No significant performance increase:
> 
> 
> 2-parameters
> Benchmark                                             Mode  Cnt  Score   Error  Units
> PrimitiveFieldSerializationBenchmark.serializeData    avgt    8  6.761 ? 0.126  ns/op
> PrimitiveFieldSerializationBenchmark.serializeRecord  avgt    8  6.890 ? 0.093  ns/op
> 
> 3-parameters
> Benchmark                                             Mode  Cnt  Score   Error  Units
> PrimitiveFieldSerializationBenchmark.serializeData    avgt    8  6.850 ? 0.074  ns/op
> PrimitiveFieldSerializationBenchmark.serializeRecord  avgt    8  6.855 ? 0.057  ns/op

I will remove the extra methods with lesser parameters.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From redestad at openjdk.org  Mon Jan 23 11:37:05 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Jan 2023 11:37:05 GMT
Subject: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter
 [v2]
In-Reply-To: <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
Message-ID: <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>

On Sun, 22 Jan 2023 13:28:06 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2611:
>> 
>>> 2609:                     "Cannot print as output of " + len + " characters exceeds pad width of " + padWidth);
>>> 2610:             }
>>> 2611:             buf.insert(preLen, String.valueOf(padChar).repeat(padWidth - len));
>> 
>> Have you checked with a microbenchmark that this added allocation can be elided by JITs and that there's a significant speed-up with your changes? I don't have the necessary domain expertise to assert anything here but I suspect padding widths are typically short. Such as 2 or 4 (for day/month and year fields) so a micro should examine there's no regression for little to no padding. Unlike the original code you call `insert` even if `padWidth - len == 0`. This might be optimized away by JITs, but it'd be good to verify which is best.
>
> The modified code is called only when a user explicitly calls `padNext(int, char)`, i.e. if I modified the example snippet as
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
> //.padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());
> 
> there's no regression.
> 
> Right now I cannot build ad-hoc JDK with my changes and check it with JMH, so I'd convert this to draft until I can verify it

Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 

DateTimeFormatter dtf = new DateTimeFormatterBuilder()
    .appendLiteral("Year:")
    .padNext(5)
    .appendValue(ChronoField.YEAR)
    .toFormatter();
... 
dtf.format(LocalDateTime.now());

And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.

-------------

PR: https://git.openjdk.org/jdk/pull/12131

From redestad at openjdk.org  Mon Jan 23 12:02:11 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Jan 2023 12:02:11 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com>

On Sat, 21 Jan 2023 00:15:10 GMT, Scott Gibbons <duke at openjdk.org> wrote:

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:

> 2659:     __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
> 2660:     __ vmovdqu(xmm11, Address(r13, 0x28));
> 2661:     __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit);

Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From pminborg at openjdk.org  Mon Jan 23 12:38:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 12:38:24 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v5]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <XLtRK2Z7j8Q7V5ztAzK5lylNQszVecZdoaJmSchUCsg=.58840f35-dfba-4ed6-9481-d7e1eda30b7e@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove methods with implicit zero offset

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/3a3dc2e0..a13b3603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=03-04

  Stats: 333 lines in 3 files changed: 0 ins; 318 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Mon Jan 23 13:21:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 13:21:20 GMT
Subject: RFR: 8299513: Clean up java.io [v9]
In-Reply-To: <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
 <QHNr39cmleckupgwrL70NrrmXMj_6GaM4I_ObevTtlQ=.98cc3b2a-920d-42dc-a368-e67929d45193@github.com>
Message-ID: <Gjc1Z5a4iPn39cjfDT4AH06K3Q-2Y_ysXW6Ag8I_w4Q=.066f5f90-106c-4d65-b6e7-aa9047670e6f@github.com>

On Wed, 11 Jan 2023 15:31:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Code in java.io contains many legacy constructs and semantics not recommended including: 
>> 
>> * C-style array declaration 
>> * Unnecessary visibility 
>> * Redundant keywords in interfaces (e.g. public, static) 
>> * Non-standard naming for constants 
>> * Javadoc typos 
>> * Missing final declaration 
>> 
>> These should be fixed as a sanity effort.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert field to static and revert copyright year

I am closing this PR. I will create separate PRs for different classes of fixes.

-------------

PR: https://git.openjdk.org/jdk/pull/11848

From pminborg at openjdk.org  Mon Jan 23 13:21:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 13:21:22 GMT
Subject: Withdrawn: 8299513: Clean up java.io
In-Reply-To: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
References: <fwMW-2cGoeqzy96M4S2Hwxks4Z3zibbaNgy0GU5eZOk=.ee97db28-347a-4ca9-b845-1e3a6808acdc@github.com>
Message-ID: <Hgdj0jECO2-b6ENBLQDzoohKObzM9OUHCY3TavTmYjw=.883c9d8b-21c1-4b91-88df-173eb518c750@github.com>

On Wed, 4 Jan 2023 15:37:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Code in java.io contains many legacy constructs and semantics not recommended including: 
> 
> * C-style array declaration 
> * Unnecessary visibility 
> * Redundant keywords in interfaces (e.g. public, static) 
> * Non-standard naming for constants 
> * Javadoc typos 
> * Missing final declaration 
> 
> These should be fixed as a sanity effort.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11848

From alanb at openjdk.org  Mon Jan 23 13:49:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 13:49:05 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
Message-ID: <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>

On Mon, 23 Jan 2023 09:44:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Java8 works `-Dfile.encoding=Cp943C` option on Linux. Since many users are migrating from Java8, I'm getting similar requests from my clients. Cp943C is not supported by Linux natively, but some clients want to use same encoding with Linux and AIX.
> 
> Japanese AIX environment supports IBM-943(Cp943C)/IBM-eucJP(Cp29626C)/UTF-8 encoding. Cp943C and Cp29626C are in base.base module on AIX platform.

It's never been supported to run with -Dfile.encoding=Cp943C. It may have worked in JDK 8 but I doubt it could have worked consistently since JDK 9 because the default charset is derived before it's possible to locate charset implementations outside of java.base.

I think it would be useful to know a bit more about the environment. It sounds like it might be AIX -> Linux migration but I'm curious if you have any insight into why these applications depend on default charset being Cp943C. Is it text files that are opened without specifying the charset or is is something else?

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From duke at openjdk.org  Mon Jan 23 14:07:25 2023
From: duke at openjdk.org (duke)
Date: Mon, 23 Jan 2023 14:07:25 GMT
Subject: Withdrawn: JDK-8297688: libjli leaks memory related to options
 handling
In-Reply-To: <iDhWdZMAJn3nZyKseiTEAxFj-nT_BmuSGDagD6BsRO0=.93a837fd-ac89-4364-8f01-f0b58202f23d@github.com>
References: <iDhWdZMAJn3nZyKseiTEAxFj-nT_BmuSGDagD6BsRO0=.93a837fd-ac89-4364-8f01-f0b58202f23d@github.com>
Message-ID: <7nAGVq44tZHJVrHrWyfFrrggaTWYSJzZ6erGNPiroqI=.6193a5ec-3b12-4ae9-bc31-c55b1c61b979@github.com>

On Mon, 28 Nov 2022 03:23:01 GMT, Justin King <jcking at openjdk.org> wrote:

> Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11384

From pminborg at openjdk.org  Mon Jan 23 15:13:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:13:57 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
Message-ID: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>

Some variables are declared using old-style declarations. These should be modified to conform to modern style. 

This is a task derived from https://github.com/openjdk/jdk/pull/11848

-------------

Commit messages:
 - Fix more classes
 - Remove c-style declarations

Changes: https://git.openjdk.org/jdk/pull/12139/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300863
  Stats: 21 lines in 8 files changed: 1 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12139.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12139/head:pull/12139

PR: https://git.openjdk.org/jdk/pull/12139

From pminborg at openjdk.org  Mon Jan 23 15:14:12 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:14:12 GMT
Subject: RFR: 8300864: Declare some fields in java.io as final
Message-ID: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>

Some of the fields in java.io can be declared as final.

-------------

Commit messages:
 - Revert final class declaration
 - Declare fields final

Changes: https://git.openjdk.org/jdk/pull/12140/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300864
  Stats: 117 lines in 8 files changed: 5 ins; 5 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/12140.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12140/head:pull/12140

PR: https://git.openjdk.org/jdk/pull/12140

From pminborg at openjdk.org  Mon Jan 23 15:22:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:22:01 GMT
Subject: RFR: 8300866: Declare some classes final in java.io
Message-ID: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>

This PR proposes declaring some internal classes in java.io as `final`, explicitly indicating that they are not intended for sub-classing. 

If you think declaring classes final is just "static noice", please see http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html first and then come back and comment on the issue.

-------------

Commit messages:
 - Declare classes as final

Changes: https://git.openjdk.org/jdk/pull/12141/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300866
  Stats: 11 lines in 5 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12141.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12141/head:pull/12141

PR: https://git.openjdk.org/jdk/pull/12141

From pminborg at openjdk.org  Mon Jan 23 15:28:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:28:04 GMT
Subject: RFR: JDK-8300867: Fix document issues in java.io
Message-ID: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>

This PR fixes a couple of typos in the documentation.

-------------

Commit messages:
 - Update copyright year
 - Fix javadoc issues

Changes: https://git.openjdk.org/jdk/pull/12142/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300867
  Stats: 39 lines in 6 files changed: 0 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/12142.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12142/head:pull/12142

PR: https://git.openjdk.org/jdk/pull/12142

From pminborg at openjdk.org  Mon Jan 23 15:33:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:33:17 GMT
Subject: RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext
Message-ID: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>

This PR proposes to reduce the visibility for constructor and methods in `java.io.SerialCallbackContext`.

-------------

Commit messages:
 - Reduce visibility in j.i.SerialCallbackConext

Changes: https://git.openjdk.org/jdk/pull/12143/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300868
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12143/head:pull/12143

PR: https://git.openjdk.org/jdk/pull/12143

From pminborg at openjdk.org  Mon Jan 23 15:39:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 15:39:23 GMT
Subject: RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext
 [v2]
In-Reply-To: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>
References: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>
Message-ID: <33dsWBv5Z7V9OCxKTKsZjcbt_V-u6cbNfqN4sju8M7U=.e2b74814-7ab0-4b67-b241-83e46a7f5b3b@github.com>

> This PR proposes to reduce the visibility for constructor and methods in `java.io.SerialCallbackContext`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12143/files
  - new: https://git.openjdk.org/jdk/pull/12143/files/6136a891..7f807539

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12143&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12143.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12143/head:pull/12143

PR: https://git.openjdk.org/jdk/pull/12143

From rriggs at openjdk.org  Mon Jan 23 15:39:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Jan 2023 15:39:24 GMT
Subject: RFR: 8300868: Reduce visibility in java.io.SerialCallbackContext
 [v2]
In-Reply-To: <33dsWBv5Z7V9OCxKTKsZjcbt_V-u6cbNfqN4sju8M7U=.e2b74814-7ab0-4b67-b241-83e46a7f5b3b@github.com>
References: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>
 <33dsWBv5Z7V9OCxKTKsZjcbt_V-u6cbNfqN4sju8M7U=.e2b74814-7ab0-4b67-b241-83e46a7f5b3b@github.com>
Message-ID: <PNRlqDl4U_XChiN9SXY--xLi-_yp5a-c3Yby9gpcOv8=.945cb174-29d6-4ef5-bad9-07ea30aff4bb@github.com>

On Mon, 23 Jan 2023 15:36:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to reduce the visibility for constructor and methods in `java.io.SerialCallbackContext`.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Its a package private class, not really a significant change.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12143

From alanb at openjdk.org  Mon Jan 23 16:09:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 16:09:37 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <-rRvQtCSe-cMsTwP71v5kwRVc-ly6fLOu138WQsq-YY=.6105d088-ac9f-4cf4-90dc-bb4d6391d188@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12139

From alanb at openjdk.org  Mon Jan 23 16:10:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 16:10:42 GMT
Subject: RFR: JDK-8300867: Fix document issues in java.io
In-Reply-To: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
References: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
Message-ID: <LN2y1jCr9e_ew8feFsd_NdyjApGPfzMmpF6pM7FlFog=.a638e250-d16b-4fc4-8317-8daf9c85c4bb@github.com>

On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a couple of typos in the documentation.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12142

From rriggs at openjdk.org  Mon Jan 23 16:41:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Jan 2023 16:41:01 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <IWb625Ul2RyZXaWl34thDOGsWCiufKrW29y5OeBldMY=.867fbcfb-361c-450c-b60d-df025c2e14f7@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12139

From cwimmer at openjdk.org  Mon Jan 23 17:00:00 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 23 Jan 2023 17:00:00 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
Message-ID: <IJIJvSN7YQbx67aOTpokvRRvVGqsrP4DPeMsTI77f-w=.8a958f12-a975-4e57-afff-e5e81a5f0d5a@github.com>

On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

>> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
>> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.
>
> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about method inlining

Can I get reviews and hopefully an approval to merge for this PR please.

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From psandoz at openjdk.org  Mon Jan 23 17:06:06 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 23 Jan 2023 17:06:06 GMT
Subject: RFR: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests [v2]
In-Reply-To: <26AmAOOjwZH20rQkIxJpXtt7OaFCrkj2dwgj3tMhKOM=.f4744a47-e80c-4286-891f-7fa690a66393@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
 <26AmAOOjwZH20rQkIxJpXtt7OaFCrkj2dwgj3tMhKOM=.f4744a47-e80c-4286-891f-7fa690a66393@github.com>
Message-ID: <yShJW35XV5BRSsOjEwRv-_pjHNtr81IO3mE49ENvHGY=.03c16152-5f4c-42b4-9157-b02567c5c9f4@github.com>

On Fri, 20 Jan 2023 17:45:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
>> 
>> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
>> 
>> 
>> Before:
>> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
>> 
>> After:
>> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the comment to @comment

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12104

From rriggs at openjdk.org  Mon Jan 23 17:10:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Jan 2023 17:10:31 GMT
Subject: RFR: 8300864: Declare some fields in java.io as final
In-Reply-To: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
References: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
Message-ID: <WrhQsuIWWWRUNwHfPYfC_4wEWsb9N66SzBejyprDJ80=.f938ed15-5024-4ba5-8ba8-328cd4ed7a60@github.com>

On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the fields in java.io can be declared as final.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12140

From lancea at openjdk.org  Mon Jan 23 17:17:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Jan 2023 17:17:58 GMT
Subject: RFR: 8300864: Declare some fields in java.io as final
In-Reply-To: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
References: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
Message-ID: <Yv6BC9gZf09S1ljWnVLetTuBxc13c428BA9ZrUdWsNU=.24e33073-4f36-4065-a2ec-981a573cdbb7@github.com>

On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the fields in java.io can be declared as final.

The changes look reasonable to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12140

From lancea at openjdk.org  Mon Jan 23 17:27:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Jan 2023 17:27:12 GMT
Subject: RFR: JDK-8300867: Fix document issues in java.io
In-Reply-To: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
References: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
Message-ID: <0QWeIFkB8i_KqBcH3gZXhG6fffdRuT6pZuXpCGnGFWA=.16917b8d-98d8-441a-bfd1-f14007d1938d@github.com>

On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a couple of typos in the documentation.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12142

From iris at openjdk.org  Mon Jan 23 17:34:24 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 23 Jan 2023 17:34:24 GMT
Subject: RFR: JDK-8300867: Fix document issues in java.io
In-Reply-To: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
References: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
Message-ID: <OGrpKM6llPWLLXPzO_K0iiOnuLRxBcWJmAVOWyVlvsA=.ca4e7aeb-02ed-4b65-addf-987e4c810fc9@github.com>

On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a couple of typos in the documentation.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12142

From smarks at openjdk.org  Mon Jan 23 17:38:59 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 23 Jan 2023 17:38:59 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v6]
In-Reply-To: <URNhRJzEfLkjLmHdttaz_ZfmiludY7yPV5EuOrlxe0w=.c472bff9-b9f1-4a39-be25-1fc654d9b0d1@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <FAQJlPvAf5UWvVN6zRiqIuZ7cfhAnem7obGyBz8CAUo=.f5efb130-7ce7-4292-9866-434d4a7327b5@github.com>
 <URNhRJzEfLkjLmHdttaz_ZfmiludY7yPV5EuOrlxe0w=.c472bff9-b9f1-4a39-be25-1fc654d9b0d1@github.com>
Message-ID: <IpNwn3ZXomrBSGJkLeNxQpSlsYoOj9T-tahcs2vZ_EQ=.61188e87-c296-4a37-8500-d7621be645bb@github.com>

On Sat, 21 Jan 2023 19:38:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Whitespaces fixed
>>  - @implSpec added to shuffle(List)
>
> Filed, will create a PR soon.
> https://bugs.openjdk.org/browse/JDK-8300817

@mrserb Thanks for noticing this and for cleaning up.

Unfortunately the GitHub Actions are often broken spuriously, but this time it was a real issue. :-(

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From darcy at openjdk.org  Mon Jan 23 17:39:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Jan 2023 17:39:41 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <tqw4MGdIYnJ3rkXqtMXTjbWon2nXQ62TnuVnd9E1J90=.69db36f4-a856-427a-9e61-2d0576965f13@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

Nice cleanup.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12139

From pminborg at openjdk.org  Mon Jan 23 17:49:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 17:49:51 GMT
Subject: Integrated: 8300864: Declare some fields in java.io as final
In-Reply-To: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
References: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
Message-ID: <4njrkfyqCVpbUKQNigciAPjY8GKdZ_6B82JQec-0pUY=.e37018e4-1272-45a8-9299-88c0a89ec9e9@github.com>

On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the fields in java.io can be declared as final.

This pull request has now been integrated.

Changeset: 079255e3
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/079255e312a60584d748babcd320eacec99c5a02
Stats:     117 lines in 8 files changed: 5 ins; 5 del; 107 mod

8300864: Declare some fields in java.io as final

Reviewed-by: rriggs, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12140

From pminborg at openjdk.org  Mon Jan 23 17:55:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 17:55:45 GMT
Subject: Integrated: 8300868: Reduce visibility in
 java.io.SerialCallbackContext
In-Reply-To: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>
References: <rRktWcq6P_8yVee3sVYFthefHyVU4pQHhsz1-dHBwM8=.f0eff47d-2a0a-4f29-87b9-419fae817980@github.com>
Message-ID: <vl4pKI4OE-l67HF66tHLlRQK5OKNBlmWqavnyozLA2w=.66ccf84b-84f7-4af8-9593-249c0035866d@github.com>

On Mon, 23 Jan 2023 15:08:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to reduce the visibility for constructor and methods in `java.io.SerialCallbackContext`.

This pull request has now been integrated.

Changeset: a7f035db
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7f035db762ce44b72733094422488047c9ad738
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8300868: Reduce visibility in java.io.SerialCallbackContext

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12143

From pminborg at openjdk.org  Mon Jan 23 18:01:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 18:01:37 GMT
Subject: Integrated: JDK-8300867: Fix document issues in java.io
In-Reply-To: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
References: <H9WFIjCN7j1vTSrLetoQpPgr-MT7SzAMj-OPYNDHbvk=.43db837e-40f5-4a38-884c-976e9dfd4888@github.com>
Message-ID: <m0xWAyOzkk6fd9AKC40QCylnEwPe1e6RV0EKJ7qrJaM=.6df66a69-6227-47d2-a80a-42acf5959505@github.com>

On Mon, 23 Jan 2023 14:59:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a couple of typos in the documentation.

This pull request has now been integrated.

Changeset: 4525aa31
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4525aa318a1025e19d4ed9924ed25992be0075e9
Stats:     38 lines in 6 files changed: 0 ins; 0 del; 38 mod

8300867: Fix document issues in java.io

Reviewed-by: alanb, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/12142

From alanb at openjdk.org  Mon Jan 23 18:02:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 18:02:39 GMT
Subject: RFR: 8300864: Declare some fields in java.io as final
In-Reply-To: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
References: <-_58Tb3w10kBVcvx27bDqHqFm0znEZf_m66OPK4s65Y=.af94f3b4-bd97-4202-8e5d-97a8b765c60a@github.com>
Message-ID: <1EdtxXILgjfukIpwMybdXL6PejezL2JiIAbQ0siMAZs=.7ad30865-8683-4f93-bc40-a4d9ad7c1bc1@github.com>

On Mon, 23 Jan 2023 14:24:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the fields in java.io can be declared as final.

src/java.base/share/classes/java/io/File.java line 155:

> 153:      * The FileSystem object representing the platform's local file system.
> 154:      */
> 155:     private static final FileSystem FS = DefaultFileSystem.getFileSystem();

It's a pity to rename this one as FS.* is very ugly.

-------------

PR: https://git.openjdk.org/jdk/pull/12140

From alanb at openjdk.org  Mon Jan 23 18:05:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 18:05:36 GMT
Subject: RFR: 8300866: Declare some classes final in java.io
In-Reply-To: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
References: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
Message-ID: <7vnVXMD6NQxgtaUFlwIbV5HzUIQt-e6Fs_7-a-GfdVY=.e98d63ff-e30b-4228-8988-26f34c944fac@github.com>

On Mon, 23 Jan 2023 14:40:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring some internal classes in java.io as `final`, explicitly indicating that they are not intended for sub-classing. 
> 
> If you think declaring classes final is just "static noice", please see http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html first and then come back and comment on the issue.

Look okay. We should probably think about removing ExpiringCache as it hasn't been used for many releases.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12141

From mchung at openjdk.org  Mon Jan 23 18:07:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 23 Jan 2023 18:07:54 GMT
Subject: Integrated: 8300693: Lower the compile threshold and reduce the
 iterations of warmup loop in VarHandles tests
In-Reply-To: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
References: <Onbsmde0QGISr4DvaO1le7eQAk6fqG-bSa85pYATGsM=.8c5c6831-83f3-4ff4-be1e-291c0ec59c21@github.com>
Message-ID: <c3jRSpBgc3mTzCbux6HwKw2Ecj8MiNF8kq_806is0TI=.e1a1c617-02fb-46bc-85dd-72cfcdcb5bda@github.com>

On Thu, 19 Jan 2023 20:43:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `java/lang/invoke/VarHandles` tests run with C1, C2 and tiered compilations and the test cases are executed in the warm up loop with 20000 iterations to verify C1, C2 intrinsics.  Default Tier4CompileThreshold is 15000.
> 
> This PR proposes to scale the compile threshold to 0.1 such that the warm up loop can be reduced to 2000 iterations.  This will speed up the test execution time.
> 
> 
> Before:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  341.06s user 14.65s system 563% cpu 1:03.14 total
> 
> After:
> make test-only TEST=open/test/jdk/java/lang/invoke/VarHandles  234.38s user 13.08s system 535% cpu 46.218 total

This pull request has now been integrated.

Changeset: 86fed796
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86fed79670c109fc3a7fbe1eb2b1485c6dd99e2f
Stats:     202 lines in 27 files changed: 74 ins; 30 del; 98 mod

8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests

Reviewed-by: jvernee, dholmes, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/12104

From pminborg at openjdk.org  Mon Jan 23 18:08:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 18:08:54 GMT
Subject: RFR: 8300866: Declare some classes final in java.io
In-Reply-To: <7vnVXMD6NQxgtaUFlwIbV5HzUIQt-e6Fs_7-a-GfdVY=.e98d63ff-e30b-4228-8988-26f34c944fac@github.com>
References: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
 <7vnVXMD6NQxgtaUFlwIbV5HzUIQt-e6Fs_7-a-GfdVY=.e98d63ff-e30b-4228-8988-26f34c944fac@github.com>
Message-ID: <9WnbxcOxfWJ-uRyRKadJyRa2ouHWYnIHni1ByWXtry4=.b0241b40-8be2-451c-8881-6dcfb0afda78@github.com>

On Mon, 23 Jan 2023 18:02:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Look okay. We should probably think about removing ExpiringCache as it hasn't been used for many releases.

It looks like CE is used in `UnixFileSystem` via the system property "sun.io.useCanonCaches" ?

-------------

PR: https://git.openjdk.org/jdk/pull/12141

From iris at openjdk.org  Mon Jan 23 18:14:28 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 23 Jan 2023 18:14:28 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <jyhY_B_LWfZZesp0uOCD3BDf4Ceuh5WeL36uPg-iubw=.34ea1879-9afb-444c-b917-7400527acbd8@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12139

From alanb at openjdk.org  Mon Jan 23 18:16:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jan 2023 18:16:35 GMT
Subject: RFR: 8300866: Declare some classes final in java.io
In-Reply-To: <9WnbxcOxfWJ-uRyRKadJyRa2ouHWYnIHni1ByWXtry4=.b0241b40-8be2-451c-8881-6dcfb0afda78@github.com>
References: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
 <7vnVXMD6NQxgtaUFlwIbV5HzUIQt-e6Fs_7-a-GfdVY=.e98d63ff-e30b-4228-8988-26f34c944fac@github.com>
 <9WnbxcOxfWJ-uRyRKadJyRa2ouHWYnIHni1ByWXtry4=.b0241b40-8be2-451c-8881-6dcfb0afda78@github.com>
Message-ID: <SHUoeNujK--sDKS_X0oFixkTV9BJWxtsX8o1bkS0slQ=.6d70a0e4-32e4-4c81-ad6f-2452e0a78273@github.com>

On Mon, 23 Jan 2023 18:06:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> It looks like CE is used in `UnixFileSystem` via the system property "sun.io.useCanonCaches" ?

It was disabled in JDK 12 and the general plan was to eventually remove it eventually.

-------------

PR: https://git.openjdk.org/jdk/pull/12141

From duke at openjdk.org  Mon Jan 23 18:16:37 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 23 Jan 2023 18:16:37 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
In-Reply-To: <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com>
Message-ID: <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com>

On Mon, 23 Jan 2023 11:58:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:
> 
>> 2659:     __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
>> 2660:     __ vmovdqu(xmm11, Address(r13, 0x28));
>> 2661:     __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit);
> 
> Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit.

You're reading it correctly - this is redundant and could be handled differently, as the same value is being loaded into ymm4 and ymm10.  I don't think there will be any significant performance gain either way.  This was done in this manner to allow easier transition to URL acceleration when it is implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/' = 0x2f).

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From pminborg at openjdk.org  Mon Jan 23 18:50:28 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 18:50:28 GMT
Subject: RFR: 8300866: Declare some classes final in java.io [v2]
In-Reply-To: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
References: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
Message-ID: <PD_mKqla-QdnhxCITjMpxDBqXFMlKc0ZOXHwsBILVOY=.325ee22d-3df2-435e-ad57-48dbda3f71b7@github.com>

> This PR proposes declaring some internal classes in java.io as `final`, explicitly indicating that they are not intended for sub-classing. 
> 
> If you think declaring classes final is just "static noice", please see http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html first and then come back and comment on the issue.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - Declare classes as final

-------------

Changes: https://git.openjdk.org/jdk/pull/12141/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12141&range=01
  Stats: 15 lines in 5 files changed: 1 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12141.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12141/head:pull/12141

PR: https://git.openjdk.org/jdk/pull/12141

From pminborg at openjdk.org  Mon Jan 23 19:18:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Jan 2023 19:18:52 GMT
Subject: Integrated: 8300866: Declare some classes final in java.io
In-Reply-To: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
References: <TdK1hJ8f71mzSj1_sN078zZJpS-xcrXksb3HEf2kDf4=.0127ab53-78de-49e5-bcec-84ecf76bc269@github.com>
Message-ID: <zu1DdBImaQErAFg2qjjanHj6oaopq9KpYsnGZXhTo70=.51aaed01-5ca6-4c54-95f1-85ffa206ac42@github.com>

On Mon, 23 Jan 2023 14:40:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes declaring some internal classes in java.io as `final`, explicitly indicating that they are not intended for sub-classing. 
> 
> If you think declaring classes final is just "static noice", please see http://minborgsjavapot.blogspot.com/2021/12/why-general-inheritance-is-flawed-and.html first and then come back and comment on the issue.

This pull request has now been integrated.

Changeset: d1173508
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d11735087507a17204bd81ae565409a3b7e881ae
Stats:     15 lines in 5 files changed: 1 ins; 3 del; 11 mod

8300866: Declare some classes final in java.io

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12141

From jlu at openjdk.org  Mon Jan 23 19:40:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jan 2023 19:40:22 GMT
Subject: Integrated: 8300077: Refactor code examples to use @snippet in
 java.text.ChoiceFormat
In-Reply-To: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
References: <sGZjqc4IOnMQmamEP60ByzueQn8xIDwtkY0UipG84tI=.0b1c5d31-42a5-476c-a89b-e6b310f70f02@github.com>
Message-ID: <WQsxVnK4feTLyLpwwSAZhPVwVpcFnGhUKD0esDsQ09E=.107e0129-eefa-4f01-9712-8d464798f247@github.com>

On Thu, 12 Jan 2023 22:31:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.ChoiceFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/ChoiceFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

This pull request has now been integrated.

Changeset: dcf1523b
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dcf1523bf2dba234371190a70a41cfcb77907196
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat

Reviewed-by: lancea, iris, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/11981

From naoto at openjdk.org  Mon Jan 23 19:46:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jan 2023 19:46:26 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
Message-ID: <sLHcRcKzqv_VKNH2NIKXiSXd_ycyItKwDS4Sm3WSdfo=.a8fdd331-6925-4c8f-940e-9410a042cdf4@github.com>

On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On jdk17, following testcase works fine on Linux platform.
>> 
>> Testcase
>> 
>> $ cat cstest1.java
>> import java.nio.charset.*;
>> 
>> public class cstest1 {
>>   public static void main(String[] args) throws Exception {
>>     Charset cs = Charset.defaultCharset();
>>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>>   }
>> }
>> 
>> 
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>> 
>> 
>> But it does not work as expected on jdk18 and jdk21b06
>> 
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> 
>> 
>> Fixed result is as follows:
>> 
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18

For the `jnuCharset` initialization revisit, I filed an issue: https://bugs.openjdk.org/browse/JDK-8300916

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From erikj at openjdk.org  Mon Jan 23 19:56:31 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 23 Jan 2023 19:56:31 GMT
Subject: RFR: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <RflwB4rH7HYrOLt9HK9zFKdLZuixyeCixn6zpGRDndI=.b91d91df-c05d-402f-802e-05ef00c637fe@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

Something is causing high contention in the bot, it's under investigation. In the meantime, all you can do is retry this /integrate command until it goes through.

-------------

PR: https://git.openjdk.org/jdk/pull/12139

From jwilhelm at openjdk.org  Mon Jan 23 20:27:19 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 23 Jan 2023 20:27:19 GMT
Subject: RFR: Merge jdk20
Message-ID: <pokCkee1DfuOIEQv6RHt9z_BrsN-hJ0qXl0Hk9z9-sQ=.672d620d-6762-4c02-9b5b-0fe5692f9319@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge
 - 8290919: Update nroff pages in JDK 20 before RC

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12150&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12150&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12150/files
  Stats: 28 lines in 27 files changed: 1 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/12150.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12150/head:pull/12150

PR: https://git.openjdk.org/jdk/pull/12150

From redestad at openjdk.org  Mon Jan 23 21:00:06 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Jan 2023 21:00:06 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2
In-Reply-To: <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com>
 <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com>
Message-ID: <qJl2CKrBDqZ5IjDfvxy3whckodcDAiqUx3YwDcTsYFs=.c594f21b-f03a-4bf8-841d-55abe3ed1d1b@github.com>

On Mon, 23 Jan 2023 18:14:16 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:
>> 
>>> 2659:     __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
>>> 2660:     __ vmovdqu(xmm11, Address(r13, 0x28));
>>> 2661:     __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit);
>> 
>> Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit.
>
> You're reading it correctly - this is redundant and could be handled differently, as the same value is being loaded into ymm4 and ymm10.  I don't think there will be any significant performance gain either way.  This was done in this manner to allow easier transition to URL acceleration when it is implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/' = 0x2f).

I was mainly curious if there was some obscure detail or difference that eluded me. It wouldn't be the first time!

As it's outside of the loop you're probably right about it not being very important to overall performance, though we should be mindful of setup overheads of transitioning into AVX code. Especially since inputs likely are skewed towards the smallest applicable lengths. I think it would be prudent to run and check the microbenchmark with values near the AVX2 threshold, such as `maxNumBytes = 48`. 

If you choose to keep the code as-is would you mind documenting the rationale behind the redundancy? (Is there WIP on more generalized URL acceleration that could be referenced?)

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From jwilhelm at openjdk.org  Mon Jan 23 21:07:12 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 23 Jan 2023 21:07:12 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <pokCkee1DfuOIEQv6RHt9z_BrsN-hJ0qXl0Hk9z9-sQ=.672d620d-6762-4c02-9b5b-0fe5692f9319@github.com>
References: <pokCkee1DfuOIEQv6RHt9z_BrsN-hJ0qXl0Hk9z9-sQ=.672d620d-6762-4c02-9b5b-0fe5692f9319@github.com>
Message-ID: <jc-2DZXsCFnZ4DgMc7Q4WsZBG_yjfOYZu7gAGUrUclg=.9818bae6-0897-43b8-99de-d16ef32ea613@github.com>

On Mon, 23 Jan 2023 19:52:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 56dc3b08
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56dc3b08a62f651835c5bccca987d93ba2bb8961
Stats:     28 lines in 27 files changed: 1 ins; 0 del; 27 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12150

From duke at openjdk.org  Mon Jan 23 21:53:29 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 23 Jan 2023 21:53:29 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v2]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <uyfTn1g2LycJOtmjlyreb_ao1Z4KCuhG0BwgkvKFr7I=.bc287a65-7a6a-4b1c-8ac8-423f563d3a11@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons 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:

 - Merge branch 'openjdk:master' into Base64-AVX2
 - Remove whitespace
 - Fix wrong register usage
 - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Intermediate AVX2 for decode
 - Fix various AVX support function invocations to get Base64 generated for AVX2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/9cfa6bbd..0f4b9c88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=00-01

  Stats: 4398 lines in 281 files changed: 2042 ins; 692 del; 1664 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From plevart at openjdk.org  Mon Jan 23 22:22:03 2023
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 23 Jan 2023 22:22:03 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
Message-ID: <W8ixUPHLTIgM4IW-yZBkIxQvOBL1lUFG1YaViPjKyME=.3177408b-5dab-4074-980c-a98ef0e167d6@github.com>

On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

>> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
>> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.
>
> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about method inlining

Hi Christian,

I think this looks good. Reviewed.

Regards, Peter

-------------

Marked as reviewed by plevart (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11791

From duke at openjdk.org  Mon Jan 23 22:40:21 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 23 Jan 2023 22:40:21 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v3]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <TRKfZmSk15B2pkGvDhMkCFNTZBCgLw3SYkqlT8b6AHg=.d68faaab-1f3e-423c-81d7-797f5c8cbc8f@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Address review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/0f4b9c88..c776d90f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=01-02

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From bhuang at openjdk.org  Mon Jan 23 22:44:32 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 23 Jan 2023 22:44:32 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups [v5]
In-Reply-To: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
Message-ID: <sodObvnsvM9ev1IKGkiwQ2VmyQYn5xBj1tzY9I9iVVQ=.dcf25988-0351-4e3d-8417-810464fe7ad0@github.com>

> This task is created to update the manual test groups.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Added missing manual tests from :jdk_core.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10864/files
  - new: https://git.openjdk.org/jdk/pull/10864/files/bd2b50a4..82974f1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864

PR: https://git.openjdk.org/jdk/pull/10864

From naoto at openjdk.org  Mon Jan 23 22:54:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jan 2023 22:54:06 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
Message-ID: <RynMP_Z-SGTZrJbS-ViOKBVCPbBxMhpaik5PHniikTk=.a5831379-0d93-4b70-ac85-2472247420fe@github.com>

On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

>> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
>> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.
>
> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about method inlining

Looks good.

src/java.base/share/classes/java/lang/String.java line 3130:

> 3128:               ((ch-'A')|('Z'-ch)) < 0)) &&
> 3129:             (ch < Character.MIN_HIGH_SURROGATE ||
> 3130:              ch > Character.MAX_LOW_SURROGATE))

Not your change, but I'd replace them with `MIN_SURROGATE` and `MAX_SURROGATE` respectively, for readability, taking the opportunity.

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From dholmes at openjdk.org  Mon Jan 23 23:21:44 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jan 2023 23:21:44 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
Message-ID: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>

Please review this simple update to the manpage to set the version to 21-ea.

This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591

Thanks.

-------------

Commit messages:
 - 8290918: Initial nroff manpage generation for JDK 21

Changes: https://git.openjdk.org/jdk/pull/12154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290918
  Stats: 28 lines in 27 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/12154.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12154/head:pull/12154

PR: https://git.openjdk.org/jdk/pull/12154

From lancea at openjdk.org  Mon Jan 23 23:27:05 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Jan 2023 23:27:05 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
Message-ID: <EbXKptkoNTm2NF30bRhqf-W6JKJOPmf7-cw1nHRvjsM=.63bb3cc8-822f-465a-b11d-8a6ac3738cbf@github.com>

On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the manpage to set the version to 21-ea.
> 
> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
> 
> Thanks.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From dholmes at openjdk.org  Tue Jan 24 00:49:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jan 2023 00:49:08 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <EbXKptkoNTm2NF30bRhqf-W6JKJOPmf7-cw1nHRvjsM=.63bb3cc8-822f-465a-b11d-8a6ac3738cbf@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
 <EbXKptkoNTm2NF30bRhqf-W6JKJOPmf7-cw1nHRvjsM=.63bb3cc8-822f-465a-b11d-8a6ac3738cbf@github.com>
Message-ID: <yE85rgB7_qg4o3c-mk_jRsmG7TE1n7zIaGJfSVpVqHo=.2458fd66-6316-444b-a2f8-ae550fdfdaf7@github.com>

On Mon, 23 Jan 2023 23:24:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this simple update to the manpage to set the version to 21-ea.
>> 
>> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
>> 
>> Thanks.
>
> Marked as reviewed by lancea (Reviewer).

Thanks for the review @LanceAndersen

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From iris at openjdk.org  Tue Jan 24 01:32:03 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 24 Jan 2023 01:32:03 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
Message-ID: <GzoeZ25yXzQRU34W-uihZpovZkP20uGvqRaAFukzT1g=.9acb2ba3-5d00-4ae4-afdb-a3c23bed4e01@github.com>

On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the manpage to set the version to 21-ea.
> 
> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
> 
> Thanks.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From jlu at openjdk.org  Tue Jan 24 02:08:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 02:08:14 GMT
Subject: Integrated: 8300706: Use @snippet in java.text
In-Reply-To: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
References: <fGU-7IXtwTJEIeW9ACxzTvWf4EUEwXALB_ldMphWJE4=.d560e14d-d232-43f7-93a2-7e244141d384@github.com>
Message-ID: <-Fk9_rPXrXEPlAdQzTryAjZvBXppkailmIXxE_LiiXE=.0f0f9eb5-4546-49c8-9524-3b446dc637b4@github.com>

On Fri, 20 Jan 2023 17:41:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Some classes / interfaces in java.text have already implemented JEP 413.
> 
> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for the rest of [java.text](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/package-summary.html) including:
> - BreakIterator
> - CharacterIterator
> - DateFormatSymbols
> - DecimalFormat
> - NumberFormat 
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.

This pull request has now been integrated.

Changeset: 0323609f
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0323609f44e68ba8d992419a23be7066838a0e01
Stats:     69 lines in 5 files changed: 7 ins; 11 del; 51 mod

8300706: Use @snippet in java.text

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12121

From jlu at openjdk.org  Tue Jan 24 04:39:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 04:39:09 GMT
Subject: Integrated: 8300589: Use @snippet and @linkplain in
 java.text.CollationKey and java.text.CompactNumberFormat
In-Reply-To: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
References: <vQnObRw_pFQ8JpNlDtWyMsTFSv0ZU-jQnRLMDeBsLi8=.98b6b352-cc68-433a-b31b-757c41002eb3@github.com>
Message-ID: <Q9VXHi--rYNyH20yn-4Jz-nRbIKB5j835eyUIAAtUsE=.8718d6f9-9318-45da-97f9-71682b170e53@github.com>

On Thu, 19 Jan 2023 22:25:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR implements _JEP 413: Code Snippets in Java API Documentation_ for [java.text.CollationKey](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CollationKey.html) and [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html).
> 
> Code examples using <pre> ... </pre> blocks are replaced with the @ snippet syntax where applicable.
> 
> Additionally, for [java.text.CompactNumberFormat](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/CompactNumberFormat.html) internal plain text links using <a> ... </a> are replaced with @ linkplain. (External links are kept the same)

This pull request has now been integrated.

Changeset: b3822f50
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3822f50c85524a00a045aa3a3d902f190e35906
Stats:     15 lines in 2 files changed: 0 ins; 2 del; 13 mod

8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat

Reviewed-by: lancea, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/12108

From dholmes at openjdk.org  Tue Jan 24 05:42:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jan 2023 05:42:02 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <GzoeZ25yXzQRU34W-uihZpovZkP20uGvqRaAFukzT1g=.9acb2ba3-5d00-4ae4-afdb-a3c23bed4e01@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
 <GzoeZ25yXzQRU34W-uihZpovZkP20uGvqRaAFukzT1g=.9acb2ba3-5d00-4ae4-afdb-a3c23bed4e01@github.com>
Message-ID: <KlTh9wjTbC3k8tzpm2NrU1j0H_g2vTIVEhRGu4BMKL4=.4b169f0a-d1b4-4e8c-914b-96b07c3418c8@github.com>

On Tue, 24 Jan 2023 01:28:53 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Please review this simple update to the manpage to set the version to 21-ea.
>> 
>> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
>> 
>> Thanks.
>
> Marked as reviewed by iris (Reviewer).

Thanks for the review @irisclark !

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From darcy at openjdk.org  Tue Jan 24 05:57:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 24 Jan 2023 05:57:04 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
Message-ID: <YZWmN-Gn-7lcp-GJ9EiaHjm14TEHDC2GhJddEjyj3PA=.7cf5e2e6-0fbf-4994-8d1a-8d51c1d2a746@github.com>

On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the manpage to set the version to 21-ea.
> 
> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
> 
> Thanks.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From dholmes at openjdk.org  Tue Jan 24 06:31:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jan 2023 06:31:11 GMT
Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <YZWmN-Gn-7lcp-GJ9EiaHjm14TEHDC2GhJddEjyj3PA=.7cf5e2e6-0fbf-4994-8d1a-8d51c1d2a746@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
 <YZWmN-Gn-7lcp-GJ9EiaHjm14TEHDC2GhJddEjyj3PA=.7cf5e2e6-0fbf-4994-8d1a-8d51c1d2a746@github.com>
Message-ID: <SUK02VMlj73d0HhBwEdTte0bHR33-fl8v4GnyICDhKU=.ffe72dfc-6e51-41ed-a3fd-cee71e3cc5dc@github.com>

On Tue, 24 Jan 2023 05:54:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this simple update to the manpage to set the version to 21-ea.
>> 
>> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
>> 
>> Thanks.
>
> Marked as reviewed by darcy (Reviewer).

Thanks for the review @jddarcy !

I think that suffices for this trivial change.

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From dholmes at openjdk.org  Tue Jan 24 06:31:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jan 2023 06:31:13 GMT
Subject: Integrated: 8290918: Initial nroff manpage generation for JDK 21
In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com>
Message-ID: <yeIK2jww1KRzkXdap1HpcJ09H4UlC5ak6d0o3URrzQA=.747cd40f-8159-4809-82d7-b801be1be373@github.com>

On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the manpage to set the version to 21-ea.
> 
> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591
> 
> Thanks.

This pull request has now been integrated.

Changeset: 6dd8723f
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6dd8723f66a22e626d98c74cff0b0b344a62626d
Stats:     28 lines in 27 files changed: 0 ins; 0 del; 28 mod

8290918: Initial nroff manpage generation for JDK 21

Reviewed-by: lancea, iris, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12154

From pminborg at openjdk.org  Tue Jan 24 07:46:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 24 Jan 2023 07:46:11 GMT
Subject: Integrated: 8300863: Remove C-style array declarations in java.io
In-Reply-To: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
References: <c-8fRnuXDxaCiRiqCpjcWRsmOMx_mUAiBPjgkJBvQzs=.3fd74cc0-5ffe-47ea-85b4-1d0661cd308a@github.com>
Message-ID: <qHHaxu_txW7MbJmZX-Buc72ss78VlB9Wi6e-qH_EIH0=.887ac477-3fc4-4bb7-bf34-b6574b139f3e@github.com>

On Mon, 23 Jan 2023 13:53:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some variables are declared using old-style declarations. These should be modified to conform to modern style. 
> 
> This is a task derived from https://github.com/openjdk/jdk/pull/11848

This pull request has now been integrated.

Changeset: 57f2d48e
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57f2d48e1e11eb2f87be7e47ab943031696e51f5
Stats:     20 lines in 8 files changed: 1 ins; 1 del; 18 mod

8300863: Remove C-style array declarations in java.io

Reviewed-by: alanb, rriggs, darcy, iris

-------------

PR: https://git.openjdk.org/jdk/pull/12139

From duke at openjdk.org  Tue Jan 24 10:10:26 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 10:10:26 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v3]
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <o-W7B1F6-mJi9pCYinNXaz0OE6gaNkd1EL-v_vzkMQQ=.2582b71e-ce60-4d6b-9c41-394039f8c3cd@github.com>

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Removing outdated comment in ImmutableCollections regarding implicit nullchecks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11847/files
  - new: https://git.openjdk.org/jdk/pull/11847/files/8e67eb86..b6bfa3f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11847/head:pull/11847

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Tue Jan 24 10:28:07 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 10:28:07 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>
Message-ID: <VWvnkoUgcHkGIjxbvmPpX59YgiWjwTqkZUNx7Xl4_OE=.822cc740-bfbf-4ce3-9c3a-522cb16ce6ed@github.com>

On Mon, 9 Jan 2023 18:26:56 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>        Modifies ImmutableCollections.listCopy:
>>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>    Modifies Map.copyOf:
>>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 169:
> 
>> 167:     @SuppressWarnings("unchecked")
>> 168:     static <E> List<E> listCopy(Collection<? extends E> coll) {
>> 169:         if (coll instanceof List12 || (coll instanceof ListN && ! ((ListN<?>)coll).allowNulls)) {
> 
> Maybe replace the cast with an instanceof pattern here?

@stuart-marks Sorry, missed this notification. I initially had the same idea, but decided against it because it forces me to suppress "rawtypes" since `coll instanceof ListN` is not considered to be a rawtype, but `coll instanceof ListN c` is. And currently it won't allow for `coll instanceof ListN<E> c`...

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Tue Jan 24 10:28:10 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 10:28:10 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
Message-ID: <Gfm93QMhW5DvpChEr1-eCwb-V4TZFEOb9saJlHtqdP0=.0bce483f-79bd-4b32-a107-39c0a5d5b421@github.com>

On Sun, 22 Jan 2023 15:20:18 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>        Modifies ImmutableCollections.listCopy:
>>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>    Modifies Map.copyOf:
>>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 174:
> 
>> 172:             return List.of();
>> 173:         } else {
>> 174:             return (List<E>)List.of(coll.toArray()); // implicit nullcheck of coll
> 
> The comment is no longer relevant here, as it now happens on line 171.

@szegedi Nice catch, Attila. Corrected!

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From alanb at openjdk.org  Tue Jan 24 10:33:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jan 2023 10:33:09 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v5]
In-Reply-To: <XLtRK2Z7j8Q7V5ztAzK5lylNQszVecZdoaJmSchUCsg=.58840f35-dfba-4ed6-9481-d7e1eda30b7e@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <XLtRK2Z7j8Q7V5ztAzK5lylNQszVecZdoaJmSchUCsg=.58840f35-dfba-4ed6-9481-d7e1eda30b7e@github.com>
Message-ID: <kO50cppz35NK-psPVR43sXySSuifi80D1BTr0BjsdOk=.b2ed9d5b-d63f-4476-8246-c5fec8778413@github.com>

On Mon, 23 Jan 2023 12:38:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove methods with implicit zero offset

src/java.base/share/classes/java/io/DataInputStream.java line 59:

> 57:     }
> 58: 
> 59:     private final byte[] readBuffer = new byte[8];

No objection to the readBuffer but it does make it wonder if we should re-visit bytearr and chararr as they are only need for reading modified UTF-8 strings and shouldn't need to be eagerly created.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 37:

> 35:  * <p>
> 36:  * All methods in this class will throw an {@linkplain NullPointerException} if {@code null} is
> 37:  * passed in as a method parameter for a byte array.

The NPE is described in both the class description and some of the methods, it doesn't need to be both.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Tue Jan 24 10:53:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 24 Jan 2023 10:53:08 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v5]
In-Reply-To: <kO50cppz35NK-psPVR43sXySSuifi80D1BTr0BjsdOk=.b2ed9d5b-d63f-4476-8246-c5fec8778413@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <XLtRK2Z7j8Q7V5ztAzK5lylNQszVecZdoaJmSchUCsg=.58840f35-dfba-4ed6-9481-d7e1eda30b7e@github.com>
 <kO50cppz35NK-psPVR43sXySSuifi80D1BTr0BjsdOk=.b2ed9d5b-d63f-4476-8246-c5fec8778413@github.com>
Message-ID: <DYtG5M_f6LPvDcdFzxnAvx7MFTKO8aImW4amypJTF5o=.3a14d1d1-ffad-4bbb-b8bc-2db0199ea4eb@github.com>

On Tue, 24 Jan 2023 10:28:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove methods with implicit zero offset
>
> src/java.base/share/classes/java/io/DataInputStream.java line 59:
> 
>> 57:     }
>> 58: 
>> 59:     private final byte[] readBuffer = new byte[8];
> 
> No objection to the readBuffer but it does make it wonder if we should re-visit bytearr and chararr as they are only need for reading modified UTF-8 strings and shouldn't need to be eagerly created.

https://bugs.openjdk.org/browse/JDK-8300979

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Tue Jan 24 10:58:39 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 24 Jan 2023 10:58:39 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v6]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <b8rM9I4PBYKd0IKNhHaGnHJYTe9Qu3hHDfpReJGVMlI=.e6b6d461-a874-465a-aa6e-26b0e34486b8@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant @throws documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/a13b3603..469cac07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=04-05

  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From forax at openjdk.org  Tue Jan 24 11:10:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 24 Jan 2023 11:10:05 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <VWvnkoUgcHkGIjxbvmPpX59YgiWjwTqkZUNx7Xl4_OE=.822cc740-bfbf-4ce3-9c3a-522cb16ce6ed@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>
 <VWvnkoUgcHkGIjxbvmPpX59YgiWjwTqkZUNx7Xl4_OE=.822cc740-bfbf-4ce3-9c3a-522cb16ce6ed@github.com>
Message-ID: <2YVlfKYFf6V3tuoZbSK7SM3lgPqU7GBK7GAcioS7A6Q=.9d92e700-287d-4bd3-8cc0-490a75a55323@github.com>

On Tue, 24 Jan 2023 10:23:14 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 169:
>> 
>>> 167:     @SuppressWarnings("unchecked")
>>> 168:     static <E> List<E> listCopy(Collection<? extends E> coll) {
>>> 169:         if (coll instanceof List12 || (coll instanceof ListN && ! ((ListN<?>)coll).allowNulls)) {
>> 
>> Maybe replace the cast with an instanceof pattern here?
>
> @stuart-marks Sorry, missed this notification. I initially had the same idea, but decided against it because it forces me to suppress "rawtypes" since `coll instanceof ListN` is not considered to be a rawtype, but `coll instanceof ListN c` is. And currently it won't allow for `coll instanceof ListN<E> c`...

`coll instanceof ListN<?> list` should work.

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From itakiguchi at openjdk.org  Tue Jan 24 12:30:06 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 24 Jan 2023 12:30:06 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
 <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
Message-ID: <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>

On Mon, 23 Jan 2023 13:46:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's never been supported to run with -Dfile.encoding=Cp943C. It may have worked in JDK 8 but I doubt it could have worked consistently since JDK 9 because the default charset is derived before it's possible to locate charset implementations outside of java.base.

As described before, JDK17 worked with `-Dfile.encoding=Cp943C`, and JDK18 changed the behavior. I heard some apps had already ported on JDK17 with the option, and works.

> I think it would be useful to know a bit more about the environment. It sounds like it might be AIX -> Linux migration but I'm curious if you have any insight into why these applications depend on default charset being Cp943C. Is it text files that are opened without specifying the charset or is is something else?

One of my client has many legacy Java apps on AIX. Their apps use default charset to communicate with other apps via cipher communication, and validate data by using Cp943C.

I hope IBM943C is moved to java.base module, like #11908 .

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From duke at openjdk.org  Tue Jan 24 12:31:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 24 Jan 2023 12:31:30 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v15]
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test IgnoreUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Add whitespace after keywords if and for

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11976/files
  - new: https://git.openjdk.org/jdk/pull/11976/files/cf93bfc1..408d2228

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11976&range=13-14

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11976.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11976/head:pull/11976

PR: https://git.openjdk.org/jdk/pull/11976

From pminborg at openjdk.org  Tue Jan 24 12:36:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 24 Jan 2023 12:36:48 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v7]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <Lv4XmlDwMhUrESGqwXu8wvyt4GVHdUELFbjmbuTpqf0=.2b321bf0-c225-42c0-8885-7fd961c0ab4d@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge master and fix RAF issues
 - Remove redundant @throws documentation
 - Remove methods with implicit zero offset
 - Add benchmark
 - Rename and move
 - Improve doc and fix typo
 - Remove white spaces
 - Remove white space
 - Fix jcheck issues
 - Update copyright years
 - ... and 8 more: https://git.openjdk.org/jdk/compare/048705c0...f331d2e7

-------------

Changes: https://git.openjdk.org/jdk/pull/12076/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=06
  Stats: 1720 lines in 12 files changed: 1065 ins; 560 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From pminborg at openjdk.org  Tue Jan 24 12:44:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 24 Jan 2023 12:44:17 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v8]
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update RAF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12076/files
  - new: https://git.openjdk.org/jdk/pull/12076/files/f331d2e7..4bf1a501

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12076&range=06-07

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12076.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12076/head:pull/12076

PR: https://git.openjdk.org/jdk/pull/12076

From alanb at openjdk.org  Tue Jan 24 12:54:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jan 2023 12:54:03 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
 <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
 <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
Message-ID: <H5dR1wC91-aqAH9tzEhIb2D3me9BtLeWVRFhQIEKuB4=.972ce810-0bd8-448d-85ab-2c12336316a5@github.com>

On Tue, 24 Jan 2023 12:27:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> One of my client has many legacy Java apps on AIX. Their apps use default charset to communicate with other apps via cipher communication, and validate data by using Cp943C.

Do you know if there is any configuration on AIX that would derive Cp943C as the default charset? That is, are they running with -Dfile.encoding=Cp943C on the AIX systems or is it chosen by default. This goes to the question as to whether they just moving these applications to Linux and expecting the default charset to be the same.

Do you know which APIs they are using? We filled in the gaps many releases ago so that all APIs that do encoding/decoding allow the charset to be specified and I'm wondering why they don't use those.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From alanb at openjdk.org  Tue Jan 24 12:59:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jan 2023 12:59:04 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
 <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
 <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
Message-ID: <ApgC3xM-2rr6Q2KLlecT9h2eq6UrvDXBJyJDiC5ZgrI=.78baae33-5aba-4fc0-b0b5-308c09ae8b3e@github.com>

On Tue, 24 Jan 2023 12:27:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> As described before, JDK17 worked with `-Dfile.encoding=Cp943C`, and JDK18 changed the behavior. I heard some apps had already ported on JDK17 with the option, and works.

It's bug that this "worked" in JDK 9+ as the default charset needs to be in java.base.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From asotona at openjdk.org  Tue Jan 24 13:42:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 24 Jan 2023 13:42:59 GMT
Subject: [jdk20] RFR: 8300953: ClassDesc::ofInternalName missing @since tag
Message-ID: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>

ClassDesc::ofInternalName was added in JDK 20, however @since tag is missing. 
This patch fixes the javadoc. 

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8300953: ClassDesc::ofInternalName missing @since tag

Changes: https://git.openjdk.org/jdk20/pull/115/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300953
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/115.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/115/head:pull/115

PR: https://git.openjdk.org/jdk20/pull/115

From duke at openjdk.org  Tue Jan 24 13:45:27 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 13:45:27 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v4]
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <idt2bSWR9XqmKX1C11efRNr6_fXbdMsdWl3QvHowNKk=.fa269c0c-b8c6-4fad-bacc-8e2914016eec@github.com>

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Switching to pattern matching to avoid raw type + cast in listCopy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11847/files
  - new: https://git.openjdk.org/jdk/pull/11847/files/b6bfa3f8..860b0c99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11847/head:pull/11847

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Tue Jan 24 13:45:29 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 13:45:29 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <2YVlfKYFf6V3tuoZbSK7SM3lgPqU7GBK7GAcioS7A6Q=.9d92e700-287d-4bd3-8cc0-490a75a55323@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>
 <VWvnkoUgcHkGIjxbvmPpX59YgiWjwTqkZUNx7Xl4_OE=.822cc740-bfbf-4ce3-9c3a-522cb16ce6ed@github.com>
 <2YVlfKYFf6V3tuoZbSK7SM3lgPqU7GBK7GAcioS7A6Q=.9d92e700-287d-4bd3-8cc0-490a75a55323@github.com>
Message-ID: <r48aS9WvCQSfVyLA6c8CvAkxXyvoWkk87BF4J0nTqtY=.9738b17d-dc4b-4b21-84f6-871edf46d640@github.com>

On Tue, 24 Jan 2023 11:07:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> @stuart-marks Sorry, missed this notification. I initially had the same idea, but decided against it because it forces me to suppress "rawtypes" since `coll instanceof ListN` is not considered to be a rawtype, but `coll instanceof ListN c` is. And currently it won't allow for `coll instanceof ListN<E> c`...
>
> `coll instanceof ListN<?> list` should work.

@forax @stuart-marks Yeah, that works. It's unfortunate that it's not possible to match on the actual (generic) type, as then both sides of the || could use type unification to avoid having to do the cast on the return value as well. Submitted a commit to switch to the wildcard version.

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From forax at openjdk.org  Tue Jan 24 14:29:09 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 24 Jan 2023 14:29:09 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <r48aS9WvCQSfVyLA6c8CvAkxXyvoWkk87BF4J0nTqtY=.9738b17d-dc4b-4b21-84f6-871edf46d640@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <tH68uXlgAm5L0kWt_IPaiqQ70EvOcpt_Dt7fsEJNzeU=.82c8fee5-91db-46d0-8d20-4caee83591dc@github.com>
 <VWvnkoUgcHkGIjxbvmPpX59YgiWjwTqkZUNx7Xl4_OE=.822cc740-bfbf-4ce3-9c3a-522cb16ce6ed@github.com>
 <2YVlfKYFf6V3tuoZbSK7SM3lgPqU7GBK7GAcioS7A6Q=.9d92e700-287d-4bd3-8cc0-490a75a55323@github.com>
 <r48aS9WvCQSfVyLA6c8CvAkxXyvoWkk87BF4J0nTqtY=.9738b17d-dc4b-4b21-84f6-871edf46d640@github.com>
Message-ID: <SdXlE2UAq0ybY-_xUaRXwFElLa-2yyqGCDPm1j6SDX0=.76bff59a-7630-4fa7-97d3-c8c26238dfc2@github.com>

On Tue, 24 Jan 2023 13:40:37 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> `coll instanceof ListN<?> list` should work.
>
> @forax @stuart-marks Yeah, that works. It's unfortunate that it's not possible to match on the actual (generic) type, as then both sides of the || could use type unification to avoid having to do the cast on the return value as well. Submitted a commit to switch to the wildcard version.

Avoiding the cast to `List<E>` requires two things:
- we need a way to say at declaration that a parameter type E is covariant, this is not true for List but this is true for ImmutableList (so true for List2 and ListN).
- we need a way to do an union between two types when doing pattern matching .

This former is still in discussion as a feature of Valhalla (it's a part of Dan Smith Phd), the later is still in discussion as a feature of Amber, so maybe in the future this will be possible is the star aligned.

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From alanb at openjdk.org  Tue Jan 24 15:37:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jan 2023 15:37:14 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v8]
In-Reply-To: <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
Message-ID: <abNSsTNs3D0tPVVylJNidStThagdClJmtvnXJmfib0o=.37ce05b6-3603-4de9-8835-c664e6c43942@github.com>

On Tue, 24 Jan 2023 12:44:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update RAF

Looks good, I don't have any more comments, @RogerRiggs?

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12076

From duke at openjdk.org  Tue Jan 24 15:56:29 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Tue, 24 Jan 2023 15:56:29 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v4]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <pGxsjjjxsV_o1Ev4DVfnBcs-uzDiZuc80MlXLPXzyVw=.236a3005-32e6-46af-9edf-f0484fdf0cea@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons 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:

 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Address review comment
 - Remove whitespace
 - Fix wrong register usage
 - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Intermediate AVX2 for decode
 - ... and 1 more: https://git.openjdk.org/jdk/compare/74411fed...f9140f40

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/c776d90f..f9140f40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=02-03

  Stats: 471 lines in 76 files changed: 123 ins; 121 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From darcy at openjdk.org  Tue Jan 24 17:04:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 24 Jan 2023 17:04:12 GMT
Subject: [jdk20] RFR: 8300953: ClassDesc::ofInternalName missing @since tag
In-Reply-To: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
References: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
Message-ID: <mY596CcSkMZy1y-CLLShWzN2jDTgXvB_aJsCJMuvdSA=.bef845dd-f25e-4783-bb15-08c865ff6236@github.com>

On Tue, 24 Jan 2023 13:35:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassDesc::ofInternalName was added in JDK 20, however @since tag is missing. 
> This patch fixes the javadoc. 
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/115

From mchung at openjdk.org  Tue Jan 24 17:22:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 24 Jan 2023 17:22:09 GMT
Subject: [jdk20] RFR: 8300953: ClassDesc::ofInternalName missing @since tag
In-Reply-To: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
References: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
Message-ID: <KGLIfITwMvzsMckzd36Aj0EgxmCnq8U9QAJsxndxk4I=.dbb788e9-df0f-47df-ac78-9da4a9ec87de@github.com>

On Tue, 24 Jan 2023 13:35:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassDesc::ofInternalName was added in JDK 20, however @since tag is missing. 
> This patch fixes the javadoc. 
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/115

From smarks at openjdk.org  Tue Jan 24 18:03:10 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 24 Jan 2023 18:03:10 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
Message-ID: <sYlJlrOU0Sk-ctxeDJZNUp2POtPT1E_s62RQAEushV4=.0460678a-6bc0-4a6c-8816-d22f0cd3db79@github.com>

On Sun, 22 Jan 2023 15:20:18 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>        Modifies ImmutableCollections.listCopy:
>>        Introduces a check for isEmpty to avoid allocation in the case of an empty input collection.
>>  - 8299444: java.util.Set.copyOf allocates needlessly for empty input collections
>>    
>>    Modifies Map.copyOf:
>>    Introduces a check for isEmpty to avoid allocation in the case of an empty input Map.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 174:
> 
>> 172:             return List.of();
>> 173:         } else {
>> 174:             return (List<E>)List.of(coll.toArray()); // implicit nullcheck of coll
> 
> The comment is no longer relevant here, as it now happens on line 171.

Thanks @szegedi for catching this and @viktorklang-ora for fixing it. I like having comments like this in cases where we need to throw NPE for null and for which there's no explicit `Objects.requireNonNull`. We've had cases in the past where an apparently innocuous refactoring postponed an implicit nullcheck, which opened the possibility of a side effect occuring before NPE was thrown (violates failure idempotency). So I think maintaining such comments is important.

With that in mind, for the Set and Map cases, could you (Viktor) add similar comments there? Arguably they should have been there already, but, oh well, they weren't. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From mchung at openjdk.org  Tue Jan 24 18:26:40 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 24 Jan 2023 18:26:40 GMT
Subject: RFR: 8300924: Method::invoke throws wrong exception type when passing
 wrong number of arguments to method with 4 or more parameters
Message-ID: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>

A simple fix in core reflection to check if the number of actual and formal parameters differ before invoking the method or the constructor regardless of whether it's a specialized case or not.

-------------

Commit messages:
 - 8300924: Method::invoke throws wrong exception type when passing wrong number of arguments to method with 4 or more parameters

Changes: https://git.openjdk.org/jdk/pull/12170/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300924
  Stats: 85 lines in 3 files changed: 67 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12170.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12170/head:pull/12170

PR: https://git.openjdk.org/jdk/pull/12170

From weijun at openjdk.org  Tue Jan 24 18:58:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jan 2023 18:58:08 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v15]
In-Reply-To: <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
Message-ID: <ITa36LJZiiJAJVLewbR9wQOopfNXg2QreiTBEEaV7fo=.f22f5aa9-0b25-45fb-94b4-e508236fdc16@github.com>

On Tue, 24 Jan 2023 12:31:30 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
>> 
>> The mentioned call sites needs updates to check and ignore such files.
>> 
>> A new test IgnoreUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add whitespace after keywords if and for

The change looks fine. I'll run some test.

Precisely `ZipFile::isSignatureRelated` should also contain those `SIG-` files. The feature is not used so I cannot say if it's wrong.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From alanb at openjdk.org  Tue Jan 24 19:03:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jan 2023 19:03:03 GMT
Subject: RFR: 8300924: Method::invoke throws wrong exception type when
 passing wrong number of arguments to method with 4 or more parameters
In-Reply-To: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
References: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
Message-ID: <Va9OMb_OKOoaNSGGxHMKwqsnVkQdCj8tWjaDxnqoCbk=.a4063c76-fa1c-4d0a-9af3-500de4ec9b90@github.com>

On Tue, 24 Jan 2023 18:19:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix in core reflection to check if the number of actual and formal parameters differ before invoking the method or the constructor regardless of whether it's a specialized case or not.

Changes looks okay, surprised it wasn't spotted in 18 or 19.

-------------

PR: https://git.openjdk.org/jdk/pull/12170

From duke at openjdk.org  Tue Jan 24 19:07:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 24 Jan 2023 19:07:04 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v15]
In-Reply-To: <ITa36LJZiiJAJVLewbR9wQOopfNXg2QreiTBEEaV7fo=.f22f5aa9-0b25-45fb-94b4-e508236fdc16@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
 <ITa36LJZiiJAJVLewbR9wQOopfNXg2QreiTBEEaV7fo=.f22f5aa9-0b25-45fb-94b4-e508236fdc16@github.com>
Message-ID: <23Ag-QUbuN8Y5jR2CZ8q51LMTZ-Bs_qSE2Xl4CjaHD4=.2a91bdd1-2ff1-49b5-9979-3ca307cc0120@github.com>

On Tue, 24 Jan 2023 18:54:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Precisely `ZipFile::isSignatureRelated` should also contain those `SIG-` files. 

Should they though?  These files are ultimately read by JarFile.initializeVerifier, which I guess only cares about signature/block files it actually knows how to verify, currently EC, RSA, DSA?

> The feature is not used so I cannot say if it's wrong.

The JAR File Specification is a bit short on the purpose of these files. I assume they are expected to be verified by code external to the JDK?

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From rriggs at openjdk.org  Tue Jan 24 19:27:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Jan 2023 19:27:06 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v8]
In-Reply-To: <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
Message-ID: <l5XeM7LxGOG_Lcwx_fQtWDQq7Y5OfcLSVothHV52tb4=.4ec0b9a0-129d-495a-8340-60767245ec3b@github.com>

On Tue, 24 Jan 2023 12:44:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update RAF

Look good, thanks

test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java line 197:

> 195: 
> 196:     // At-zero methods
> 197: 

These *AtZero* test methods don't add much value?  It is already testing an offset of 1 in the original tests.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12076

From duke at openjdk.org  Tue Jan 24 19:43:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 19:43:14 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v5]
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <I6xoNPcoYD-g1qx4KZXEEfar1S0Sv-VOaOt0hWEUzw8=.83969664-4a39-465c-821c-45c3d03f19bd@github.com>

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Adding comment clarifying where implicit nullchecks are made in Set and Map copyOf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11847/files
  - new: https://git.openjdk.org/jdk/pull/11847/files/860b0c99..9d80411a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11847&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11847/head:pull/11847

PR: https://git.openjdk.org/jdk/pull/11847

From rriggs at openjdk.org  Tue Jan 24 19:43:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Jan 2023 19:43:15 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v5]
In-Reply-To: <I6xoNPcoYD-g1qx4KZXEEfar1S0Sv-VOaOt0hWEUzw8=.83969664-4a39-465c-821c-45c3d03f19bd@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <I6xoNPcoYD-g1qx4KZXEEfar1S0Sv-VOaOt0hWEUzw8=.83969664-4a39-465c-821c-45c3d03f19bd@github.com>
Message-ID: <jblrRn0S0tAwmGszqrsoz_-qRFVXdlABvy4-_6-aWlE=.1b42f137-dadc-4fa7-884e-bc9c7e3de4ed@github.com>

On Tue, 24 Jan 2023 19:38:58 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment clarifying where implicit nullchecks are made in Set and Map copyOf

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From duke at openjdk.org  Tue Jan 24 19:43:18 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 24 Jan 2023 19:43:18 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <sYlJlrOU0Sk-ctxeDJZNUp2POtPT1E_s62RQAEushV4=.0460678a-6bc0-4a6c-8816-d22f0cd3db79@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
 <sYlJlrOU0Sk-ctxeDJZNUp2POtPT1E_s62RQAEushV4=.0460678a-6bc0-4a6c-8816-d22f0cd3db79@github.com>
Message-ID: <zNXnNyFIq0yUbJN71H3YgWv08FWczLTtrHtA51nmkcw=.ce5a8f87-e960-43aa-9035-482a9195e8c1@github.com>

On Tue, 24 Jan 2023 18:00:30 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 174:
>> 
>>> 172:             return List.of();
>>> 173:         } else {
>>> 174:             return (List<E>)List.of(coll.toArray()); // implicit nullcheck of coll
>> 
>> The comment is no longer relevant here, as it now happens on line 171.
>
> Thanks @szegedi for catching this and @viktorklang-ora for fixing it. I like having comments like this in cases where we need to throw NPE for null and for which there's no explicit `Objects.requireNonNull`. We've had cases in the past where an apparently innocuous refactoring postponed an implicit nullcheck, which opened the possibility of a side effect occuring before NPE was thrown (violates failure idempotency). So I think maintaining such comments is important.
> 
> With that in mind, for the Set and Map cases, could you (Viktor) add similar comments there? Arguably they should have been there already, but, oh well, they weren't. Thanks.

@stuart-marks Makes sense. I've added those comments to Set and Map copyOf()

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From smarks at openjdk.org  Tue Jan 24 20:16:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 24 Jan 2023 20:16:05 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v5]
In-Reply-To: <I6xoNPcoYD-g1qx4KZXEEfar1S0Sv-VOaOt0hWEUzw8=.83969664-4a39-465c-821c-45c3d03f19bd@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <I6xoNPcoYD-g1qx4KZXEEfar1S0Sv-VOaOt0hWEUzw8=.83969664-4a39-465c-821c-45c3d03f19bd@github.com>
Message-ID: <meNcuR6tiiNO088Uc9lbVNY87qbbRfH_N5Lboi_B7Q0=.2edac80d-570b-4395-a881-3e869f00b8c3@github.com>

On Tue, 24 Jan 2023 19:43:14 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
>> 
>> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment clarifying where implicit nullchecks are made in Set and Map copyOf

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From smarks at openjdk.org  Tue Jan 24 20:16:09 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 24 Jan 2023 20:16:09 GMT
Subject: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty
 input collections [v2]
In-Reply-To: <zNXnNyFIq0yUbJN71H3YgWv08FWczLTtrHtA51nmkcw=.ce5a8f87-e960-43aa-9035-482a9195e8c1@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
 <KiieaEwemgSWjSvu2ThR6nSe8u70tqmBb4-2U8vCh34=.0107ab55-1113-437a-bae4-292bae37452d@github.com>
 <aUUyjrQDfSDGiItYu-3mQ3svLFUqi8spaJpRlmPTddo=.c73042ec-c852-42b2-bd7c-513eac738875@github.com>
 <sYlJlrOU0Sk-ctxeDJZNUp2POtPT1E_s62RQAEushV4=.0460678a-6bc0-4a6c-8816-d22f0cd3db79@github.com>
 <zNXnNyFIq0yUbJN71H3YgWv08FWczLTtrHtA51nmkcw=.ce5a8f87-e960-43aa-9035-482a9195e8c1@github.com>
Message-ID: <6l168FSzRaBE1u55hgNv9HRi1109noGPtlW2j9C-mMY=.2d3d0a2e-101b-4708-8eba-e4a9825da973@github.com>

On Tue, 24 Jan 2023 19:34:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Thanks @szegedi for catching this and @viktorklang-ora for fixing it. I like having comments like this in cases where we need to throw NPE for null and for which there's no explicit `Objects.requireNonNull`. We've had cases in the past where an apparently innocuous refactoring postponed an implicit nullcheck, which opened the possibility of a side effect occuring before NPE was thrown (violates failure idempotency). So I think maintaining such comments is important.
>> 
>> With that in mind, for the Set and Map cases, could you (Viktor) add similar comments there? Arguably they should have been there already, but, oh well, they weren't. Thanks.
>
> @stuart-marks Makes sense. I've added those comments to Set and Map copyOf()

Great, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From dnguyen at openjdk.org  Tue Jan 24 20:57:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 20:57:43 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
Message-ID: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>

Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
All tests passed

-------------

Commit messages:
 - Remove currency symbol entries
 - Remove whitespace using tool
 - Remove double quotes generated by translation tool
 - Revert translation's removal of <is considered> text
 - Update files for localization

Changes: https://git.openjdk.org/jdk20/pull/116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300719
  Stats: 1030 lines in 81 files changed: 218 ins; 115 del; 697 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 21:08:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:08:11 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <4tI9y6FpAFrOiS4N4joygZHAHvPm-Ka2D9_3F8pyD6o=.fbb62ba6-4658-46b5-96f8-307ab3b41f81@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@prrace @wangweij @naotoj @JoeWang-Java @plummercj @alexeysemenyukoracle
Could you review the changes from this localization drop?

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 21:21:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 21:21:47 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty
Message-ID: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>

This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

-------------

Commit messages:
 - 8300916: Re-examine the initialization of JNU Charset in StaticProperty

Changes: https://git.openjdk.org/jdk/pull/12171/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300916
  Stats: 27 lines in 3 files changed: 4 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From dnguyen at openjdk.org  Tue Jan 24 21:48:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 21:48:11 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <SltPNoJFof9JSmmSGamoTHPgVj-sZYWE0-_ijvVAHq4=.904ae847-154e-4fbc-bb8f-3792d5767b3e@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

@magicus @LanceAndersen @jonathan-gibbons @pavelrappo @dougxc @lahodaj
Could you review the changes from this localization drop for the areas you're familiar with?

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 21:52:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 21:52:36 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v2]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <s-oRlTiDkc1cDcneDObJOcpjSjQVoYpNaWn0PTOXY_k=.fda5fee1-e1dd-4982-8817-e5df7dde3f04@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Clean-up of imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/183f5526..579aca70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Tue Jan 24 21:57:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 21:57:25 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v3]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  One more.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/579aca70..23ed827c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From cjplummer at openjdk.org  Tue Jan 24 22:05:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 24 Jan 2023 22:05:10 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <B6mEwU9m4V_eHQKkH5EHYR4ofs8G7wh5Zzpt7K6-M7I=.a2729d77-4f00-4871-a4a1-2904ce852c74@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

jdk.console and jdk.management.agent changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:12:26 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:12:26 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change German help of jar command

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4ced04fb..a2528015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 22:24:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:24:15 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Changes requested by naoto (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:

> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:

This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:

> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
> 37: resource.wxl-file=WiX-Lokalisierungsdatei
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `de`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:

> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `ja`?

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:

> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl

Shouldn't this be `zh_CN`?

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove this.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:24:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:24:16 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>

On Tue, 24 Jan 2023 22:05:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
> 
>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
> 
> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.

OK, I can make the manual edit for this

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38:
> 
>> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C
>> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `zh_CN`?

The translation tool seems to use the English source file's file name here, so it's replaced. I will handle these 3 occurrences now. I thought I handled all occurrences of this, but these 3 slipped in

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:24 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:24 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Change localization codes. Add CNY back

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/a2528015..40291c61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01-02

  Stats: 4 lines in 4 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:28 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:28 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <aSepuyRGkRCKZRV73viMQmYFsLPiygi9ty1PrPJAfOA=.847916eb-487b-4d07-9959-df8e9e178ac9@github.com>

On Tue, 24 Jan 2023 22:12:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38:
> 
>> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm
>> 37: resource.wxl-file=WiX-Lokalisierungsdatei
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `de`?

Changed back similar to with zh_CN

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38:
> 
>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8
>> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB
>> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl
> 
> Shouldn't this be `ja`?

Changed back similar to with zh_CN

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:33:29 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:33:29 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
Message-ID: <uWum8tAJrTs5hLSFFUV1E67SZFZsqqAsHpCELrLIMaM=.d90513b3-c6af-43a5-bb37-2024bcfc3f70@github.com>

On Tue, 24 Jan 2023 22:14:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:
> 
>> 61: # written authorization of the copyright holder.
>> 62: 
>> 63: CNY=\uffe5
> 
> Do not remove this.

Added back. Thanks for catching this!

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From prr at openjdk.org  Tue Jan 24 22:44:13 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Jan 2023 22:44:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <gQ5g-MSzzcsErcy0NLkwj4OOYoilBeIRyRHnNlZzfFM=.05615d12-452b-4bab-89cf-9ed5ffb91510@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

Removing the trailing white space seems OK in the desktop resources.
I checked the base (English) version of the files and none of them have trailing white space so it seems unlikely it is significant.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Tue Jan 24 22:44:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 22:44:14 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
Message-ID: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>

On Tue, 24 Jan 2023 22:20:22 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:
>> 
>>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
>>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
>>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:
>> 
>> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations.
>> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place.
>
> OK, I can make the manual edit for this

This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.

I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.

Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From joehw at openjdk.org  Tue Jan 24 22:59:07 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Jan 2023 22:59:07 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <8IAAljdZ35sxC22s2SeFdCTX5xmx83YUFr8dwOYtXzA=.028e67c7-0969-4204-b843-0c0f2d79574f@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Marked as reviewed by joehw (Reviewer).

java.xml changes look good to me. Thanks.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Tue Jan 24 22:59:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
Message-ID: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>

On Tue, 24 Jan 2023 22:40:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> OK, I can make the manual edit for this
>
> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
> 
> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
> 
> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?

Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 22:59:08 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 22:59:08 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <LKDcz3RMflqdnDZ3x6w43Ze0_STq3iMJXMtqdu9HNUs=.52ffc835-ed19-457b-9788-3f3798e7e1bd@github.com>
 <udjE03vk_yctaqPPRo9TBHGxQ4j6j3pjO3h21WasMlU=.03434916-5c1b-4d44-a232-f43b4c928ec8@github.com>
 <asI2PH6xlHtgVW2Mj-E4puV5nna6IRYlNLeu2qIisXQ=.527599ac-16ce-41f1-bb92-263bb85b79f6@github.com>
 <CsAAVzIKnnz5XUpUrnwieoCon_IUB2AloJD3f088IQ0=.cafe7f9a-af56-4ed0-a57a-10ac66ba0958@github.com>
Message-ID: <l0IK6fz7xp_c34lMdRgzs570ED6G2oXQ-CZwZ9pU1XU=.7b1893fe-06c8-4a9c-acf1-00ec66245dc2@github.com>

On Tue, 24 Jan 2023 22:49:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped.
>> 
>> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space.
>> 
>> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`?
>
> Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm.

Ok I left this change out of my most recent update just in case. I addressed all the other comments I believe. Thanks!

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Tue Jan 24 22:59:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 22:59:12 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="de-de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="ja-jp" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">

Please revert the value of the `Culture` attribute.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the `Culture` attribute.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Tue Jan 24 23:06:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 24 Jan 2023 23:06:14 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:

> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
> 61: 
> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 

It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:

> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
> 193: 
> 194: main.plugin.category=\u7C7B\u522B 

Same as above.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Tue Jan 24 23:19:12 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 24 Jan 2023 23:19:12 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
Message-ID: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>

On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change localization codes. Add CNY back

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:

> 1: <?xml version = '1.0' encoding = 'utf-8'?>
> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">

Please revert the value of the Culture attribute.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:38:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:38:23 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v4]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <T2H6mU3enuaNrLKae6YLvpA313QW2F1gfnXOzKhYP20=.d188ea58-f00e-4782-a508-ba25ed9f8819@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/40291c61..fc32c37f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:56:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:56:23 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert culture attribute

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/fc32c37f..616b2502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03-04

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <NHJe4Mt27DnzPaNGgGPmBegrpITlHxclp91qKggg9Xg=.899a3122-736b-48d9-a564-f629ad1e3096@github.com>
Message-ID: <tro5Qie7pi8hcU2dfXbz7Ew2P5_UBRDcEhohq7MBBmc=.ccef1231-0bb4-457d-8f3c-78878c6e98bb@github.com>

On Tue, 24 Jan 2023 23:02:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62:
> 
>> 60: dedup-legal-notices.usage=\  --dedup-legal-notices [error-if-not-same-content]\n                            \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n                            error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n                            \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n                            \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002
>> 61: 
>> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E<pattern-list> 
> 
> It seems like the translation process added a space here, but it does not appear in the original. This should be removed.

Removed both instances of the extra trailing whitespace.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194:
> 
>> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 193: 
>> 194: main.plugin.category=\u7C7B\u522B 
> 
> Same as above.

Addressed as above

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:17 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:17 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <SYT5AGvWO_Miz8XToU091Kyt7GKfYd167UmiGFLjy6Q=.963f58d4-d913-4ab4-abd3-8bb9c10ae16a@github.com>
Message-ID: <wT1oblMLJ8pV6MGHIXybIcNIp71p6Gm4AT0VQgbfTzA=.06b8ac34-8d10-4e71-a596-b64f856c6b27@github.com>

On Tue, 24 Jan 2023 22:55:43 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="de" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="1252">
> 
> Please revert the value of the `Culture` attribute.

I resolved this for the German, Japanese, and Chinese files in the latest commit.

> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="ja" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="932">
> 
> Please revert the value of the `Culture` attribute.

Resolved in recent commit

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Tue Jan 24 23:59:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Jan 2023 23:59:19 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3]
In-Reply-To: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <HHFxP3-ycH0yH-P5XKXDvS5Zrvm5Ywjn7gfHH10GlSg=.bf635d7b-5cfc-4450-87a9-846d59ead8ed@github.com>
 <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com>
Message-ID: <oM9Wt1fwilca-26aYPtGk-oarvJai1SJ6UgYbfw2Yao=.c0ab676d-eeb8-4c8b-9219-20bd58c4b32c@github.com>

On Tue, 24 Jan 2023 23:16:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change localization codes. Add CNY back
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2:
> 
>> 1: <?xml version = '1.0' encoding = 'utf-8'?>
>> 2: <WixLocalization Culture="zh-CN" xmlns="http://schemas.microsoft.com/wix/2006/localization" Codepage="936">
> 
> Please revert the value of the Culture attribute.

Resolved in recent commit

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From asemenyuk at openjdk.org  Wed Jan 25 00:12:09 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Jan 2023 00:12:09 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <HxDebTNqUdnnPbK_vZ7sFzNng3LygKgZCCajLqQYoKY=.08357b3d-91d8-4871-9c14-f73053d8a7af@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

jpackage changes look good

-------------

Marked as reviewed by asemenyuk (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Wed Jan 25 00:17:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 00:17:26 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v5]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <csXgN_JLXVq_OrvSbpWuembZTZwLqWk_hGU0HYV-3yc=.8e23a644-0edf-4a4b-9533-727f667d2775@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.
> 
> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Abstract may throw NPE, static will throw, instance use @implspec
 - Add ImplNote for non-abstract instance methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/a8059d50..145c5929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=03-04

  Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From jlu at openjdk.org  Wed Jan 25 00:31:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 00:31:26 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v6]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <HMCvwGZfjCE-InWLv8N6PQY8Ey8d80nK30iY77WCcxM=.282e8c62-37df-41ed-b8a0-56de018e1165@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.
> 
> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Minor punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/145c5929..c26519b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From naoto at openjdk.org  Wed Jan 25 01:00:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 01:00:11 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v6]
In-Reply-To: <HMCvwGZfjCE-InWLv8N6PQY8Ey8d80nK30iY77WCcxM=.282e8c62-37df-41ed-b8a0-56de018e1165@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <HMCvwGZfjCE-InWLv8N6PQY8Ey8d80nK30iY77WCcxM=.282e8c62-37df-41ed-b8a0-56de018e1165@github.com>
Message-ID: <GHT0csgNk0heIlsUG9g0jDDUTFrBN1lG8L7c3MOcVzk=.0f32eb5e-5371-45af-9033-79251f2cfde0@github.com>

On Wed, 25 Jan 2023 00:31:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
>> 
>> TimeZone.getTimeZone(String ID)
>> TimeZone.setID(String ID)
>> TimeZone.inDaylightTime(Date date)
>> 
>> For example, 
>> 
>> 
>> String someID = null;
>> TimeZone tz1 = TimeZone.getTimeZone(someID);
>> ``` 
>> 
>> throws a `NullPointerException`
>> 
>> However this is not documented in the API docs in the form of a _throws:_ section.
>> 
>> This change updates the documentation to make this apparent.
>> 
>> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor punctuation

src/java.base/share/classes/java/util/TimeZone.java line 297:

> 295:      * the time zone object.
> 296:      * @param ID the new time zone ID.
> 297:      * @implSpec The default implementation throws a

Usually @implSpec follows the method description, apart from other tags. See https://openjdk.org/jeps/8068562

src/java.base/share/classes/java/util/TimeZone.java line 402:

> 400:      * @param style either {@link #LONG} or {@link #SHORT}
> 401:      * @param locale   the locale in which to supply the display name.
> 402:      * @implSpec The default implementation throws a

Same as above.

src/java.base/share/classes/java/util/TimeZone.java line 404:

> 402:      * @implSpec The default implementation throws a
> 403:      * {@code NullPointerException} if {@code ID} is {@code null}.
> 404:      * Additionally, an {@code IllegalArgumentException} will be thrown if

I'd concatenate these with "or". Also, I think `IllegalArgumentException` has higher priority in the case of both being null/invalid.

src/java.base/share/classes/java/util/TimeZone.java line 407:

> 405:      * {@code style} is invalid.
> 406:      * @return the human-readable name of this time zone in the given locale.
> 407:      * @throws IllegalArgumentException This method may throw a

a -> an

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From jlu at openjdk.org  Wed Jan 25 01:11:15 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 01:11:15 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <zEwbMCW5Eq8q0rv8_F8m2iddDj6z-QdBCfiT8w93Di0=.b0991198-41b8-4204-aafe-32bedd2974f7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by jlu (Author).

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From duke at openjdk.org  Wed Jan 25 02:20:12 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 25 Jan 2023 02:20:12 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v5]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <QlzNsXImzljQKqirSAjT-1-hLXeNglN5O9KMes6vMfQ=.6f15c55e-9137-4203-8fd9-eb9defc227e6@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons 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:

 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Address review comment
 - Remove whitespace
 - Fix wrong register usage
 - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7714f4ce...98728555

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/f9140f40..98728555

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=03-04

  Stats: 585 lines in 17 files changed: 93 ins; 440 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From jpai at openjdk.org  Wed Jan 25 06:22:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jan 2023 06:22:05 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v3]
In-Reply-To: <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
Message-ID: <64kjqqYiSOag9_4tIkdcTsN2N-IP0RJSwRVZuwPSK6M=.451fcf07-e94f-4445-9f1c-5bb139edc2d6@github.com>

On Tue, 24 Jan 2023 21:57:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more.

src/java.base/unix/classes/java/lang/ProcessImpl.java line 74:

> 72:     // Cache for JNU Charset. The encoding name is guaranteed
> 73:     // to be supported in this environment.
> 74:     static final Charset JNU_CHARSET = Charset.forName(StaticProperty.jnuEncoding());

Before the change in this PR, the `jnuCharset` used to fallback to `Charset.defaultCharset()`, if the `sun.jnu.encoding` value wasn't a legal charset or couldn't be loaded. 
On this line, we no longer do that. The comment, above this line, indicates that this is intentional. Looking at the code in `java.lang.System#initPhase1()`, the `sun.jnu.encoding` property value is updated to `UTF-8` if the previous value isn't a supported charset. That is done just before the `StaticProperty` class is referenced and loaded. Effectively, as noted in this comment, the `sun.jnu.encoding` would just have the right usable/supported value stored in `StaticProperty.jnuEncoding()` by the time we reach here. So this change looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From jpai at openjdk.org  Wed Jan 25 06:31:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jan 2023 06:31:04 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v3]
In-Reply-To: <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
Message-ID: <irGuDqexmpRAbTVYQVDC8CO7thkBEAvtE4xqD_SpYx8=.83ab6b55-50cf-47ee-8c73-ff5dd5c07e01@github.com>

On Tue, 24 Jan 2023 21:57:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more.

Hello Naoto,

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where Charset class was loaded/initialized at the phase 1 of the startup process. Since Charset depends on StaticProperty

>From the comment in that PR:

> That said, the change does highlight an issue in StaticProperty. where it calls Charset.defaultCharset(), which in turn will StaticProperty.FILE_ENCODING before that class is fully initialized.

Looking at the code in `Charset.defaultCharset()` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/charset/Charset.java#L651, I don't see it using `StaticProperty` class. Instead, it just queries the `System.getProperty()`. I don't see any other methods in `Charset` using `StaticProperty` either.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From alanb at openjdk.org  Wed Jan 25 07:45:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jan 2023 07:45:05 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v3]
In-Reply-To: <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
Message-ID: <avraKQSGssMhKoXvP772dockNlt0N2VUG5VuvlBlQ4k=.b7b9da4f-5a7e-4863-a4bd-0e7b446522c6@github.com>

On Tue, 24 Jan 2023 21:57:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more.

The change to StaticProperty to avoid calling out to Charset.defaultCharset from the initializer is good. However, the other part to that is the scenario in PR 12132 where the default Charset was accidentally located via the provider mechanism in JDK 9-17. If I read the changes correctly, that fragile scenario will come back. We have a couple of ways to avoid that, one being to ensure that defaultCharset is called before the boot layer is set. A simpler, and more reliable, would be to change Charset.defaultCharset to use StandardCharsets.charsetForName with the value of "file.encoding", and avoid the provider lookup completely.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From duke at openjdk.org  Wed Jan 25 08:20:13 2023
From: duke at openjdk.org (danielpeintner)
Date: Wed, 25 Jan 2023 08:20:13 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
Message-ID: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>

On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change German help of jar command

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:

> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus

Just because I stumbled over this commit. I think the line should be translated as follows:

`Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From sgehwolf at openjdk.org  Wed Jan 25 10:34:46 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 10:34:46 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v2]
In-Reply-To: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
Message-ID: <1MJa0S4r9whrusF9SS3yYhwtpE9za5hfV1LOpLDdRLg=.436498ac-e995-4210-9caa-1d7ac6e0de6d@github.com>

> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
> 
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)

Severin Gehwolf 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12118/files
  - new: https://git.openjdk.org/jdk/pull/12118/files/abd83cf3..abd83cf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12118/head:pull/12118

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Wed Jan 25 11:24:55 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 11:24:55 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
Message-ID: <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>

> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
> 
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8299858: [Metrics] Swap memory limit reported incorrectly when too large

-------------

Changes: https://git.openjdk.org/jdk/pull/12118/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=02
  Stats: 65 lines in 3 files changed: 62 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12118/head:pull/12118

PR: https://git.openjdk.org/jdk/pull/12118

From itakiguchi at openjdk.org  Wed Jan 25 12:15:04 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 25 Jan 2023 12:15:04 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <H5dR1wC91-aqAH9tzEhIb2D3me9BtLeWVRFhQIEKuB4=.972ce810-0bd8-448d-85ab-2c12336316a5@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
 <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
 <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
 <H5dR1wC91-aqAH9tzEhIb2D3me9BtLeWVRFhQIEKuB4=.972ce810-0bd8-448d-85ab-2c12336316a5@github.com>
Message-ID: <f15YxBbS9ZPUqqlBy9YKCv2XFtBf5A9FTXPMZrofPNU=.a21022fc-bb41-49e0-996b-5f8ab34e148b@github.com>

On Tue, 24 Jan 2023 12:51:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you know if there is any configuration on AIX that would derive Cp943C as the default charset? That is, are they running with -Dfile.encoding=Cp943C on the AIX systems or is it chosen by default. This goes to the question as to whether they just moving these applications to Linux and expecting the default charset to be the same.

In my understanding, my client uses `-Dfile.encoding=Cp943C` option on Japanese IBM-943 locale on AIX.
Default charset on Japanese IBM-943 locale with IBM Java8 and OpenJDK JDK11+ is x-IBM943C(Cp943C).
(We need to use `-Dfile.encoding=Cp943C` for OpenJDK JDK8.)
We never thought we could just move to Linux because of JEP-400. But we don't move the apps all at once to Linux.
We expected that we could change default charset by `-Dfile.encoding=Cp943C`, at least until Java8 EOS.

> Do you know which APIs they are using? We filled in the gaps many releases ago so that all APIs that do encoding/decoding allow the charset to be specified and I'm wondering why they don't use those.

We checked String.getByte()/new String(...)/Reader/Writer/ByteArrayOutputStream.toString()...
Is there good way to pick up which parts need to be fixed ?

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From pminborg at openjdk.org  Wed Jan 25 12:57:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 12:57:19 GMT
Subject: Integrated: 8300236: Use VarHandle access in Data(Input |
 Output)Stream classes
In-Reply-To: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
Message-ID: <C_G-H5K_5lfwJSEbtq1qceZsPTmDFXYDBvxlkT1Bu6A=.8c054e11-3ad6-418a-9383-02b86b75613a@github.com>

On Wed, 18 Jan 2023 16:34:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`

This pull request has now been integrated.

Changeset: 74e1a8bf
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74e1a8bfa852a55fb8e6e93e19e2999f4d23f959
Stats:     1720 lines in 12 files changed: 1065 ins; 560 del; 95 mod

8300236: Use VarHandle access in Data(Input | Output)Stream classes

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From asotona at openjdk.org  Wed Jan 25 13:14:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 25 Jan 2023 13:14:43 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v7]
In-Reply-To: <KxjDVaJU_aX3HL9SRr39iw-hBLrlNzq8pLUP_7Yad7I=.c6b0c338-669a-481c-af66-2cc4899cf3a0@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <cCJkKGiF9YEs_DrnEKfGMl-mVqkFFg17Frvz8mg0dfg=.74f27f83-f539-41e4-9691-46c9535aa442@github.com>
 <KxjDVaJU_aX3HL9SRr39iw-hBLrlNzq8pLUP_7Yad7I=.c6b0c338-669a-481c-af66-2cc4899cf3a0@github.com>
Message-ID: <PqrX61LrDF0RbyqW16OUNcscF1K2TwCM_zHFIqgVWSc=.4b2555aa-b633-4e4b-a44e-993db178d2e5@github.com>

On Thu, 12 Jan 2023 12:47:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removal of Preview.java and TransPatterns.java patch
>>    and enabled preview for java.base
>>  - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview
>
> make/modules/java.base/Java.gmk line 28:
> 
>> 26: DOCLINT += -Xdoclint:all/protected \
>> 27:     '-Xdoclint/package:java.*,javax.*'
>> 28: JAVAC_FLAGS += -XDstringConcat=inline
> 
> I think it makes more sense to just have a single `JAVAC_FLAGS` assignment line, not one per flag.

fixed, thanks

> make/modules/java.base/Java.gmk line 39:
> 
>> 37: 
>> 38: EXCLUDES += java/lang/doc-files
>> 39: EXCLUDES += jdk/classfile/snippet-files
> 
> ... and the same goes for the `EXCLUDES`. If the line gets longer than 80 chars, split it like the `COPY` line above.

fixed, thanks

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Jan 25 13:14:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 25 Jan 2023 13:14:43 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v8]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  merged JAVAC_FLAGS and EXCLUDES in Java.gmk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/c42dc3e4..2bfc2b1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=06-07

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From stuefe at openjdk.org  Wed Jan 25 13:17:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Jan 2023 13:17:08 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
Message-ID: <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>

On Wed, 25 Jan 2023 11:24:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>> 
>> Testing:
>> - [x] Container tests on linux x86_64 with cg v1
>> - [x] Container tests on linux x86_64 with cg v2
>> - [ ] GHA (seem to have had some infra issues, so re-running)
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8299858: [Metrics] Swap memory limit reported incorrectly when too large

Mostly good, small nits.

src/java.base/linux/native/libjava/CgroupMetrics.c line 44:

> 42: {
> 43:     jlong pages = sysconf(_SC_PHYS_PAGES);
> 44:     jlong page_size = sysconf(_SC_PAGESIZE);

Preexisting: Check or at least assert for error? sysconf could also signal "indeterminable" state beside an error. I cannot see how either one could happen with _SC_PHYS_PAGES or _SC_PAGESIZE, so an assert would probably be enough.
(I know you do an assert in java, but that has to be switched on explicitly - do we run tests with asserts enabled?)

src/java.base/linux/native/libjava/CgroupMetrics.c line 45:

> 43:     jlong pages = sysconf(_SC_PHYS_PAGES);
> 44:     jlong page_size = sysconf(_SC_PAGESIZE);
> 45:     return pages * page_size;

Preexisting, and theoretical nitpickery: I got curious when I saw this. What does sysconf return if a 32-bit VM runs on a large machine with >8Tb main memory and 4k pages? In that case, _SC_PHYS_PAGES would overflow the 32-bit long return type of sysconf.

src/java.base/linux/native/libjava/CgroupMetrics.c line 54:

> 52:     struct sysinfo si;
> 53:     sysinfo(&si);
> 54:     return (jlong)si.totalswap;

If sysinfo fails, we return a random value.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Wed Jan 25 13:25:07 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 13:25:07 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
Message-ID: <NuLY85HlACElsu9t5lD8iWfTvNsulEX10i_O7d1V0uI=.2df92e2b-00b3-4885-af14-20ee07ae5edf@github.com>

On Wed, 25 Jan 2023 13:05:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8299858: [Metrics] Swap memory limit reported incorrectly when too large
>
> src/java.base/linux/native/libjava/CgroupMetrics.c line 45:
> 
>> 43:     jlong pages = sysconf(_SC_PHYS_PAGES);
>> 44:     jlong page_size = sysconf(_SC_PAGESIZE);
>> 45:     return pages * page_size;
> 
> Preexisting, and theoretical nitpickery: I got curious when I saw this. What does sysconf return if a 32-bit VM runs on a large machine with >8Tb main memory and 4k pages? In that case, _SC_PHYS_PAGES would overflow the 32-bit long return type of sysconf.

Yes. Any suggestions as to how to fix it? This code was actually changed recently with [JDK-8300119](https://bugs.openjdk.org/browse/JDK-8300119). Anyway, this should go into a separate bug if we change it. Do you agree?

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Wed Jan 25 13:32:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 13:32:08 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
Message-ID: <MuLkpSC6r7eeSaUdmCAkwL3n4Z_2P3MpoYth0FD2p6M=.85c812f4-a0c9-44e8-b96f-f2107b4d1d17@github.com>

On Wed, 25 Jan 2023 13:08:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> (I know you do an assert in java, but that has to be switched on explicitly - do we run tests with asserts enabled?)

Yes. That's why `-esa` is being added here:
https://github.com/openjdk/jdk/pull/12118/files#diff-597a72f91945acae784afe2610925a1da491f138eec44b98cb630414dac9cc76R204

I'll fix the other pre-existing issues you point out in another bug.

> src/java.base/linux/native/libjava/CgroupMetrics.c line 54:
> 
>> 52:     struct sysinfo si;
>> 53:     sysinfo(&si);
>> 54:     return (jlong)si.totalswap;
> 
> If sysinfo fails, we return a random value.

Makes sense. I think returning `0` (no swap) might be reasonable if it fails. I'll update.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From amaembo at gmail.com  Wed Jan 25 13:41:41 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 25 Jan 2023 14:41:41 +0100
Subject: Math.clamp method?
Message-ID: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>

Hello!

Quite often it's necessary to clamp a numerical value to a given
range, using the algorithm like this:
int clampedValue = value > max ? max : value < min ? min : value;
or probably
int clampedValue = Math.max(min, Math.min(max, value));
Some examples in wild: [1] [2]

These "algorithms" are verbose and error-prone. E.g., many years ago
Math.max and Math.min were mixed in Jenkins CI implementation (later
fixed in [3]). Static analyzers like SonarLint even implement a rule
to catch such kind of mistake [4], but it cannot statically find a
mistake if max and min values are not constant.

Having a library method for this algorithm will make the code more
readable, and robust. Standard libraries of various languages tend to
implement a function that encapsulates this algorithm. E.g., Kotlin
coerseIn [5], C# Math.Clamp [6], Rust num::clamp [7].

I hereby propose to add a similar method to Java Math class. The
signatures could be:
public static int clamp(int value, int min, int max)
public static long clamp(long value, long min, long max)
public static double clamp(double value, double min, double max)
public static float clamp(float value, float min, float max)

These methods should additionally check that min is not greater than
max (throwing IllegalArgumentException). Probably IAE should be thrown
as well if either min or max is NaN for floating point methods. It can
be discussed what should happen if the value is NaN (I think returning
NaN would be ok, but throwing an exception is also a possibility).

I can post CSR and contribute the implementation if Core Library team
members agree that it's a good idea.

With best regards,
Tagir Valeev.

[1] https://github.com/moneymod/moneymod/blob/4d2c7f5be40dbf392e75/src/main/java/wtf/moneymod/client/impl/ui/click/buttons/settings/SliderButton.java#L71
[2] https://github.com/androidthings/experiment-expression-flower/blob/f0fd6090e0df1659bad/code/app/src/main/java/com/example/androidthings/VideoProcessor.java#L559
[3] https://github.com/jenkinsci/jenkins/commit/e00f99251e0b
[4] https://rules.sonarsource.com/java/RSPEC-3065
[5] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/coerce-in.html
[6] https://learn.microsoft.com/en-us/dotnet/api/system.math.clamp?view=net-7.0
[7] https://docs.rs/num/0.2.1/num/fn.clamp.html

From lancea at openjdk.org  Wed Jan 25 13:45:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Jan 2023 13:45:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <DhnLBlhufb7h62qL0BwYg-_kg8ttfCWuViNBhrYhAcs=.88b29cf5-12bd-4cac-9d43-b0b123d0c1b4@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From sgehwolf at openjdk.org  Wed Jan 25 13:45:28 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 13:45:28 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v4]
In-Reply-To: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
Message-ID: <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>

> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
> 
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Do proper error checking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12118/files
  - new: https://git.openjdk.org/jdk/pull/12118/files/346ddc84..f0b6818e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12118&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12118/head:pull/12118

PR: https://git.openjdk.org/jdk/pull/12118

From james.laskey at oracle.com  Wed Jan 25 13:50:20 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 25 Jan 2023 13:50:20 +0000
Subject: Math.clamp method?
In-Reply-To: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
Message-ID: <8FA36A33-501E-4A2E-AC4C-0F80BEDB3EB4@oracle.com>

+1

> On Jan 25, 2023, at 9:41 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> Quite often it's necessary to clamp a numerical value to a given
> range, using the algorithm like this:
> int clampedValue = value > max ? max : value < min ? min : value;
> or probably
> int clampedValue = Math.max(min, Math.min(max, value));
> Some examples in wild: [1] [2]
> 
> These "algorithms" are verbose and error-prone. E.g., many years ago
> Math.max and Math.min were mixed in Jenkins CI implementation (later
> fixed in [3]). Static analyzers like SonarLint even implement a rule
> to catch such kind of mistake [4], but it cannot statically find a
> mistake if max and min values are not constant.
> 
> Having a library method for this algorithm will make the code more
> readable, and robust. Standard libraries of various languages tend to
> implement a function that encapsulates this algorithm. E.g., Kotlin
> coerseIn [5], C# Math.Clamp [6], Rust num::clamp [7].
> 
> I hereby propose to add a similar method to Java Math class. The
> signatures could be:
> public static int clamp(int value, int min, int max)
> public static long clamp(long value, long min, long max)
> public static double clamp(double value, double min, double max)
> public static float clamp(float value, float min, float max)
> 
> These methods should additionally check that min is not greater than
> max (throwing IllegalArgumentException). Probably IAE should be thrown
> as well if either min or max is NaN for floating point methods. It can
> be discussed what should happen if the value is NaN (I think returning
> NaN would be ok, but throwing an exception is also a possibility).
> 
> I can post CSR and contribute the implementation if Core Library team
> members agree that it's a good idea.
> 
> With best regards,
> Tagir Valeev.
> 
> [1] https://github.com/moneymod/moneymod/blob/4d2c7f5be40dbf392e75/src/main/java/wtf/moneymod/client/impl/ui/click/buttons/settings/SliderButton.java#L71
> [2] https://github.com/androidthings/experiment-expression-flower/blob/f0fd6090e0df1659bad/code/app/src/main/java/com/example/androidthings/VideoProcessor.java#L559
> [3] https://github.com/jenkinsci/jenkins/commit/e00f99251e0b
> [4] https://rules.sonarsource.com/java/RSPEC-3065
> [5] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/coerce-in.html
> [6] https://learn.microsoft.com/en-us/dotnet/api/system.math.clamp?view=net-7.0
> [7] https://docs.rs/num/0.2.1/num/fn.clamp.html


From ihse at openjdk.org  Wed Jan 25 13:56:21 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Jan 2023 13:56:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <-Mjbn1ko2InJOzXLccieEzU8h4bypdm9vTzHdmtA-JQ=.2e1f4d59-e30e-434a-8e62-25777adb3a07@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

I skimmed through this, basically looking for trailing white space changes only, and it generally looks okay.

Note that some of these trailing whitespace fixes has been independently address in mainline. Forward-porting this might involve some (virtual) conflicts.

It is also impossible to see in the Github interface if you are introducing *new* trailing white spaces in the added texts. I hope you are not, and that you have verified this.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From stuefe at openjdk.org  Wed Jan 25 14:01:06 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Jan 2023 14:01:06 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v4]
In-Reply-To: <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
Message-ID: <9Ae_nNFG1FiAHA3RncVDWrLGKTDW5AGJdN0-gYjsK4k=.f975bcbb-a1ec-462f-bb46-b242b4a6ad0c@github.com>

On Wed, 25 Jan 2023 13:45:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>> 
>> Testing:
>> - [x] Container tests on linux x86_64 with cg v1
>> - [x] Container tests on linux x86_64 with cg v2
>> - [ ] GHA (seem to have had some infra issues, so re-running)
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do proper error checking

Good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Wed Jan 25 14:01:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 14:01:08 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
Message-ID: <pKlrgmxNUXnsMAxrIFIu2Ovu_u0oaapsgYvRSCZXdyM=.4ff1f804-3608-4e27-b710-aaf4fc855e7f@github.com>

On Wed, 25 Jan 2023 13:14:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Mostly good, small nits.

Thanks for the review, @tstuefe! I've updated the patch. Please let me know if you want me to change anything else.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From stuefe at openjdk.org  Wed Jan 25 14:01:12 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Jan 2023 14:01:12 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <NuLY85HlACElsu9t5lD8iWfTvNsulEX10i_O7d1V0uI=.2df92e2b-00b3-4885-af14-20ee07ae5edf@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
 <NuLY85HlACElsu9t5lD8iWfTvNsulEX10i_O7d1V0uI=.2df92e2b-00b3-4885-af14-20ee07ae5edf@github.com>
Message-ID: <4NFW7tEUg6ZuEWum1ZLM5ddR7ixiryybT6JyuSYiXIw=.82893a86-391d-4af9-a05c-df752cfccb22@github.com>

On Wed, 25 Jan 2023 13:22:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/native/libjava/CgroupMetrics.c line 45:
>> 
>>> 43:     jlong pages = sysconf(_SC_PHYS_PAGES);
>>> 44:     jlong page_size = sysconf(_SC_PAGESIZE);
>>> 45:     return pages * page_size;
>> 
>> Preexisting, and theoretical nitpickery: I got curious when I saw this. What does sysconf return if a 32-bit VM runs on a large machine with >8Tb main memory and 4k pages? In that case, _SC_PHYS_PAGES would overflow the 32-bit long return type of sysconf.
>
> Yes. Any suggestions as to how to fix it? This code was actually changed recently with [JDK-8300119](https://bugs.openjdk.org/browse/JDK-8300119). Anyway, this should go into a separate bug if we change it. Do you agree?

I honestly have no idea of how to fix it. A separate RFE would be fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From stuefe at openjdk.org  Wed Jan 25 14:02:06 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Jan 2023 14:02:06 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v4]
In-Reply-To: <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
Message-ID: <9Ae_nNFG1FiAHA3RncVDWrLGKTDW5AGJdN0-gYjsK4k=.73d6341e-8aef-4234-be8c-f03b917340e9@github.com>

On Wed, 25 Jan 2023 13:45:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>> 
>> Testing:
>> - [x] Container tests on linux x86_64 with cg v1
>> - [x] Container tests on linux x86_64 with cg v2
>> - [ ] GHA (seem to have had some infra issues, so re-running)
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do proper error checking

Good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Wed Jan 25 14:02:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 25 Jan 2023 14:02:09 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
Message-ID: <pKlrgmxNUXnsMAxrIFIu2Ovu_u0oaapsgYvRSCZXdyM=.d5ce3332-364d-4d5f-8240-474ec24fbe20@github.com>

On Wed, 25 Jan 2023 13:14:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Mostly good, small nits.

Thanks for the review, @tstuefe! I've updated the patch. Please let me know if you want me to change anything else.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From stuefe at openjdk.org  Wed Jan 25 14:02:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Jan 2023 14:02:13 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v3]
In-Reply-To: <NuLY85HlACElsu9t5lD8iWfTvNsulEX10i_O7d1V0uI=.2df92e2b-00b3-4885-af14-20ee07ae5edf@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <ZW7kcT-HXc43hqxHsaKs97r1IWjqFbgXhWdvdMn2MSI=.cd56e997-a775-40c3-8efe-1cabc1e73613@github.com>
 <4HzOimBmY0gZmiQghLbuLsQ99KF5wCFF251okEIQJnc=.ac696a7b-7f17-4eea-b8a7-183eb07b1d41@github.com>
 <NuLY85HlACElsu9t5lD8iWfTvNsulEX10i_O7d1V0uI=.2df92e2b-00b3-4885-af14-20ee07ae5edf@github.com>
Message-ID: <4NFW7tEUg6ZuEWum1ZLM5ddR7ixiryybT6JyuSYiXIw=.8785ae16-6b36-447a-b5bc-fa568072bb6f@github.com>

On Wed, 25 Jan 2023 13:22:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/native/libjava/CgroupMetrics.c line 45:
>> 
>>> 43:     jlong pages = sysconf(_SC_PHYS_PAGES);
>>> 44:     jlong page_size = sysconf(_SC_PAGESIZE);
>>> 45:     return pages * page_size;
>> 
>> Preexisting, and theoretical nitpickery: I got curious when I saw this. What does sysconf return if a 32-bit VM runs on a large machine with >8Tb main memory and 4k pages? In that case, _SC_PHYS_PAGES would overflow the 32-bit long return type of sysconf.
>
> Yes. Any suggestions as to how to fix it? This code was actually changed recently with [JDK-8300119](https://bugs.openjdk.org/browse/JDK-8300119). Anyway, this should go into a separate bug if we change it. Do you agree?

I honestly have no idea of how to fix it. A separate RFE would be fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From forax at univ-mlv.fr  Wed Jan 25 14:15:13 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 25 Jan 2023 15:15:13 +0100 (CET)
Subject: Math.clamp method?
In-Reply-To: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
Message-ID: <820061872.5079210.1674656113573.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, January 25, 2023 2:41:41 PM
> Subject: Math.clamp method?

> Hello!
> 
> Quite often it's necessary to clamp a numerical value to a given
> range, using the algorithm like this:
> int clampedValue = value > max ? max : value < min ? min : value;
> or probably
> int clampedValue = Math.max(min, Math.min(max, value));
> Some examples in wild: [1] [2]
> 
> These "algorithms" are verbose and error-prone. E.g., many years ago
> Math.max and Math.min were mixed in Jenkins CI implementation (later
> fixed in [3]). Static analyzers like SonarLint even implement a rule
> to catch such kind of mistake [4], but it cannot statically find a
> mistake if max and min values are not constant.
> 
> Having a library method for this algorithm will make the code more
> readable, and robust. Standard libraries of various languages tend to
> implement a function that encapsulates this algorithm. E.g., Kotlin
> coerseIn [5], C# Math.Clamp [6], Rust num::clamp [7].
> 
> I hereby propose to add a similar method to Java Math class. The
> signatures could be:
> public static int clamp(int value, int min, int max)
> public static long clamp(long value, long min, long max)
> public static double clamp(double value, double min, double max)
> public static float clamp(float value, float min, float max)
> 
> These methods should additionally check that min is not greater than
> max (throwing IllegalArgumentException). Probably IAE should be thrown
> as well if either min or max is NaN for floating point methods. It can
> be discussed what should happen if the value is NaN (I think returning
> NaN would be ok, but throwing an exception is also a possibility).
> 
> I can post CSR and contribute the implementation if Core Library team
> members agree that it's a good idea.

I remember John Rose talking about something very similar to this proposal, there is maybe already a bug for it.

Given that the semantics of NaN is clearly defined for Math.max/min (if one of the values is NaN the result is NaN),
I don't believe we need a special case here for NaN.

The semantics should be, this is equivalent to execute
  Math.max(min, Math.min(max, value))

So clamp(double) can be implemented using minsd and maxsd on x64, which is already what the VM does.

> 
> With best regards,
> Tagir Valeev.

regards,
R?mi

> 
> [1]
> https://github.com/moneymod/moneymod/blob/4d2c7f5be40dbf392e75/src/main/java/wtf/moneymod/client/impl/ui/click/buttons/settings/SliderButton.java#L71
> [2]
> https://github.com/androidthings/experiment-expression-flower/blob/f0fd6090e0df1659bad/code/app/src/main/java/com/example/androidthings/VideoProcessor.java#L559
> [3] https://github.com/jenkinsci/jenkins/commit/e00f99251e0b
> [4] https://rules.sonarsource.com/java/RSPEC-3065
> [5] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/coerce-in.html
> [6] https://learn.microsoft.com/en-us/dotnet/api/system.math.clamp?view=net-7.0
> [7] https://docs.rs/num/0.2.1/num/fn.clamp.html

From pminborg at openjdk.org  Wed Jan 25 14:17:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 14:17:07 GMT
Subject: Integrated: 8301086: jdk/internal/util/ByteArray/ReadWriteValues.java
 fails with CompilationError
Message-ID: <-uANgvyuKyHArWG44mYl3AVDG6dT3UqhtIjydAEigyM=.fb99538d-11ce-440a-ae5c-bb7421628033@github.com>

This PR suggests the removal of certain faulty tests.

-------------

Commit messages:
 - Remove faulty tests

Changes: https://git.openjdk.org/jdk/pull/12196/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301086
  Stats: 142 lines in 1 file changed: 0 ins; 142 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12196.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12196/head:pull/12196

PR: https://git.openjdk.org/jdk/pull/12196

From pminborg at openjdk.org  Wed Jan 25 14:17:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 14:17:10 GMT
Subject: Integrated: 8301086: jdk/internal/util/ByteArray/ReadWriteValues.java
 fails with CompilationError
In-Reply-To: <-uANgvyuKyHArWG44mYl3AVDG6dT3UqhtIjydAEigyM=.fb99538d-11ce-440a-ae5c-bb7421628033@github.com>
References: <-uANgvyuKyHArWG44mYl3AVDG6dT3UqhtIjydAEigyM=.fb99538d-11ce-440a-ae5c-bb7421628033@github.com>
Message-ID: <rXZCZpyazZ7ruWw-xRcrln9l9mnIqlNrwieQKm3yqss=.693c1a25-9391-4317-bb00-8dd693f6b9c7@github.com>

On Wed, 25 Jan 2023 14:02:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests the removal of certain faulty tests.

This pull request has now been integrated.

Changeset: a23ff63a
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a23ff63af147067e0704970a9f9e6d847df22dff
Stats:     142 lines in 1 file changed: 0 ins; 142 del; 0 mod

8301086: jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/12196

From dfuchs at openjdk.org  Wed Jan 25 14:17:09 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Jan 2023 14:17:09 GMT
Subject: Integrated: 8301086:
 jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError
In-Reply-To: <-uANgvyuKyHArWG44mYl3AVDG6dT3UqhtIjydAEigyM=.fb99538d-11ce-440a-ae5c-bb7421628033@github.com>
References: <-uANgvyuKyHArWG44mYl3AVDG6dT3UqhtIjydAEigyM=.fb99538d-11ce-440a-ae5c-bb7421628033@github.com>
Message-ID: <5jwyg1Ii_7LPF_0nMR8-aIrlrZDJ7I0_rAswx_bp9TM=.89766e81-44e0-43fc-b9d6-8363eb2f0d20@github.com>

On Wed, 25 Jan 2023 14:02:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests the removal of certain faulty tests.

LGTM provided that the test passes with these changes.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12196

From ihse at openjdk.org  Wed Jan 25 15:18:03 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Jan 2023 15:18:03 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v8]
In-Reply-To: <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>
Message-ID: <XBN3F7nbctbFt5AOOCsPwDoFyl0nH_54i1vTEhmyF1s=.fac69f21-4211-469a-953c-baefe5026dbe@github.com>

On Wed, 25 Jan 2023 13:14:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merged JAVAC_FLAGS and EXCLUDES in Java.gmk

Build changes look fine now!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Wed Jan 25 15:18:53 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 25 Jan 2023 15:18:53 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32
Message-ID: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>

Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

-------------

Commit messages:
 - Updated copyright
 - Add benchmark for CRC32

Changes: https://git.openjdk.org/jdk/pull/12199/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301092
  Stats: 61 lines in 1 file changed: 61 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12199.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12199/head:pull/12199

PR: https://git.openjdk.org/jdk/pull/12199

From ecaspole at openjdk.org  Wed Jan 25 15:43:16 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 25 Jan 2023 15:43:16 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32
In-Reply-To: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
Message-ID: <tbrci3AdCW6O2kEEgUs3HoTi0YyJXfNoC2eFnL7bLp0=.31ef35cf-43d7-41a2-9b30-1e19fc189eb6@github.com>

On Wed, 25 Jan 2023 15:03:05 GMT, Scott Gibbons <duke at openjdk.org> wrote:

> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

Looks good to me, thanks!

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.org/jdk/pull/12199

From naoto at openjdk.org  Wed Jan 25 16:55:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 16:55:04 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <cAC0d_Qt7wDZq7kMDzQPm2QO8NrgIF5XMMvxq4Bhcc4=.131687a3-5000-4bee-af43-05d577b19748@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 17:36:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:36:38 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <_THK1t7SrTRqoW0o0gfgmCo1Ea1WfgdfeB7jNJDKUKk=.05512373-8cb2-41d3-a71f-589075240bb7@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:

> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}

While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.

There should be a general rule on which style we should use throughout all display messages.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 17:47:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:47:19 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v6]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <X62CFfqZcV_yEfImnVmu3ZoHI5P2xChVA-ky8AgsYBA=.07cc648b-7d60-4188-89d9-c6254d2ce023@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert translated punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/616b2502..4222df9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 17:51:20 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 17:51:20 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert one more punctuation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/4222df9a..9a5b45a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 17:52:21 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 17:52:21 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
Message-ID: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>

On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert culture attribute

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:

> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B

Should `exception-type` be translated?

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 18:03:54 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 18:03:54 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
Message-ID: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>

On Wed, 25 Jan 2023 17:49:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert culture attribute
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
> 
>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
> 
> Should `exception-type` be translated?

The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
> 
>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
> 
> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
> 
> There should be a general rule on which style we should use throughout all display messages.

Updated the punctuation (colons and comma) to be more consistent throughout the file.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From weijun at openjdk.org  Wed Jan 25 18:03:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:03:55 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
Message-ID: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>

On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113:
>> 
>>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc
>>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0}
>>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B
>> 
>> Should `exception-type` be translated?
>
> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.

I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

>> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32:
>> 
>>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1}
>>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0}
>>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1}
>> 
>> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style.
>> 
>> There should be a general rule on which style we should use throughout all display messages.
>
> Updated the punctuation (colons and comma) to be more consistent throughout the file.

Looks good now.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From jlu at openjdk.org  Wed Jan 25 18:12:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 18:12:10 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v7]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> However this is not documented in the API docs in the form of a _throws:_ section.
> 
> This change updates the documentation to make this apparent.
> 
> Aditionally, updates the javadoc of SimpleTimeZone.inDaylightTime(Date date) to inherit the _ at throws:_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust ImplSpec positioning and wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/c26519b4..106624a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=05-06

  Stats: 10 lines in 1 file changed: 4 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From jlu at openjdk.org  Wed Jan 25 18:12:15 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 18:12:15 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v6]
In-Reply-To: <GHT0csgNk0heIlsUG9g0jDDUTFrBN1lG8L7c3MOcVzk=.0f32eb5e-5371-45af-9033-79251f2cfde0@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <HMCvwGZfjCE-InWLv8N6PQY8Ey8d80nK30iY77WCcxM=.282e8c62-37df-41ed-b8a0-56de018e1165@github.com>
 <GHT0csgNk0heIlsUG9g0jDDUTFrBN1lG8L7c3MOcVzk=.0f32eb5e-5371-45af-9033-79251f2cfde0@github.com>
Message-ID: <r2Lpq_ZVC5qTkC3W5kK3JhZ8F7lWaEMjGLC-USPNxZM=.1d5dfe8d-b00d-4a8f-84cb-b3570b41bc9f@github.com>

On Wed, 25 Jan 2023 00:50:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor punctuation
>
> src/java.base/share/classes/java/util/TimeZone.java line 297:
> 
>> 295:      * the time zone object.
>> 296:      * @param ID the new time zone ID.
>> 297:      * @implSpec The default implementation throws a
> 
> Usually @implSpec follows the method description, apart from other tags. See https://openjdk.org/jeps/8068562

Thanks, will reference this for future use of javadoc tags

> src/java.base/share/classes/java/util/TimeZone.java line 404:
> 
>> 402:      * @implSpec The default implementation throws a
>> 403:      * {@code NullPointerException} if {@code ID} is {@code null}.
>> 404:      * Additionally, an {@code IllegalArgumentException} will be thrown if
> 
> I'd concatenate these with "or". Also, I think `IllegalArgumentException` has higher priority in the case of both being null/invalid.

Swapped the priority, and improved the wording

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From duke at openjdk.org  Wed Jan 25 18:19:52 2023
From: duke at openjdk.org (altrisi)
Date: Wed, 25 Jan 2023 18:19:52 GMT
Subject: RFR: 8300236: Use VarHandle access in Data(Input | Output)Stream
 classes [v8]
In-Reply-To: <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
References: <0H0YZ1us8eLP8bkZxuU-gd9AkCfx3lyReeRXtiSQMLI=.6874fb44-b353-4bbd-8776-0c7d9f8ec7ff@github.com>
 <OkmUumWJzwtBJnEeVqHfPrquOaDUxZtKgiKLQn54XGI=.b6529695-43ad-4009-a720-9f08ea124644@github.com>
Message-ID: <T51yVa29tWic9sjNdcke3g3bjtdImoUcrnaVdeF3YSI=.2f3f82bc-a2ff-4d8d-9201-2289f9c04a86@github.com>

On Tue, 24 Jan 2023 12:44:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a performance optimization using a new supported API for operations similar to those found in `java.io.Bits`
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update RAF

Not fully related to this PR, but is there a reason that functionality was exposed as a VarHandle factory instead of just methods that do that, taking an array and an index?

These byte array handles don't seem to have much state in them other than endianness, that could just be passed in (improving `8300235` further), removing the need here for a class holding them and the indirection.

-------------

PR: https://git.openjdk.org/jdk/pull/12076

From duke at openjdk.org  Wed Jan 25 18:24:31 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 25 Jan 2023 18:24:31 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v10]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <EYZ0PKhJSpBN9TNV2h37OjCx4pCVQ0_fZQowE3plrh4=.d31043c3-0bdd-43df-90f4-f5c2ecb9a50a@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp 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 18 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into fix-8240567
   
   * upstream/master: (348 commits)
     8300592: ASan build does not correctly propagate options to some test launchers
     8299635: Hotspot update for deprecated sprintf in Xcode 14
     8300805: Update autoconf build-aux files with latest from 2022-09-17
     8301086: jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError
     8300997: Add curl support to createJMHBundle.sh
     8295944: Move the Http2TestServer and related classes into a package of its own
     8301004: httpclient: Add more debug to HttpResponseInputStream
     8300236: Use VarHandle access in Data(Input | Output)Stream classes
     8300244: Replace NULL with nullptr in share/interpreter/
     8300651: Replace NULL with nullptr in share/runtime/
     8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values
     8300657: Remove null filtering in CLD oop handle area
     8300644: Remove gc/shenandoah/jni/TestStringCriticalWithDedup.java
     8297730: C2: Arraycopy intrinsic throws incorrect exception
     6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE.
     8300830: Remove redundant assertion in src/hotspot/share/runtime/javaCalls.cpp
     8300981: Build failure on 32-bit platforms after JDK-8281213
     8300272: Improve readability of the test JarWithOneNonDisabledDigestAlg
     8300942: JDK-8299684 breaks x86 build
     8300769: Remove G1CollectionSet::_inc_bytes_used_before
     ...
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
   
   * upstream/master:
     8298601: Refactor archiving of java.lang.Module objects
     7030853: JDK 7 Serializable Swing classes not compatible with JDK 6
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
   
   * upstream/master:
     8299378: sprintf is deprecated in Xcode 14
     8299520: TestPrintXML.java output error messages in case compare fails
     8294526: sun/security/provider/SubjectCodeSource.java no longer referenced
     8291302: ARM32: nmethod entry barriers support
     8299437: Make InetSocketAddressHolder shallowly immutable
     8299395: Remove metaprogramming/removeCV.hpp
     8288204: GVN Crash: assert() failed: correct memory chain
     8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames
     8299441: Fix typos in some test files under core-libs component
     8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java
     8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics
 - Merge branch 'fix-8240567' of github.com:JabRef/jdk into fix-8240567
   
   * 'fix-8240567' of github.com:JabRef/jdk:
     More recursion
     8299030: Refactor ReservedSpace::reserve
     8299397: Remove metaprogramming/isFloatingPoint.hpp
     8299399: Remove metaprogramming/isArray.hpp
     8299396: Remove metaprogramming/removeExtent.hpp
     8299402: Remove metaprogramming/isVolatile.hpp
     8298652: G1: Refactor G1MarkAndPushClosure
     8299193: (bf) Buffer.capacity should be declared final
     8299187: (bf) ByteOrder.name should be declared final
     8298590: Refactor LambdaForm constructors
     8299398: Remove metaprogramming/isConst.hpp
     8299424: containers/docker/TestMemoryWithCgroupV1.java fails on SLES12 ppc64le when testing Memory and Swap Limit
     6257207: JTable.getDefaultEditor throws NullPointerException
     4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native
     8299388: java/util/regex/NegativeArraySize.java fails on Alpine and sometimes Windows
     8299260: libawt and libfreetype should export only explicitly requested symbols
     8299387: CompressedClassPointers.java still fails on ppc with 'Narrow klass shift: 0' missing
     8235297: sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent
 - More recursion
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
 - Merge remote-tracking branch 'origin/master' into fix-8240567
 - Merge remote-tracking branch 'origin/master' into fix-8240567
   
   * origin/master: (68 commits)
     8298875: A module requiring "java.base" with flags ACC_SYNTHETIC should be rejected
     8288204: GVN Crash: assert() failed: correct memory chain
     8299255: Unexpected round errors in FreetypeFontScaler
     8298645: JNI works with accessibleSelection on a wrong thread
     8298643: JNI call of getAccessibleRowWithIndex and getAccessibleColumnWithIndex on a wrong thread
     8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file
     8299172: RISC-V: [TESTBUG] Fix stack alignment logic in jvmci RISCV64TestAssembler.java
     8299168: RISC-V: Fix MachNode size mismatch for MacroAssembler::_verify_oops*
     8299237: add ArraysSupport.newLength test to a test group
     8286311: remove boilerplate from use of runTests
     8299194: CustomTzIDCheckDST.java may fail at future date
     8292206: TestCgroupMetrics.java fails as getMemoryUsage() is lower than expected
     8299199: Avoid redundant split calls in FontConfiguration.initReorderMap implementations
     8299191: Unnecessarily global friend functions for relocInfo
     8295087: Manual Test to Automated Test Conversion
     8299230: Use https: in links
     8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes
     8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java
     8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears
     8298887: On the latest macOS+XCode the Robot API may report wrong colors
     ...
 - Refine tests
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>
 - Revert to original SystemModulesPlugin
   
   Co-authored-by: Christoph <siedlerkiller at gmail.com>
   Co-authored-by: Carl Christian Snethlage <50491877+calixtus at users.noreply.github.com>
 - Merge remote-tracking branch 'origin/master' into fix-8240567
 - ... and 8 more: https://git.openjdk.org/jdk/compare/d58c2366...e73760ca

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/ede0e87f..e73760ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=08-09

  Stats: 48380 lines in 2033 files changed: 23815 ins; 11402 del; 13163 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From jjg at openjdk.org  Wed Jan 25 18:24:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 18:24:55 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <J-ty6TMfR4ldx_S-L65JWYllWC1ZHnF_ongCEJBxtxI=.aca2e3d7-6b87-4bd0-ab84-ca75ee3ce007@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

I don't see anything absurdly wrong in the jdk.compiler files.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From naoto at openjdk.org  Wed Jan 25 18:45:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 18:45:04 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use standardProvider to determine the default charset

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/23ed827c..5c37f5bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Wed Jan 25 18:48:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 18:48:44 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
Message-ID: <7b3pYFpBTKBsf-WXMJ0SIrm1hUWBZTuyF8pz_pgIBrI=.46398ec6-9057-4278-8070-85a86f3178e6@github.com>

On Wed, 25 Jan 2023 18:45:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use standardProvider to determine the default charset

`Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From weijun at openjdk.org  Wed Jan 25 18:58:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 25 Jan 2023 18:58:57 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7]
In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com>
Message-ID: <v7uEXriAXWk-hzpE3-k1fiiPitnlhkkN1gkTMXFQ9Yg=.951f83bf-79b3-4270-981f-140e84b68fb9@github.com>

On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert one more punctuation

zh_cn translations look fine. Thanks.

-------------

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/116

From alanb at openjdk.org  Wed Jan 25 19:01:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jan 2023 19:01:44 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <7b3pYFpBTKBsf-WXMJ0SIrm1hUWBZTuyF8pz_pgIBrI=.46398ec6-9057-4278-8070-85a86f3178e6@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
 <7b3pYFpBTKBsf-WXMJ0SIrm1hUWBZTuyF8pz_pgIBrI=.46398ec6-9057-4278-8070-85a86f3178e6@github.com>
Message-ID: <07ZoLE0pwp1mHpp79O80BfH-o8mF_o-vRAlvkIn-I5o=.afd8b5ec-a94a-4dea-ac13-946f2768bbff@github.com>

On Wed, 25 Jan 2023 18:45:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.

I think this is the right thing to do. It can also be changed to use StaticProperty.fileEncoding() and maybe the field can be changed to be a `@Stable` field. 

It might be that we will need to create a CSR and Release Note for this change.  The scenario is PR 12132 is unfortunate but does not show that some deployments may have been relying on the this from JDK 9 to JDK 17. With the change here, we are doubling now on ensuring that the default charset is loaded from java.base.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From pminborg at openjdk.org  Wed Jan 25 19:05:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 19:05:29 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
Message-ID: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>

This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.

-------------

Commit messages:
 - Remove comments
 - Add little endian performance improvements
 - Use jdk.internal.util.ByteArray for pack/unpack

Changes: https://git.openjdk.org/jdk/pull/12204/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300235
  Stats: 279 lines in 5 files changed: 8 ins; 144 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/12204.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12204/head:pull/12204

PR: https://git.openjdk.org/jdk/pull/12204

From pminborg at openjdk.org  Wed Jan 25 19:05:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Jan 2023 19:05:30 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <buJ4qTEY6IvOIRZS0UXGg9dJenhMRnyP805OddlzhfM=.806d1e13-c651-42b2-b886-396382fe7253@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.

src/java.base/share/classes/module-info.java line 275:

> 273:     exports jdk.internal.util.random to
> 274:         jdk.random;
> 275:     exports jdk.internal.util to

Added coupling I am afraid.

-------------

PR: https://git.openjdk.org/jdk/pull/12204

From lancea at openjdk.org  Wed Jan 25 19:20:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Jan 2023 19:20:47 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v7]
In-Reply-To: <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>
Message-ID: <RzbGmNHEaTpAIOXWYKyAa1d3L6C9YcSeONN5sZWLNM8=.3226284e-de00-4d01-9149-72082c8c4cb7@github.com>

On Wed, 25 Jan 2023 18:12:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
>> 
>> _TimeZone.getTimeZone(String ID)
>> TimeZone.setID(String ID)
>> TimeZone.inDaylightTime(Date date)_
>> 
>> For example, 
>> 
>> 
>> String someID = null;
>> TimeZone tz1 = TimeZone.getTimeZone(someID);
>> ``` 
>> 
>> throws a `NullPointerException`
>> 
>> 
>> This PR adds the missing  _ at throws:_ for the mentioned methods. The wording and specification is also adjusted for the overridable methods in TZ to use "_may throw_" over "_will throw_" because of the possibility of external sub-classes that may override the method.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust ImplSpec positioning and wording

src/java.base/share/classes/java/util/TimeZone.java line 300:

> 298:      * @param ID the new time zone ID.
> 299:      * @throws NullPointerException This method may throw a
> 300:      * {@code NullPointerException} if {@code ID} is {@code null}

Is this needed given it is covered in the implSpec as it seems redundant

src/java.base/share/classes/java/util/TimeZone.java line 409:

> 407:      * {@code IllegalArgumentException} if {@code style} is invalid.
> 408:      * @throws NullPointerException This method may throw a
> 409:      * {@code NullPointerException} if {@code ID} is {@code null}

Same comment as above

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From naoto at openjdk.org  Wed Jan 25 19:24:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 19:24:45 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
Message-ID: <qpmcqq6o5zX4dMWm8pj27e2tUYmcjxA5JdSpkYv0N5I=.9518a3d3-9f6a-47f7-bcb2-6e98248e3c89@github.com>

On Wed, 25 Jan 2023 18:45:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use standardProvider to determine the default charset

Good point. Will make the change and create a CSR/relnote.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Wed Jan 25 19:35:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 19:35:18 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v5]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <4RWiUTHXWOGXwwQ5WrMhna4SuVexsnNvp4q0mBuN2jc=.50547251-b9e9-439c-b3c6-a2d80cb615bc@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use StaticProperty.fileEncoding() & make the field @Stable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/5c37f5bc..b2268eb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=03-04

  Stats: 7 lines in 1 file changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From jlu at openjdk.org  Wed Jan 25 19:36:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 19:36:50 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v7]
In-Reply-To: <RzbGmNHEaTpAIOXWYKyAa1d3L6C9YcSeONN5sZWLNM8=.3226284e-de00-4d01-9149-72082c8c4cb7@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>
 <RzbGmNHEaTpAIOXWYKyAa1d3L6C9YcSeONN5sZWLNM8=.3226284e-de00-4d01-9149-72082c8c4cb7@github.com>
Message-ID: <N6eV7mYBY50tsCPNvCea9tPJNFMGM1QMsyf2AtPVqRk=.152db4f5-b0a6-4aa0-8d36-dad6f8a3d0db@github.com>

On Wed, 25 Jan 2023 19:15:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust ImplSpec positioning and wording
>
> src/java.base/share/classes/java/util/TimeZone.java line 300:
> 
>> 298:      * @param ID the new time zone ID.
>> 299:      * @throws NullPointerException This method may throw a
>> 300:      * {@code NullPointerException} if {@code ID} is {@code null}
> 
> Is this needed given it is covered in the implSpec as it seems redundant

In the CSR, Joe brought up the point that since _Time Zone_ is a non final class, and these instance methods can be overridden, there exists the possibility of an external subclass that overrides the method and does **not** throw an NPE. That is why in the @throws: section, the wording is weakened from _will_ throw an NPE to _may._

The **@ImplSpec** is then added on to state that Time Zone's default implementation of the particular method _does_ indeed throw an NPE.

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From mchung at openjdk.org  Wed Jan 25 19:43:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 25 Jan 2023 19:43:43 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v3]
In-Reply-To: <avraKQSGssMhKoXvP772dockNlt0N2VUG5VuvlBlQ4k=.b7b9da4f-5a7e-4863-a4bd-0e7b446522c6@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DGY-6SOBN8zVp4pg6NUsr8Q4-sc7YJuJBY3tdBgV3B0=.328689f7-5a59-475d-9707-da4f08a7235d@github.com>
 <avraKQSGssMhKoXvP772dockNlt0N2VUG5VuvlBlQ4k=.b7b9da4f-5a7e-4863-a4bd-0e7b446522c6@github.com>
Message-ID: <iCB63Ufnj0mcmY3D4HaKBF7Q-Cx-1N2f3fpBjy4sn-A=.94442d87-8cc7-443f-8847-00b8c813f132@github.com>

On Wed, 25 Jan 2023 07:41:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A simpler, and more reliable, would be to change Charset.defaultCharset to use standardProvider.charsetForName with the value of "file.encoding", and avoid the provider lookup completely.

This is a good observation.   The change looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From lancea at openjdk.org  Wed Jan 25 19:57:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Jan 2023 19:57:45 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v7]
In-Reply-To: <N6eV7mYBY50tsCPNvCea9tPJNFMGM1QMsyf2AtPVqRk=.152db4f5-b0a6-4aa0-8d36-dad6f8a3d0db@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>
 <RzbGmNHEaTpAIOXWYKyAa1d3L6C9YcSeONN5sZWLNM8=.3226284e-de00-4d01-9149-72082c8c4cb7@github.com>
 <N6eV7mYBY50tsCPNvCea9tPJNFMGM1QMsyf2AtPVqRk=.152db4f5-b0a6-4aa0-8d36-dad6f8a3d0db@github.com>
Message-ID: <orPdwkSGA6Ci-a83A_n7KS89cpuitBv9gYXPMVyYnB0=.208fa2ad-2358-4829-88ca-8f174995ff18@github.com>

On Wed, 25 Jan 2023 19:33:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 300:
>> 
>>> 298:      * @param ID the new time zone ID.
>>> 299:      * @throws NullPointerException This method may throw a
>>> 300:      * {@code NullPointerException} if {@code ID} is {@code null}
>> 
>> Is this needed given it is covered in the implSpec as it seems redundant
>
> In the CSR, Joe brought up the point that since _Time Zone_ is a non final class, and these instance methods can be overridden, there exists the possibility of an external subclass that overrides the method and does **not** throw an NPE. That is why in the @throws: section, the wording is weakened from _will_ throw an NPE to _may._
> 
> The **@ImplSpec** is then added on to state that Time Zone's default implementation of the particular method _does_ indeed throw an NPE.

OK, fair enough, let's get the CSR moving forward to make sure the proposed wording addresses Joe's concern.

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From jlu at openjdk.org  Wed Jan 25 20:02:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 20:02:46 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v7]
In-Reply-To: <orPdwkSGA6Ci-a83A_n7KS89cpuitBv9gYXPMVyYnB0=.208fa2ad-2358-4829-88ca-8f174995ff18@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <N889PQBG8n4MLeyPWEhcvksnlj8HnIB9q73PdQXTgrQ=.5f44370a-03c3-4125-91e2-87827cb05cdf@github.com>
 <RzbGmNHEaTpAIOXWYKyAa1d3L6C9YcSeONN5sZWLNM8=.3226284e-de00-4d01-9149-72082c8c4cb7@github.com>
 <N6eV7mYBY50tsCPNvCea9tPJNFMGM1QMsyf2AtPVqRk=.152db4f5-b0a6-4aa0-8d36-dad6f8a3d0db@github.com>
 <orPdwkSGA6Ci-a83A_n7KS89cpuitBv9gYXPMVyYnB0=.208fa2ad-2358-4829-88ca-8f174995ff18@github.com>
Message-ID: <X9C3Kt1DzNiG-ZIEV7pOKqW--XFuWNlZ0EGp_nfNuyU=.1180b893-d50e-4ee7-9a4a-72f127831281@github.com>

On Wed, 25 Jan 2023 19:55:09 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> In the CSR, Joe brought up the point that since _Time Zone_ is a non final class, and these instance methods can be overridden, there exists the possibility of an external subclass that overrides the method and does **not** throw an NPE. That is why in the @throws: section, the wording is weakened from _will_ throw an NPE to _may._
>> 
>> The **@ImplSpec** is then added on to state that Time Zone's default implementation of the particular method _does_ indeed throw an NPE.
>
> OK, fair enough, let's get the CSR moving forward to make sure the proposed wording addresses Joe's concern.

Agreed, was planning to finalize the CSR before the end of the day, and will adjust this accordingly if Joe has concerns

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From prappo at openjdk.org  Wed Jan 25 20:06:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 25 Jan 2023 20:06:53 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
Message-ID: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>

On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is.
>
> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.

It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:

    doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
    that are not declared by a method; document such exception types directly

JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.

@jonathan-gibbons thoughts?

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From duke at openjdk.org  Wed Jan 25 20:11:28 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 25 Jan 2023 20:11:28 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v11]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <z3azpaSAQQwDGKItPKIFlNUU91hI3JH2HYuYO9l7x0Q=.971bc965-aae9-4f21-ab1b-334bdc4c8236@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - remove debug output
 - Fix inner loop, now we get the method too large exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/e73760ca..768a23d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=09-10

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From alanb at openjdk.org  Wed Jan 25 20:15:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jan 2023 20:15:48 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v5]
In-Reply-To: <4RWiUTHXWOGXwwQ5WrMhna4SuVexsnNvp4q0mBuN2jc=.50547251-b9e9-439c-b3c6-a2d80cb615bc@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <4RWiUTHXWOGXwwQ5WrMhna4SuVexsnNvp4q0mBuN2jc=.50547251-b9e9-439c-b3c6-a2d80cb615bc@github.com>
Message-ID: <lK6DvYUT3pPkJ5D7rrEClJHt-OnjIEBBNgK_IoK0jT0=.2a202619-16f5-4385-b1fa-24126c531b5d@github.com>

On Wed, 25 Jan 2023 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StaticProperty.fileEncoding() & make the field @Stable

src/java.base/share/classes/java/nio/charset/Charset.java line 633:

> 631: 
> 632:     @Stable
> 633:     private static volatile Charset defaultCharset;

If the field is stable then does the volatile go away?

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From jlu at openjdk.org  Wed Jan 25 20:21:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jan 2023 20:21:11 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v8]
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <hwuMkMb5Pba4Ju_TTUi9_EarFro2rBbfTfDCZ5w-vjA=.0af4f14b-a393-4f68-9a99-c3dea0180b36@github.com>

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> _TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)_
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> 
> This PR adds the missing  _ at throws:_ for the mentioned methods. The wording and specification is also adjusted for the overridable methods in TZ to use "_may throw_" over "_will throw_" because of the possibility of external sub-classes that may override the method.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  STZ.inDT can also be overriden

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11888/files
  - new: https://git.openjdk.org/jdk/pull/11888/files/106624a0..7d6fc6e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11888&range=06-07

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11888/head:pull/11888

PR: https://git.openjdk.org/jdk/pull/11888

From igraves at openjdk.org  Wed Jan 25 20:21:20 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 25 Jan 2023 20:21:20 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v3]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <8t816yne7F-LOhZf_EWFa79ZbrDiFSatnWUOfz-HKy8=.889607b4-02ea-4788-b68c-7068153ab586@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into jlink-compression
 - Changes per review
 - Swapping deprecations in properties
 - 8293667: Align jlink's --compress option with jmod's --compress option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/da25d251..9c03c670

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=01-02

  Stats: 148117 lines in 3831 files changed: 74255 ins; 50170 del; 23692 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From naoto at openjdk.org  Wed Jan 25 20:23:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 20:23:31 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v6]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <4C_ovf8vExo9PAYU2mZ_lddvqjMo065l9kFOqXIL9a8=.db5455f6-85ce-401f-8e85-2a502dab089a@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Remove `volatile` from the field definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/b2268eb2..c0a6770c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Wed Jan 25 20:23:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 20:23:34 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v5]
In-Reply-To: <lK6DvYUT3pPkJ5D7rrEClJHt-OnjIEBBNgK_IoK0jT0=.2a202619-16f5-4385-b1fa-24126c531b5d@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <4RWiUTHXWOGXwwQ5WrMhna4SuVexsnNvp4q0mBuN2jc=.50547251-b9e9-439c-b3c6-a2d80cb615bc@github.com>
 <lK6DvYUT3pPkJ5D7rrEClJHt-OnjIEBBNgK_IoK0jT0=.2a202619-16f5-4385-b1fa-24126c531b5d@github.com>
Message-ID: <uyfzgcw8hWA2EQY2rm1X1n-EUoRrXBR9ceWfY8-aLqQ=.c499d72d-eb20-4a88-be72-67daa1cf2c02@github.com>

On Wed, 25 Jan 2023 20:13:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use StaticProperty.fileEncoding() & make the field @Stable
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 633:
> 
>> 631: 
>> 632:     @Stable
>> 633:     private static volatile Charset defaultCharset;
> 
> If the field is stable then does the volatile go away?

Right. It should.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Wed Jan 25 20:28:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 20:28:10 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v7]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <v0nfLsCGd-5A7A7AdCF8Mfi_2sqJ5MMmcEadren8DMo=.ee56e1c1-05be-4a6f-b456-05abdb16ee07@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/c0a6770c..df999de3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Wed Jan 25 20:50:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jan 2023 20:50:21 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v8]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <DX5v7_t3KucSjji8WKgv1nbEi9CrysDJ2jSmM50WZPY=.c91a3721-219d-4fd5-9892-f1f977b1b9ac@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Restored doPriv

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/df999de3..847fdd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=06-07

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From duke at openjdk.org  Wed Jan 25 21:00:01 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 25 Jan 2023 21:00:01 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v12]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <5KZPrCRHL1WjABaYBIOzkUeUySD_jMRUPH3alDqNmDs=.99953550-8f5b-4d33-9138-0cdd8a7cd1dc@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  use jlinktask assertSuccess

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/768a23d4..cba36761

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=10-11

  Stats: 13 lines in 1 file changed: 1 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Wed Jan 25 21:00:03 2023
From: duke at openjdk.org (Christoph)
Date: Wed, 25 Jan 2023 21:00:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <f8lBv2grA_mHK-pLXtIYEKih-eOJL44r0gMuUd3LhdM=.5c60c4b0-ede9-4f3a-b808-6c0a72e1ba03@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <Ouly-NyXJMLpyNiBnUNkO0Zhus8EZc3S03_PsCP40vk=.47c03775-acc8-4aa4-a09d-75e9337f915e@github.com>
 <iS9jjhVy4BtehQablwAX9B2fbOF6M_nfP7O_TGpppqY=.3c0cc6a4-dbbf-48fb-a09c-c9c2ce8d4aee@github.com>
 <x8UM5rQyXazsY8j3AxpIwra3hAZ89vQkjK1S5Ym5WWo=.7b490221-0c1e-49ee-9384-b27e4fe857fa@github.com>
 <f8lBv2grA_mHK-pLXtIYEKih-eOJL44r0gMuUd3LhdM=.5c60c4b0-ede9-4f3a-b808-6c0a72e1ba03@github.com>
Message-ID: <I8kffnWC1ZKD_4Krj_YaBo-evO0hpSNd1W4TGlfEIOM=.bc436f1a-5bfd-4913-ba8d-7d47e05b57c8@github.com>

On Tue, 3 Jan 2023 16:17:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Would it be possible to paste in a summary on the VerifyError with the previous iteration?
>> 
>> Isn't this https://github.com/openjdk/jdk/pull/10704#issuecomment-1286106503?
>> 
>>     Type top (current frame, locals[15]) is not assignable to reference type
>> 
>>>  If I read the latest update then the limit per helper method has been bump to avoid it, is that right?
>> 
>> Yes. Then, the compiler still works - and we can try to debug using the test case (yet to be finalized).
>
> @koppor Should we continue to just ignore this PR for now? The current patch is test only, I don't know if that is deliberate or not.

@AlanBateman  We now have a reproducible JTREG test case that throws the MethodTooLargeException. We will now readd the module splitting handling.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From tvaleev at openjdk.org  Wed Jan 25 21:48:48 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 25 Jan 2023 21:48:48 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections
Message-ID: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>

number of minor cleanups could be done in Arrays and Collections utility classes.
In Arrays:
- Redundant import jdk.internal.misc.Unsafe;
- C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
- Redundant casts to Object type in comparisons like (Object)newType == (Object)Object[].class

In Collections:
- A few obsolete "unchecked" and "rawtypes" suppressions
- Unnecessary local variable initializer in get() method
- Raw type can be avoided in a number of casts
- Explicit type parameters could be omitted or converted to diamonds
- A couple of javadoc links on private APIs are malformed

-------------

Commit messages:
 - Cleanup

Changes: https://git.openjdk.org/jdk/pull/12207/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301120
  Stats: 30 lines in 2 files changed: 0 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/12207.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12207/head:pull/12207

PR: https://git.openjdk.org/jdk/pull/12207

From dnguyen at openjdk.org  Wed Jan 25 22:02:45 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:02:45 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v8]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <AB1V6yMmmoy0zYaY-mNjq4QPc8MTvQO4t8BCsUs0EFA=.40f66568-b479-45c6-8126-1e0d8b375bf9@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Update German translation

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/9a5b45a2..35829a25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:19:34 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:19:34 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2]
In-Reply-To: <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <qRJEZ59SZ0bAjFZoM-Wq-pjrjLZ8mQ3nmdyhUGpZ4uc=.fe95fa3d-cf4a-42fa-8873-869a74335022@github.com>
 <TsM2mpquBl2wvitATox3_QNHuSrQLhZN0MFsaaINyHg=.41bef814-3f17-402b-be0d-a1797114bbee@github.com>
Message-ID: <XTYcX2V5gNfgnD4UmjFcya6DL2xEA1xmZha3_37alEU=.ab625ad0-c40c-48e1-b759-337ca44d2b98@github.com>

On Wed, 25 Jan 2023 08:17:26 GMT, danielpeintner <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change German help of jar command
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111:
> 
>> 109: main.help.opt.main.update=\  -u, --update               Ein vorhandenes JAR-Archiv aktualisieren
>> 110: main.help.opt.main.extract=\  -x, --extract              Benannte (oder alle) Dateien aus dem Archiv extrahieren
>> 111: main.help.opt.main.describe-module=\  -d, --describe-module      Gibt den Moduldeskriptor oder automatischen Modulnamen aus
> 
> Just because I stumbled over this commit. I think the line should be translated as follows:
> 
> `Gibt die Modulbeschreibung oder den automatischen Modulnamen aus`

Resolved

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From sviswanathan at openjdk.org  Wed Jan 25 22:22:02 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 25 Jan 2023 22:22:02 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32
In-Reply-To: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
Message-ID: <unCS9qidVWquo1puE3LVqagOCSjAFn0Dnl98T2x_t28=.3315561b-7d2a-4bf1-b261-9f07c3232e9f@github.com>

On Wed, 25 Jan 2023 15:03:05 GMT, Scott Gibbons <duke at openjdk.org> wrote:

> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

test/micro/org/openjdk/bench/java/util/TestCRC32.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022, 2023, Oracle and/or its affiliates. All rights reserved.

The copyright line should be as follows:
 * Copyright (c) 2021,  2023, Oracle and/or its affiliates. All rights reserved.

Rest of the patch looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12199

From tvaleev at openjdk.org  Wed Jan 25 22:23:26 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 25 Jan 2023 22:23:26 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
Message-ID: <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>

> number of minor cleanups could be done in Arrays and Collections utility classes.
> In Arrays:
> - Redundant import jdk.internal.misc.Unsafe;
> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
> 
> In Collections:
> - A few obsolete "unchecked" and "rawtypes" suppressions
> - Unnecessary local variable initializer in get() method
> - Raw type can be avoided in a number of casts
> - Explicit type parameters could be omitted or converted to diamonds
> - A couple of javadoc links on private APIs are malformed

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Revert cast removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12207/files
  - new: https://git.openjdk.org/jdk/pull/12207/files/f1345d33..ec7b2afc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12207&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12207&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12207.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12207/head:pull/12207

PR: https://git.openjdk.org/jdk/pull/12207

From jjg at openjdk.org  Wed Jan 25 22:41:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 25 Jan 2023 22:41:34 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
Message-ID: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>

On Wed, 25 Jan 2023 20:03:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it.
>
> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
> 
>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>     that are not declared by a method; document such exception types directly
> 
> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
> 
> @jonathan-gibbons thoughts?

While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.

I would suggest translating the phrase as if it were something like

@inheritDoc is not supported for type parameters that are exception types and not declared by a method


and secondarily, changing the English resource to something like that as well.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From igraves at openjdk.org  Wed Jan 25 22:45:51 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 25 Jan 2023 22:45:51 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v4]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <4GRRKK8UFBwpbKfont6hLkgV8h6gyAWdTZ13-Ej_IKw=.fa193c02-bf0a-451c-9573-2a238c995606@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding test for new plugin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/9c03c670..41e52039

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=02-03

  Stats: 281 lines in 1 file changed: 281 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Wed Jan 25 22:47:45 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 25 Jan 2023 22:47:45 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32 [v2]
In-Reply-To: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
Message-ID: <yZdRF4VwCk5ACsM5Hk2o90UjsKVxkmO3GwdhviU06wI=.b3b0a545-7299-4892-8a05-d40e671e2d00@github.com>

> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

Scott Gibbons 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:

 - Merge branch 'openjdk:master' into CRC32
 - Updated copyright
 - Add benchmark for CRC32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12199/files
  - new: https://git.openjdk.org/jdk/pull/12199/files/0f098760..d61f6588

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12199&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12199&range=00-01

  Stats: 215 lines in 56 files changed: 27 ins; 37 del; 151 mod
  Patch: https://git.openjdk.org/jdk/pull/12199.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12199/head:pull/12199

PR: https://git.openjdk.org/jdk/pull/12199

From igraves at openjdk.org  Wed Jan 25 22:54:19 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 25 Jan 2023 22:54:19 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <jNkqEmwR3QhjvxJCmjMotsZHwIfcdsKce-gDsRdzWgY=.122a68b8-6069-43d2-a3f6-c2ac1a50cf39@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <jNkqEmwR3QhjvxJCmjMotsZHwIfcdsKce-gDsRdzWgY=.122a68b8-6069-43d2-a3f6-c2ac1a50cf39@github.com>
Message-ID: <Cy51wUA8eT4jLysG4aERBJZVq08uNauJN6aMtFaAx6g=.a55ecfd9-1c79-4d56-b392-0c7b2c199609@github.com>

On Thu, 15 Dec 2022 07:22:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 227:
> 
>> 225:         boolean suggestProviders = false;
>> 226: 
>> 227:         int compressLevel;
> 
> Does this get used anywhere?

Thanks. Removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v9]
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <VeAjGWpLXL0FNT25iwGS5NsmzRe4Navl_LNepqMKSNg=.23960b10-c6cb-4893-93f8-cbc2f8a8297c@github.com>

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Replace exception-type

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/116/files
  - new: https://git.openjdk.org/jdk20/pull/116/files/35829a25..53a86ef2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116

PR: https://git.openjdk.org/jdk20/pull/116

From dnguyen at openjdk.org  Wed Jan 25 22:56:59 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jan 2023 22:56:59 GMT
Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]
In-Reply-To: <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
 <XF9BahXDdZI9Q40rOSWKUmpUAhqumlmwftnfXYM8xXk=.f077bf6e-285f-48e2-9e6f-b908e6380cd4@github.com>
 <pUJrKYdaLsbvEJV9SEZpa0mU_huHnHzM2rqGFBk1yZc=.412f2249-608d-4de8-bb36-d3ad8acd72d6@github.com>
 <UcOC5aYXrhw_K9Pb7t5ORu9jjYo5LMVlf-CxRoFykQM=.b8a3dfc5-da11-4361-9193-69928d6b4d3b@github.com>
 <nN1C5POK0aTeX1s9_NUkBMmYTcQgzEJFQwHs42rn_og=.e1029cac-c82e-423c-a4da-d1c99dd8eec4@github.com>
 <HmtuZgI4Gn2cXWC_wVOVAjPD0DdjSnOa4OENGo9ofsU=.aa00f17c-703d-494d-9594-9f6f084be286@github.com>
 <SguhDj7riiU8cDGLybLwdwjSQbHGgLUsDhGBVeHk5L4=.df78d310-21cb-422c-b588-6e3b0a060709@github.com>
Message-ID: <qWC3dfg9l9N5Om85X97AxhnYgQJCQEYtxknwqG0MeY0=.417d15ec-c2d8-424e-97dc-867c4f753e9a@github.com>

On Wed, 25 Jan 2023 22:38:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows:
>> 
>>     doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \
>>     that are not declared by a method; document such exception types directly
>> 
>> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type.
>> 
>> @jonathan-gibbons thoughts?
>
> While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language.
> 
> I would suggest translating the phrase as if it were something like
> 
> @inheritDoc is not supported for type parameters that are exception types and not declared by a method
> 
> 
> and secondarily, changing the English resource to something like that as well.

Updated this line with `exception-type` translated. Hopefully this will be addressed in future drops with changes to the translation tool after some bug fixes.

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From bpb at openjdk.org  Wed Jan 25 22:57:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 25 Jan 2023 22:57:16 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input | Output)Impl
 classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <ESkA2xuv6_kG96jZQg0s_KZjmC-Q1ATIQMfIJaENzCY=.8d6d1457-928c-4a8e-9029-db5911f429e7@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Looks good overall. Did you measure any performance changes in the image streams? (Note that this PR and its corresponding issue are missing "Stream" in the title.)

-------------

PR: https://git.openjdk.org/jdk/pull/12204

From raffaello.giulietti at oracle.com  Wed Jan 25 22:59:49 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 25 Jan 2023 22:59:49 +0000
Subject: Math.clamp method?
In-Reply-To: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
Message-ID: <BY5PR10MB40027E8DF13A4BE5EE1A558987CE9@BY5PR10MB4002.namprd10.prod.outlook.com>

What?s error-prone is not much the clamping logic proper, but the need to check that the [min, max] interval is not empty. IMO, this is what most people will likely forget.
Thus, I vote for this addition.

Greetings
Raffaello


From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Tagir Valeev <amaembo at gmail.com>
Date: Wednesday, 25 January 2023 at 14:42
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Math.clamp method?
Hello!

Quite often it's necessary to clamp a numerical value to a given
range, using the algorithm like this:
int clampedValue = value > max ? max : value < min ? min : value;
or probably
int clampedValue = Math.max(min, Math.min(max, value));
Some examples in wild: [1] [2]

These "algorithms" are verbose and error-prone. E.g., many years ago
Math.max and Math.min were mixed in Jenkins CI implementation (later
fixed in [3]). Static analyzers like SonarLint even implement a rule
to catch such kind of mistake [4], but it cannot statically find a
mistake if max and min values are not constant.

Having a library method for this algorithm will make the code more
readable, and robust. Standard libraries of various languages tend to
implement a function that encapsulates this algorithm. E.g., Kotlin
coerseIn [5], C# Math.Clamp [6], Rust num::clamp [7].

I hereby propose to add a similar method to Java Math class. The
signatures could be:
public static int clamp(int value, int min, int max)
public static long clamp(long value, long min, long max)
public static double clamp(double value, double min, double max)
public static float clamp(float value, float min, float max)

These methods should additionally check that min is not greater than
max (throwing IllegalArgumentException). Probably IAE should be thrown
as well if either min or max is NaN for floating point methods. It can
be discussed what should happen if the value is NaN (I think returning
NaN would be ok, but throwing an exception is also a possibility).

I can post CSR and contribute the implementation if Core Library team
members agree that it's a good idea.

With best regards,
Tagir Valeev.

[1] https://github.com/moneymod/moneymod/blob/4d2c7f5be40dbf392e75/src/main/java/wtf/moneymod/client/impl/ui/click/buttons/settings/SliderButton.java#L71
[2] https://github.com/androidthings/experiment-expression-flower/blob/f0fd6090e0df1659bad/code/app/src/main/java/com/example/androidthings/VideoProcessor.java#L559
[3] https://github.com/jenkinsci/jenkins/commit/e00f99251e0b
[4] https://rules.sonarsource.com/java/RSPEC-3065
[5] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.ranges/coerce-in.html
[6] https://learn.microsoft.com/en-us/dotnet/api/system.math.clamp?view=net-7.0
[7] https://docs.rs/num/0.2.1/num/fn.clamp.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230125/e9e77f32/attachment.htm>

From duke at openjdk.org  Wed Jan 25 23:07:49 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 25 Jan 2023 23:07:49 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32 [v3]
In-Reply-To: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
Message-ID: <G3sTBGzRgz-5TD8RtN8ZRWXc4-gZ1sL7R8A7kgvHrzE=.aa788712-cc34-4956-9214-b861f778558c@github.com>

> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12199/files
  - new: https://git.openjdk.org/jdk/pull/12199/files/d61f6588..7ff46913

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12199&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12199&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12199.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12199/head:pull/12199

PR: https://git.openjdk.org/jdk/pull/12199

From duke at openjdk.org  Wed Jan 25 23:07:49 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 25 Jan 2023 23:07:49 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32 [v3]
In-Reply-To: <unCS9qidVWquo1puE3LVqagOCSjAFn0Dnl98T2x_t28=.3315561b-7d2a-4bf1-b261-9f07c3232e9f@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
 <unCS9qidVWquo1puE3LVqagOCSjAFn0Dnl98T2x_t28=.3315561b-7d2a-4bf1-b261-9f07c3232e9f@github.com>
Message-ID: <0CpBeL_NlwVYABSPs30EyXEXnZMD27MxgRR12qw3EcM=.4b9e4512-734a-491b-9f4f-2abcebb6e8af@github.com>

On Wed, 25 Jan 2023 22:19:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> test/micro/org/openjdk/bench/java/util/TestCRC32.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> The copyright line should be as follows:
>  * Copyright (c) 2021,  2023, Oracle and/or its affiliates. All rights reserved.
> 
> Rest of the patch looks good to me.

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12199

From sviswanathan at openjdk.org  Wed Jan 25 23:29:18 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 25 Jan 2023 23:29:18 GMT
Subject: RFR: JDK-8301092 - Add benchmark for CRC32 [v3]
In-Reply-To: <G3sTBGzRgz-5TD8RtN8ZRWXc4-gZ1sL7R8A7kgvHrzE=.aa788712-cc34-4956-9214-b861f778558c@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
 <G3sTBGzRgz-5TD8RtN8ZRWXc4-gZ1sL7R8A7kgvHrzE=.aa788712-cc34-4956-9214-b861f778558c@github.com>
Message-ID: <fBWKa_Y6ealHkIz0DO0paf02Ex7yr6XDa1gd5eOnEvQ=.46553d17-568a-41a0-b582-191ef456f448@github.com>

On Wed, 25 Jan 2023 23:07:49 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12199

From john.r.rose at oracle.com  Wed Jan 25 23:47:30 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 25 Jan 2023 15:47:30 -0800
Subject: Math.clamp method?
In-Reply-To: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
Message-ID: <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>

Dealing with numeric ranges is error-prone, so I welcome these.

Another operation on ranges is membership.  This is easy to derive
from the clamp methods, I think:

```
   checkRange(x,min,max) := clamp(x,min,max) == x
```

That idiom works even for NaNs, which are never in any range.
I wonder about having a separate method for this. The idiom does
fail for empty ranges, so it?s almost worth making a method that
returns false with empty ranges instead of throwing.  Probably
not, though.

But I think there is no harm and real benefit from widening
the value parameters, so value is always either long or double.
That will save casts (which also cause bugs) for some use
cases, such as doing 32x32-to-64-bit arithmetic followed
by overflow checks and/or saturation.  That?s a common use
case for clamping.

```
public static int clamp(long value, int min, int max)
public static long clamp(long value, long min, long max)
public static double clamp(double value, double min, double max)
public static float clamp(double value, float min, float max)
```

I wonder if there is a use case for these methods (either clamp
or the range-membership method), with 64-bit overflow detection
for complex expressions.  The idea is that you compute the
expression in two domains, double and long.  The double domain
correctly tracks magnitude (but not precision) while long
tracks 64 bits of precision.  At the end, if the double value
is in the range representable by longs, you take the long
value, with full confidence.

```
   long x = ?, y = a*x*x + b*x + c;
   double xf = x, yf = a*xf*xf + b*xf + c;
   double xc = clamp(xf, Long.MIN_VALUE, Long.MAX_VALUE);
   boolean saturated = false;
   if (xc != xf) {   // error processing
      saturated = true;  // or throw an exception
      x = xc;  // saturate towards the required magnitude
   }
```

That use case doesn?t require a membership operation per se,
just clamp.

I thought about cross-domain clamps, which preserve 64 bit
precision and double range at the same time in different places:

```
public static long clamp(long value, double min, double max)
public static long clamp(double value, long min, long max)
```

Those are perhaps overly subtle.  I think it would be OK for
nearly all use cases to cast the min/max values to the appropriate
type (same as value) and then call one of the clamp functions
originally proposed.  Note that (long)(double)Long.MAX_VALUE
is the same as Long.MAX_VALUE, and the same is true for MIN_VALUE.
So these critical parameters would be processed as the same
limits by both the regular and cross-typed overloading.

Now for another topic.

There is another common range operation which is very often the
source of bugs, and I?d like us to consider it for this group.

That is the midpoint operation, naively coded as (min+max)/2,
and more subtly as min+(max-min)/2 and even more subtly what
our friend Mr. Stackoverflow recommends, (min+max)>>>1.
All three of these idioms hide bugs, for some values of
max or min.

The fully correct idiom (for 2s complement numbers) is:

```
  midpoint(min, max) := min + ((max - min) >>> 1)
```

The subexpression max-min never overflows, when it
is regarded as an unsigned number, and the ?>>>1?
immediately converts that unsigned number into the
correctly signed positive number.  That?s the only
way to avoid overflow for all inputs.  The third
idiom above (the ?smartest? of the three) will fail,
for example, if you feed it negative values.
For some uses that is OK, but for others it isn?t.

```
public static int midpoint(int min, int max)
public static long midpoint(long min, long max)
public static double midpoint(double min, double max)
public static float midpoint(float min, float max)
```

All kinds of divide and conquer algorithms need a robust
midpoint operation.  And many of those are coded wrongly,
because affine ranges are hard to reason about.

The int and long midpoints are more useful than the floating
point ones, because ints and longs are used as indexes into
arrays (including Panama native arrays), where subdivision
and binary search is common (and very often buggy).

More generally, this midpoint operation performs an affine
weighted sum within the given numeric range, so one might
think that a floating point ?alpha? parameter would be
interesting.  The midpoint operations hardwire alpha=0.5,
and they use clever fast fixpoint division to divide by 2.

There are applications for using alpha other than 0.5,
such as a 10x subdivision of a range using alpha=0.1, 0.2,
and so on.  I don?t recommend an ?affine midpoint? method,
because I think the clamp methods combined with floating
point math can get the right answers.  For example, given
a 64-bit range, you can use double arithmetic to compute
affine inner points and then clamp them, like this:

```
final double ALPHA = 0.1;  //float would be OK too
final long min = ?, max = ?;
final double incr = ((double)max - min) * ALPHA;
for (int i = 1; i < 10; i++)
  addPoint(clamp((long)(min + i*incr), min, max));
```

Doing the grid measurements in double (instead of long) is good
enough for most purposes, and doesn?t cause anomalies even if
the difference between min and max is large.  Using a long
for the difference would lead to bugs when max-min cannot be
represented as a long.

Anyway, the above examples tell me that we don?t need a
general affine range splitter if we can use floating point
to compute the splits and use clamp to prevent bugs at the
range boundaries.  But we do need the optimized midpoint
operations, because people always insist on them taking
a couple of cycles, and then they insist on coding them
dangerously.

Besides clamp and midpoint is there another operation on
affine ranges that is commonly coded, and with bugs?
I don?t think so.  Range algebra such as union, intersection,
difference, convex hull: those come to mind, but I don?t
think they are as bug-prone (and as frequent) as clamp
and midpoint.  Range translation (moving a range to another
base point) is subject to overflow, but I think that can
be handled by using higher precision and/or overflow checks,
and/or clamping.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230125/6ded18a3/attachment-0001.htm>

From mchung at openjdk.org  Thu Jan 26 00:01:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 00:01:21 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v8]
In-Reply-To: <DX5v7_t3KucSjji8WKgv1nbEi9CrysDJ2jSmM50WZPY=.c91a3721-219d-4fd5-9892-f1f977b1b9ac@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DX5v7_t3KucSjji8WKgv1nbEi9CrysDJ2jSmM50WZPY=.c91a3721-219d-4fd5-9892-f1f977b1b9ac@github.com>
Message-ID: <EFilSpaeCOvzuhSh-H-eJ1cqDEgAXz6d9cPdLHI-wNI=.a9aeb0ee-8a74-48f6-b2e9-86f52ca952ea@github.com>

On Wed, 25 Jan 2023 20:50:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored doPriv

src/java.base/share/classes/java/nio/charset/Charset.java line 662:

> 660:                 } else {
> 661:                     PrivilegedAction<Charset> pa =
> 662:                         () -> standardProvider.charsetForName(StaticProperty.fileEncoding());

what operation does this do security permission check?  I don't think any.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From john.r.rose at oracle.com  Thu Jan 26 00:06:21 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 25 Jan 2023 16:06:21 -0800
Subject: Math.clamp method?
In-Reply-To: <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
 <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
Message-ID: <A9F82399-6B01-45B9-86F2-E151F3BCED41@oracle.com>

P.S Sorry, I botched a use case, saying x where I meant y:


```
   long x = ?, y = a*x*x + b*x + c;
   double xf = x, yf = a*xf*xf + b*xf + c;
   double yc = clamp(yf, Long.MIN_VALUE, Long.MAX_VALUE);
   boolean saturated = false;
   if (yc != yf) {   // error processing
      saturated = true;  // or throw an exception
      y = yc;  // saturate towards the required magnitude
   }
```


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230125/ce09a506/attachment.htm>

From naoto at openjdk.org  Thu Jan 26 00:14:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jan 2023 00:14:17 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v8]
In-Reply-To: <EFilSpaeCOvzuhSh-H-eJ1cqDEgAXz6d9cPdLHI-wNI=.a9aeb0ee-8a74-48f6-b2e9-86f52ca952ea@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <DX5v7_t3KucSjji8WKgv1nbEi9CrysDJ2jSmM50WZPY=.c91a3721-219d-4fd5-9892-f1f977b1b9ac@github.com>
 <EFilSpaeCOvzuhSh-H-eJ1cqDEgAXz6d9cPdLHI-wNI=.a9aeb0ee-8a74-48f6-b2e9-86f52ca952ea@github.com>
Message-ID: <fYLJluAxMDi9IEDdgRiPjUYjeOka-rpYualPlzeh6Jc=.a7cf5c54-d6ee-4003-b801-22565ad5465f@github.com>

On Wed, 25 Jan 2023 23:58:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restored doPriv
>
> src/java.base/share/classes/java/nio/charset/Charset.java line 662:
> 
>> 660:                 } else {
>> 661:                     PrivilegedAction<Charset> pa =
>> 662:                         () -> standardProvider.charsetForName(StaticProperty.fileEncoding());
> 
> what operation does this do security permission check?  I don't think any.

Right. I was under the impression that the call should have been made with privileged action (as in the comments for those access methods in `StaticProperty`, but the property value itself is not given to untrusted code. Will remove the permission check.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Thu Jan 26 00:19:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jan 2023 00:19:45 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v9]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Revert the permission check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/847fdd30..3f9165bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=07-08

  Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From duke at openjdk.org  Thu Jan 26 00:23:28 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Thu, 26 Jan 2023 00:23:28 GMT
Subject: Integrated: JDK-8301092 - Add benchmark for CRC32
In-Reply-To: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
References: <IZygvkraur7RjuUCAO2fH5A9bJ1F0gFkGsCBXfNeF8w=.3e7ed6ca-1564-4989-9c50-abdb46b9ac30@github.com>
Message-ID: <rYuLUU4M08kW60wiYzzGVLJjD-qVVUdpqKxnQS8isF4=.74ed2087-310c-4ab7-8145-eb7aba884b22@github.com>

On Wed, 25 Jan 2023 15:03:05 GMT, Scott Gibbons <duke at openjdk.org> wrote:

> Adding a performance benchmark test for CRC32.  This does exactly the same test as for CRC32C.

This pull request has now been integrated.

Changeset: 7e951f4b
Author:    Scott Gibbons <scott.gibbons at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e951f4b4cc047d354856c29ed2e1a22190ba382
Stats:     61 lines in 1 file changed: 61 ins; 0 del; 0 mod

8301092: Add benchmark for CRC32

Reviewed-by: ecaspole, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/12199

From mchung at openjdk.org  Thu Jan 26 01:04:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 01:04:18 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v9]
In-Reply-To: <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>
Message-ID: <Kx-faI_7Y_t-J7WrP4hOj2lU-r4wuzfcE4hwsJ9L-Xo=.7ca3e0f5-4d27-464b-9029-283f37af1a9e@github.com>

On Thu, 26 Jan 2023 00:19:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the permission check

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From itakiguchi at openjdk.org  Thu Jan 26 02:40:23 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 26 Jan 2023 02:40:23 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <07ZoLE0pwp1mHpp79O80BfH-o8mF_o-vRAlvkIn-I5o=.afd8b5ec-a94a-4dea-ac13-946f2768bbff@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
 <7b3pYFpBTKBsf-WXMJ0SIrm1hUWBZTuyF8pz_pgIBrI=.46398ec6-9057-4278-8070-85a86f3178e6@github.com>
 <07ZoLE0pwp1mHpp79O80BfH-o8mF_o-vRAlvkIn-I5o=.afd8b5ec-a94a-4dea-ac13-946f2768bbff@github.com>
Message-ID: <_Bq-Meyk4nliwF0CQfkpDhI9HNA68cSaItlAkyHt36s=.2aebcb1a-76f0-47aa-841f-43deadbd6b23@github.com>

On Wed, 25 Jan 2023 18:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.
>
>> `Charset.defaultCharset()` now uses `standardProvider.charsetForName(<file.encoding>)` charset.
> 
> I think this is the right thing to do. It can also be changed to use StaticProperty.fileEncoding() and maybe the field can be changed to be a `@Stable` field. 
> 
> It might be that we will need to create a CSR and Release Note for this change.  The scenario is PR 12132 is unfortunate but does not show that some deployments may have been relying on the this from JDK 9 to JDK 17. With the change here, we are doubling now on ensuring that the default charset is loaded from java.base.

Hello @AlanBateman 
You said

> The change to StaticProperty to avoid calling out to Charset.defaultCharset from the initializer is good. However, the other part to that is the scenario in PR 12132 where the default Charset was accidentally located via the provider mechanism in JDK 9-17. If I read the changes correctly, that fragile scenario will come back. We have a couple of ways to avoid that, one being to ensure that defaultCharset is called before the boot layer is set. A simpler, and more reliable, would be to change Charset.defaultCharset to use standardProvider.charsetForName with the value of "file.encoding", and avoid the provider lookup completely.

Could you explain about fragile scenario ?

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From alanb at openjdk.org  Thu Jan 26 08:59:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jan 2023 08:59:43 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v4]
In-Reply-To: <_Bq-Meyk4nliwF0CQfkpDhI9HNA68cSaItlAkyHt36s=.2aebcb1a-76f0-47aa-841f-43deadbd6b23@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <xIW9WxGkxbWaFiGPpsNLmK7medr7tvTlHpBSqdfWxLM=.2b3b1821-a89c-4096-b245-2e554b617260@github.com>
 <7b3pYFpBTKBsf-WXMJ0SIrm1hUWBZTuyF8pz_pgIBrI=.46398ec6-9057-4278-8070-85a86f3178e6@github.com>
 <07ZoLE0pwp1mHpp79O80BfH-o8mF_o-vRAlvkIn-I5o=.afd8b5ec-a94a-4dea-ac13-946f2768bbff@github.com>
 <_Bq-Meyk4nliwF0CQfkpDhI9HNA68cSaItlAkyHt36s=.2aebcb1a-76f0-47aa-841f-43deadbd6b23@github.com>
Message-ID: <iYC7bPCtafll3bYWWvqeF794XjB4IHEubY-TTqbncmM=.05e15c6f-354e-45ed-ad4c-12d8cf291491@github.com>

On Thu, 26 Jan 2023 02:37:57 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Could you explain about fragile scenario ?

Charset.defaultCharset does the lookup on the first usage. Since JDK 18, that first usage is in initPhase1 so it will always find the default charset in java.base. In JDK 9-17, the first usage may have been in initPhase2 (during module system initialization), in which case it would locate the default charset in java.base, the first usage may have been after the VM is fully initialized, in which case it would be a service provider lookup and maybe find it in jdk.charsets or on the class path.

I've added a comment to the [CSR](https://bugs.openjdk.org/browse/JDK-8301114) with more context and to support the proposal to double down on requiring the default charset to be in java.base.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From pminborg at openjdk.org  Thu Jan 26 09:00:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Jan 2023 09:00:34 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <McLp1lkPcd_TuZvOdzfTiPg3ziNarfJxwq6IeiCfUws=.f3f0353f-9927-401a-9e6b-066bb48c5b9a@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Here are some performance figures (TLDR: about 2% performance increase):

Baseline (J21 master)

     [java] All test results:
     [java] Test(imageio.input.stream.tests.readFully(int[])) averaged 2.0089243986475606E9 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache
     [java] Test(imageio.input.stream.tests.readLong) averaged 6.087925258517034E8 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache


Patch

     [java] All test results:
     [java] Test(imageio.input.stream.tests.readFully(int[]) averaged 2.0537614726652384E9 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache
     [java] Test(imageio.input.stream.tests.readLong) averaged 6.227265050569915E8 bytes/sec
     [java]     with 250x250, photo, byteArray, !useCache


the `readFully(int[])` is a custom benchmark:


                iis.mark();
                int[] array = new int[8];
                do {
                    if (pos + 4*8 > length) {
                        iis.reset();
                        iis.mark();
                        pos = 0;
                    }
                    iis.readFully(array, 0, 8);
                    pos += 4*8;
                } while (--numReps >= 0);


Tests were run on a Mac M1 aarch64 machine.

-------------

PR: https://git.openjdk.org/jdk/pull/12204

From gdub at openjdk.org  Thu Jan 26 09:14:02 2023
From: gdub at openjdk.org (Gilles Duboscq)
Date: Thu, 26 Jan 2023 09:14:02 GMT
Subject: RFR: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should
 get the receiver type from VarHandle [v2]
In-Reply-To: <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
References: <QLS8Xbf78XJzYK2zHjZv5D2q6xJRVogjmuC27_a01bY=.6ac94ffe-efc9-470c-a61d-1bde8010a790@github.com>
 <XRMWQK5hZFp35Uy5yaEYXy-99LbBelseSF9SEIerexs=.0b9d46ab-9515-4b90-b68a-f80b9ad045db@github.com>
Message-ID: <o4aZHD_bs8Gk4tyEimLeBuz_8qKpMcTf3AxJJlGEoiE=.6b6d737f-6b5a-4fe7-9c35-ab7be560be6c@github.com>

On Thu, 19 Jan 2023 23:37:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `VarHandles.getStaticFieldFromBaseAndOffset` maps a base/offset/fieldType to a static `Field`.   It's fragile to assume that the location of a static field returned by `Unsafe.staticFieldBase` is a Class object.    This changes the VarHandle implementation for static fields (i.e. `FieldStaticReadOnly` and `FieldStaticReadWrite` classes) to include the receiver type in addition to the base and offset.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the base parameter which is unused

Thank you for this fix @mlchung!

-------------

PR: https://git.openjdk.org/jdk/pull/12100

From pminborg at openjdk.org  Thu Jan 26 09:15:42 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Jan 2023 09:15:42 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <7FkPoEUd1D8kRSJavY_WWu9JFN1PdXlTprwwZZVn2BU=.6f33250d-35c8-4fc3-92cd-b258299e209c@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Given the way the benchmarks are written, I suspect the actual performance gains are higher than indicated by the figures above. The benchmark likely spends more time in preparing for the call (e.g. checking, looping) than in the actual target method.

-------------

PR: https://git.openjdk.org/jdk/pull/12204

From amaembo at gmail.com  Thu Jan 26 09:49:13 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 26 Jan 2023 10:49:13 +0100
Subject: Circular initialization between EmptyNavigableMap and
 UnmodifiableNavigableMap
Message-ID: <CAE+3fjaWjKeAEeroGieaXvb5Gg2t80-2oTHZzHvW6A8b9yEyTA@mail.gmail.com>

Hello!

Not sure if this should be considered as a problem that requires
attention but there's an initialization loop between
java.util.Collections$UnmodifiableNavigableMap and
java.util.Collections$UnmodifiableNavigableMap$EmptyNavigableMap
classes. E.g., the following program may stuck in a classloader
deadlock (happens to me in ~30% of launches):

import static java.util.concurrent.CompletableFuture.supplyAsync;

public class Test {
public static void main(String[] args) {
var future1 = supplyAsync(() ->
loadClass("java.util.Collections$UnmodifiableNavigableMap$EmptyNavigableMap"));
var future2 = supplyAsync(() ->
loadClass("java.util.Collections$UnmodifiableNavigableMap"));
System.out.println(future1.join()+":"+future2.join());
}

private static Class<?> loadClass(String className) {
try {
return Class.forName(className);
} catch (ClassNotFoundException e) {
throw new RuntimeException(e);
}
}
}

This is due to the EMPTY_NAVIGABLE_MAP which is declared in
UnmodifiableNavigableMap but its type is a subclass of
UnmodifiableNavigableMap. Moving the field inside EmptyNavigableMap
will likely solve the problem. On the other hand, I was not able to
reproduce the problem without explicit Class.forName call, and given
that EmptyNavigableMap class is an implementation detail, we probably
can ignore this.

With best regards,
Tagir Valeev.

From alanb at openjdk.org  Thu Jan 26 12:10:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jan 2023 12:10:19 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v9]
In-Reply-To: <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>
Message-ID: <KtTp1XAgh_SeikUv7-DMjsM1TANtb_X8blcbmO3-GgE=.1f2b17d2-e43a-4651-8abe-56989859007a@github.com>

On Thu, 26 Jan 2023 00:19:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the permission check

Thanks for the updates/iterations, I think you've got this to a good place.

One thing to think about is having System.initPhase3 read file.encoding and if not UTF-8, it could call Charset.defaultCharset and if not the expected value then it could emit a warning like is done for a bad value of java.io.tmpdir.

One thing is whether to add a regression test to ensure that the default charset is UTF-8 when run with -Dfile.encoding=XXX and XXX is in the the service provider module.

Also, just thinking about diagnosability and whether there is any merit to have

src/java.base/share/classes/java/nio/charset/Charset.java line 632:

> 630: 
> 631:     @Stable
> 632:     private static Charset defaultCharset;

Style wise, I think the annotation is added between the private and static modifiers in other places.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12171

From zjx001202 at gmail.com  Thu Jan 26 12:35:06 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 26 Jan 2023 20:35:06 +0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT by
 default
Message-ID: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>

At present, the no-parameter toLowerCase and toUpperCase methods of String
are based on the default locale.

I checked all the uses of this method in OpenJDK, and found that most of
the use cases are suspicious, and even there are some hidden bugs.
For example, I just found that jdk.incubator.vector.LaneType will trigger
assertion failure on Turkish locale, and opened a PR for this problem:

https://github.com/openjdk/panama-vector/pull/210

In addition to such obvious problems, some use cases behave suspiciously
after calling Locale.setDefault.
I am investigating these problems and preparing to open a PR to solve these
hidden bugs.

In all the third-party libraries I have used, I have never seen the correct
use of these two methods.
Although the behavior of modifying API methods is destructive, I think it
is worthwhile to consider whether to modify its behavior for such a
suspicious method.
If users need locale-sensitive case conversion, it may be better to
explicitly use Locale.getDefault().
Using Locale.ROOT as the default value also helps to keep the behavior of
these two methods consistent with equalsIgnoreCase,
Character.toLowerCase/toUpperCase and other methods.

This is my rough idea. I hope to get your suggestions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/cb0b01c4/attachment.htm>

From forax at univ-mlv.fr  Thu Jan 26 13:34:36 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 26 Jan 2023 14:34:36 +0100 (CET)
Subject: [Proposal] Make toLowerCase and toUpperCase based on
 Locale.ROOT by default
In-Reply-To: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
Message-ID: <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>

> From: "Glavo" <zjx001202 at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, January 26, 2023 1:35:06 PM
> Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT by
> default

> At present, the no-parameter toLowerCase and toUpperCase methods of String are
> based on the default locale.

> I checked all the uses of this method in OpenJDK, and found that most of the use
> cases are suspicious, and even there are some hidden bugs.
> For example, I just found that jdk.incubator.vector.LaneType will trigger
> assertion failure on Turkish locale, and opened a PR for this problem:

>> [ https://github.com/openjdk/panama-vector/pull/210 |
>> https://github.com/openjdk/panama-vector/pull/210 ]

> In addition to such obvious problems, some use cases behave suspiciously after
> calling Locale.setDefault.
> I am investigating these problems and preparing to open a PR to solve these
> hidden bugs.

> In all the third-party libraries I have used, I have never seen the correct use
> of these two methods.
> Although the behavior of modifying API methods is destructive, I think it is
> worthwhile to consider whether to modify its behavior for such a suspicious
> method.
> If users need locale-sensitive case conversion, it may be better to explicitly
> use Locale.getDefault().
> Using Locale.ROOT as the default value also helps to keep the behavior of these
> two methods consistent with equalsIgnoreCase, Character.toLowerCase/toUpperCase
> and other methods.

> This is my rough idea. I hope to get your suggestions.

yes, it's a very very common bug, IntelliJ already warns when toLowerCase()/toUpperCase() is used without a Locale. 
I think the logical nest step is more to deprecate toLowerCase()/toUpperCase() than to change their implementation. 

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/4f4af0a4/attachment.htm>

From duke at openjdk.org  Thu Jan 26 14:13:20 2023
From: duke at openjdk.org (Hannes Greule)
Date: Thu, 26 Jan 2023 14:13:20 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v8]
In-Reply-To: <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>
Message-ID: <xqGo3H7R2Ik0cNQiqBnNfv0rcWIiDYLcHTQ4hll86w0=.be279bf6-651d-4438-a9ac-c2c95d3a754e@github.com>

On Wed, 25 Jan 2023 13:14:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merged JAVAC_FLAGS and EXCLUDES in Java.gmk

(not a reviewer) From a quick look at it, I noticed two things:

1. Input validation: As an example, it is possible to call `ClassfileVersion.of(-1, -1)`, and also use it to create a classfile from it. It looks like it is possible to create a classfile byte array with such a version, and the upper int bits are just ignored when writing the version. Should something like that be validated before? How much validation do you generally want to do (also regarding nullability etc)?

2. I've seen interfaces with `sealed public` aswell as `public sealed` as modifier order. I think this should be consistent. (maybe it also makes sense to add `sealed` to the `blessed-modifier-order.sh`?)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From zjx001202 at gmail.com  Thu Jan 26 14:42:45 2023
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 26 Jan 2023 22:42:45 +0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAJL5A3ngNbgz4OjX90P6wAAyk5fDYJMq3G0TZ+ZZF8z2fNt=kw@mail.gmail.com>

The reason why I want to modify their behavior is that a large number of
programs have misused this method.
By modifying the behavior, we can fix them without modifying their source
code.

However, it may be a better choice to mark it as deprecated.
After deprecating them, we can provide new API  methods that use
Locale.ROOT by default as a substitute.
Kotlin is using methods called lowercase() and uppercase() for this
purpose, which I think can be used for reference.

On Thu, Jan 26, 2023 at 9:36 PM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Glavo" <zjx001202 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Thursday, January 26, 2023 1:35:06 PM
> *Subject: *[Proposal] Make toLowerCase and toUpperCase based on
> Locale.ROOT by default
>
> At present, the no-parameter toLowerCase and toUpperCase methods of String
> are based on the default locale.
>
> I checked all the uses of this method in OpenJDK, and found that most of
> the use cases are suspicious, and even there are some hidden bugs.
> For example, I just found that jdk.incubator.vector.LaneType will trigger
> assertion failure on Turkish locale, and opened a PR for this problem:
>
> https://github.com/openjdk/panama-vector/pull/210
>
> In addition to such obvious problems, some use cases behave suspiciously
> after calling Locale.setDefault.
> I am investigating these problems and preparing to open a PR to solve
> these hidden bugs.
>
> In all the third-party libraries I have used, I have never seen the
> correct use of these two methods.
> Although the behavior of modifying API methods is destructive, I think it
> is worthwhile to consider whether to modify its behavior for such a
> suspicious method.
> If users need locale-sensitive case conversion, it may be better to
> explicitly use Locale.getDefault().
> Using Locale.ROOT as the default value also helps to keep the behavior of
> these two methods consistent with equalsIgnoreCase,
> Character.toLowerCase/toUpperCase and other methods.
>
> This is my rough idea. I hope to get your suggestions.
>
>
> yes, it's a very very common bug, IntelliJ already warns when
> toLowerCase()/toUpperCase() is used without a Locale.
> I think the logical nest step is more to deprecate
> toLowerCase()/toUpperCase() than to change their implementation.
>
> regards,
> R?mi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/61041005/attachment.htm>

From sgehwolf at openjdk.org  Thu Jan 26 14:50:21 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 26 Jan 2023 14:50:21 GMT
Subject: RFR: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large [v4]
In-Reply-To: <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
 <K-yP1FRRn8dJQgD9D6Vw_pL70yT-R1n1MrZxkMk2L0w=.eb33cf2a-14d8-4161-88a8-ad3d7b3b46f9@github.com>
Message-ID: <7qnmNfVdSLsV15mlF_qCSt_mbFqQErE_7uYoIBuglOw=.57fdf4aa-b47d-43de-be34-2ab65e3ea198@github.com>

On Wed, 25 Jan 2023 13:45:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>> 
>> Testing:
>> - [x] Container tests on linux x86_64 with cg v1
>> - [x] Container tests on linux x86_64 with cg v2
>> - [x] GHA (seem to have had some infra issues, so re-running)
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do proper error checking

Windows GHA test failure of [compiler/jsr292/ContinuousCallSiteTargetChange](https://github.com/jerboaa/jdk/actions/runs/4008775901#user-content-compiler_jsr292_continuouscallsitetargetchange) seems unrelated.

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From sgehwolf at openjdk.org  Thu Jan 26 14:54:25 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 26 Jan 2023 14:54:25 GMT
Subject: Integrated: 8299858: [Metrics] Swap memory limit reported incorrectly
 when too large
In-Reply-To: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
References: <AjZWUcYEG1p7dczXRJOT1DDyewGHgYePj8w-yR8nuew=.439c5ec0-d9c8-4ab8-8e28-cf0abb205067@github.com>
Message-ID: <gbNXSzmihkArfy_cYz-OMYWJTUFir7TVue60zjb7edM=.fbada969-cdd9-442f-ba29-3bb4a90f9665@github.com>

On Fri, 20 Jan 2023 15:53:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this fix to [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same handling for swap values exceeding what's possible in the non-container case. I.e. treats it as unlimited and fixes the reporting. This has been handled on the hotspot side similarly with [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
> 
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [x] GHA (seem to have had some infra issues, so re-running)

This pull request has now been integrated.

Changeset: 64ddf953
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64ddf9536f55fb81956ebde6dfc0a3c4147af371
Stats:     68 lines in 3 files changed: 65 ins; 1 del; 2 mod

8299858: [Metrics] Swap memory limit reported incorrectly when too large

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/12118

From asotona at openjdk.org  Thu Jan 26 15:51:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Jan 2023 15:51:23 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v9]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <BQW442x_TjzOwahDGgkHd5LcQrtakPS8jGCtu7LcCSI=.a9466213-535e-4d5e-94f1-d307eaf09b89@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  unification of sealed class modifiers order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/2bfc2b1a..931ca1c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=07-08

  Stats: 65 lines in 63 files changed: 0 ins; 0 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Thu Jan 26 15:57:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Jan 2023 15:57:20 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v8]
In-Reply-To: <xqGo3H7R2Ik0cNQiqBnNfv0rcWIiDYLcHTQ4hll86w0=.be279bf6-651d-4438-a9ac-c2c95d3a754e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <PvfhSdqnXFPfjklgOFYkpeXeo0OFVjAEHUd9cj1JTJo=.eb07fa41-01d9-49ff-86db-5e905ddf1217@github.com>
 <xqGo3H7R2Ik0cNQiqBnNfv0rcWIiDYLcHTQ4hll86w0=.be279bf6-651d-4438-a9ac-c2c95d3a754e@github.com>
Message-ID: <gA8QcBaK924poBdBjcbwPRExCs_SXdrTmMfExdgFbgE=.9fb515fb-7898-47b8-8ee2-0e1cf5fa3d21@github.com>

On Thu, 26 Jan 2023 14:10:47 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merged JAVAC_FLAGS and EXCLUDES in Java.gmk
>
> (not a reviewer) From a quick look at it, I noticed two things:
> 
> 1. Input validation: As an example, it is possible to call `ClassfileVersion.of(-1, -1)`, and also use it to create a classfile from it. It looks like it is possible to create a classfile byte array with such a version, and the upper int bits are just ignored when writing the version. Should something like that be validated before? How much validation do you generally want to do (also regarding nullability etc)?
> 
> 2. I've seen interfaces with `sealed public` aswell as `public sealed` as modifier order. I think this should be consistent. (maybe it also makes sense to add `sealed` to the `blessed-modifier-order.sh`?)

@SirYwell thanks for your review comments!
 1. Level of input validation and unification of that level across the whole Classfile API is important topic to discuss.
Please join us and raise this topic to classfile-api-dev at openjdk.org mailing list, as this pull request is not the best place for such discussions.
 2. General order of sealed modifier is not defined and it is another topic for discussion outside of this PR, however I've unified it to `public sealed` meanwhile.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rriggs at openjdk.org  Thu Jan 26 16:08:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Jan 2023 16:08:18 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <bSMNAtZQSAAp_kVC5HNj3PTavDNITZZVDZarXVhd8KE=.243d1099-2d99-4a59-80eb-7cfb4e502fb4@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Can the benchmark be moved to the JMH framework; it deals with the setup and measurements in a more predictable way.
See test/micro/org/openjdk/bench/jajva/nio/... for examples.

-------------

PR: https://git.openjdk.org/jdk/pull/12204

From duke at openjdk.org  Thu Jan 26 18:19:28 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 26 Jan 2023 18:19:28 GMT
Subject: Integrated: 8299444  java.util.Set.copyOf allocates needlessly for
 empty input collections
In-Reply-To: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
References: <8im4N7c3JAMB-2bHYH5N77o6Ju83dn119s5rUhtTr3k=.1603d4aa-e343-4094-85e7-5309c03fdbf7@github.com>
Message-ID: <NCAw3dAFa0kvG5LkMmdOlrTz2cRYwGEUh2FZkg2R5mQ=.7fa277a2-a30a-4155-9ffa-133d627d6325@github.com>

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Currently Set.copyOf allocates both a HashSet and a new empty array when the input collection is empty.
> 
> This patch avoids allocating anything for the case where the parameter collection's isEmpty returns true.

This pull request has now been integrated.

Changeset: a2a77033
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2a7703370caf07afd88b5cfe44e1a78eed699e9
Stats:     10 lines in 3 files changed: 6 ins; 0 del; 4 mod

8299444: java.util.Set.copyOf allocates needlessly for empty input collections

Reviewed-by: rriggs, shade, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/11847

From eirbjo at gmail.com  Thu Jan 26 18:57:41 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 26 Jan 2023 19:57:41 +0100
Subject: Update TestTooManyEntries to run non-manual
Message-ID: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>

Hi,

This PR updates the test TestTooManyEntries to not create gigabytes of
ZIP files, allowing the test to run fast and non-manual:

https://github.com/openjdk/jdk/pull/12231

May I please get some help with filing a JBS for this PR?

Thanks,
Eirik.

From duke at openjdk.org  Thu Jan 26 19:08:46 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 26 Jan 2023 19:08:46 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v13]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <AdIr-E-F2kJpGtraAbZltQnU0uyNHGYSBDdSfZHlbOY=.58429dbd-d4df-4b9b-b996-1d1a06964fd6@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Readd creation of helper methods for splitting up modules
  
  Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/cba36761..5fc6e3d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=11-12

  Stats: 51 lines in 1 file changed: 45 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Thu Jan 26 19:18:52 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 26 Jan 2023 19:18:52 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v14]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <w-5ffBjKSnasXEOw1EwWDrW9QE8h47IvbuoPydLa9bo=.e97abb27-da3c-421d-8f28-0fab36af9043@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/5fc6e3d5..2a381bde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=12-13

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Thu Jan 26 19:33:17 2023
From: duke at openjdk.org (Christoph)
Date: Thu, 26 Jan 2023 19:33:17 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v14]
In-Reply-To: <w-5ffBjKSnasXEOw1EwWDrW9QE8h47IvbuoPydLa9bo=.e97abb27-da3c-421d-8f28-0fab36af9043@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <w-5ffBjKSnasXEOw1EwWDrW9QE8h47IvbuoPydLa9bo=.e97abb27-da3c-421d-8f28-0fab36af9043@github.com>
Message-ID: <pLyEbxFDJ9qIcYj6FpKpmFnMy4epE6NVnE8rSbPwFsA=.37865c6b-e199-4745-95f0-e7b92665b18e@github.com>

On Thu, 26 Jan 2023 19:18:52 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove whitespace

We readded the splitting code and the test is passing. In the test we could make it work with up to 130 modules where each module _n_ requires all modules from _0...n_

Any further optimization ideas?

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From rriggs at openjdk.org  Thu Jan 26 19:36:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Jan 2023 19:36:20 GMT
Subject: RFR: 8300924: Method::invoke throws wrong exception type when
 passing wrong number of arguments to method with 4 or more parameters
In-Reply-To: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
References: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
Message-ID: <0QxQuWw11xF6YDEXUQTKzh0-8fFOg0ujr2yL4gCOgUI=.6f336d7c-2deb-4eb6-9771-4604f7601cb5@github.com>

On Tue, 24 Jan 2023 18:19:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix in core reflection to check if the number of actual and formal parameters differ before invoking the method or the constructor regardless of whether it's a specialized case or not.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12170

From mchung at openjdk.org  Thu Jan 26 21:10:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 21:10:58 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module
Message-ID: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>

Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.

However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    

This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

-------------

Commit messages:
 - 8217920: Lookup.defineClass injects a class that can access private members of any class in its own module

Changes: https://git.openjdk.org/jdk/pull/12236/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8217920
  Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12236.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12236/head:pull/12236

PR: https://git.openjdk.org/jdk/pull/12236

From naoto at openjdk.org  Thu Jan 26 21:50:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jan 2023 21:50:42 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v10]
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <krxbE7j97qJ9VWHPdkqhJDouiPEF7I93RCnknbUkD-Q=.0f02852c-2115-4638-be75-b109d2970a56@github.com>

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  @Stable style fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12171/files
  - new: https://git.openjdk.org/jdk/pull/12171/files/3f9165bb..427ee350

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12171&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12171.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12171/head:pull/12171

PR: https://git.openjdk.org/jdk/pull/12171

From naoto at openjdk.org  Thu Jan 26 21:50:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jan 2023 21:50:45 GMT
Subject: RFR: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty [v9]
In-Reply-To: <KtTp1XAgh_SeikUv7-DMjsM1TANtb_X8blcbmO3-GgE=.1f2b17d2-e43a-4651-8abe-56989859007a@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
 <m6nvyQKrBXljF10jU-wqE5CG4MriheYJD9lYGRYxGy4=.75a9b52a-84b7-412f-bbac-19e7055d0e38@github.com>
 <KtTp1XAgh_SeikUv7-DMjsM1TANtb_X8blcbmO3-GgE=.1f2b17d2-e43a-4651-8abe-56989859007a@github.com>
Message-ID: <3Q67fiyArRN902XfS4ahY_0sZwtEwGkHGz3-J8l2dpE=.991ba7eb-4c64-4afa-aa39-5d521e0655f4@github.com>

On Thu, 26 Jan 2023 12:07:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for the updates/iterations, I think you've got this to a good place.
> 
> One thing to think about is having System.initPhase3 read file.encoding and if not UTF-8, it could call Charset.defaultCharset and if not the expected value then it could emit a warning like is done for a bad value of java.io.tmpdir.
> 
> One thing is whether to add a regression test to ensure that the default charset is UTF-8 when run with -Dfile.encoding=XXX and XXX is in the service provider module.

Filed: https://bugs.openjdk.org/browse/JDK-8301199

> src/java.base/share/classes/java/nio/charset/Charset.java line 632:
> 
>> 630: 
>> 631:     @Stable
>> 632:     private static Charset defaultCharset;
> 
> Style wise, I think the annotation is added between the private and static modifiers in other places.

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From psandoz at openjdk.org  Thu Jan 26 21:57:18 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 26 Jan 2023 21:57:18 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module
In-Reply-To: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
Message-ID: <mOqXs614gwBoW9yBusfWchMS2Hq8kP1LyJg_6jmeWIY=.eff05df7-0a44-4f0f-a7aa-a5195ebd3299@github.com>

On Thu, 26 Jan 2023 21:03:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
> 
> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
> 
> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

src/java.base/share/classes/java/lang/Module.java line 607:

> 605:      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that can be used to
> 606:      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) inject classes}
> 607:      * in package {@code p}. </p>

Suggestion:

     * <p> A package {@code p} opened to module {@code M} means that code in
     * {@code M} is allowed to do deep reflection on all types in the package.
     * Further, if {@code M} reads this module it can obtain a
     * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that is allowed to
     * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) define classes}
     * in package {@code p}. </p>

Trying to reuse existing terms. I am presuming deep reflection implies on all members and setAccessible so there is no need to mention it?

Also i don't see "inject" used in existing text, so just reuse "define"?

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 240:

> 238:      * of {@code targetClass}. Extreme caution should be taken when opening a package
> 239:      * to another module.  The injected classes have the same full privilege
> 240:      * access as other members in the target module.

Suggestion:

     * The {@code Lookup} object returned by this method is allowed to
     * {@linkplain Lookup#defineClass(byte[]) define classes} in the runtime package
     * of {@code targetClass}. Extreme caution should be taken when opening a package
     * to another module as such defined classes have the same full privilege
     * access as other members in the target module.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 883:

> 881:      * of {@code T}. Extreme caution should be taken when opening a package
> 882:      * to another module.  The injected classes have the same full privilege
> 883:      * access as other members in the target module.

Suggestion:

     * <p>
     * The {@code Lookup} object returned by {@code privateLookupIn} is allowed to
     * {@linkplain Lookup#defineClass(byte[]) define classes} in the runtime package
     * of {@code T}. Extreme caution should be taken when opening a package
     * to another module as such defined classes have the same full privilege
     * access as other members in the target module.


You mention "target module" but i don't think i it is defined for the Lookup class JavaDoc. In this case are we referring to module M2?

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From duke at openjdk.org  Thu Jan 26 22:08:07 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 26 Jan 2023 22:08:07 GMT
Subject: RFR: 8301190: [vectorapi] The typeChar of LaneType is incorrect when
 default locale is tr
Message-ID: <ETUoz92u2OUx71ZvbjnOFvNqWXp_lhz_Q4nVEJEoS98=.4cf22b56-733d-43f3-9d22-26cfccea602d@github.com>

When the default Locale is tr, the letter `i` will be converted to `?` (U+0130) by `toUpperCase()`. This causes the assertion to fail.

-------------

Commit messages:
 - 8301190: [vectorapi] The typeChar of LaneType is incorrect when default locale is tr

Changes: https://git.openjdk.org/jdk/pull/12238/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12238&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301190
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12238.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12238/head:pull/12238

PR: https://git.openjdk.org/jdk/pull/12238

From mchung at openjdk.org  Thu Jan 26 22:27:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 22:27:36 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
Message-ID: <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>

> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
> 
> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
> 
> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12236/files
  - new: https://git.openjdk.org/jdk/pull/12236/files/a1d09325..4d3e879c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=00-01

  Stats: 13 lines in 2 files changed: 0 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12236.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12236/head:pull/12236

PR: https://git.openjdk.org/jdk/pull/12236

From jlu at openjdk.org  Thu Jan 26 22:34:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 26 Jan 2023 22:34:19 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v8]
In-Reply-To: <hwuMkMb5Pba4Ju_TTUi9_EarFro2rBbfTfDCZ5w-vjA=.0af4f14b-a393-4f68-9a99-c3dea0180b36@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <hwuMkMb5Pba4Ju_TTUi9_EarFro2rBbfTfDCZ5w-vjA=.0af4f14b-a393-4f68-9a99-c3dea0180b36@github.com>
Message-ID: <BQTxCWXVPt2LLBHlok8vLugokN5eLjm8HOpB6_tEXVQ=.955d2743-9511-40d2-bab6-f842797b1d20@github.com>

On Wed, 25 Jan 2023 20:21:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
>> 
>> _TimeZone.getTimeZone(String ID)
>> TimeZone.setID(String ID)
>> TimeZone.inDaylightTime(Date date)_
>> 
>> For example, 
>> 
>> 
>> String someID = null;
>> TimeZone tz1 = TimeZone.getTimeZone(someID);
>> ``` 
>> 
>> throws a `NullPointerException`
>> 
>> 
>> This PR adds the missing  _ at throws:_ for the mentioned methods. The wording and specification is also adjusted for the overridable methods in TZ to use "_may throw_" over "_will throw_" because of the possibility of external sub-classes that may override the method.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   STZ.inDT can also be overriden

The CSR has been approved and all the methods have been updated with the following specifications


- (Overridden) Instance methods **may** throw an NPE and (via implSpec) the particular method **will** indeed throw an NPE: _TimeZone.getDisplayName(boolean daylight, int style, Locale locale), TimeZone.setID(String ID), SimpleTimeZone.inDaylightTime(Date date)_
- (Overridden) Abstract methods **may** throw an NPE: _TimeZone.inDaylightTime(Date date)_
-  Static methods **will** throw an NPE: _Timezone.getTimeZone(String ID)_


Will "/integrate" once approved.

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From dnguyen at openjdk.org  Thu Jan 26 22:36:39 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jan 2023 22:36:39 GMT
Subject: [jdk20] Integrated: 8300719: JDK 20 RDP2 L10n resource files update
In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com>
Message-ID: <z7OxU1K7tY5joYmEwBKhNW6uZjOx05mtjEF7bRlLNIg=.d95c6b89-3c0d-4400-8def-cd5b3d59c3e7@github.com>

On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files.
> All tests passed

This pull request has now been integrated.

Changeset: a67b1e77
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/a67b1e77d33339f5db36c6d15bac0423a31eb5ee
Stats:     1023 lines in 82 files changed: 218 ins; 114 del; 691 mod

8300719: JDK 20 RDP2 L10n resource files update

Reviewed-by: cjplummer, naoto, prr, joehw, asemenyuk, jlu, lancea, ihse, jjg, weijun

-------------

PR: https://git.openjdk.org/jdk20/pull/116

From mchung at openjdk.org  Thu Jan 26 22:41:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 22:41:21 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <mOqXs614gwBoW9yBusfWchMS2Hq8kP1LyJg_6jmeWIY=.eff05df7-0a44-4f0f-a7aa-a5195ebd3299@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <mOqXs614gwBoW9yBusfWchMS2Hq8kP1LyJg_6jmeWIY=.eff05df7-0a44-4f0f-a7aa-a5195ebd3299@github.com>
Message-ID: <zYukHYDbrCaPqBjMtI7hG4KiqMpuOWVBhqHVwr8UPbE=.c987d290-bcf9-46fa-84d6-bd33807ad301@github.com>

On Thu, 26 Jan 2023 21:46:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
> src/java.base/share/classes/java/lang/Module.java line 607:
> 
>> 605:      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that can be used to
>> 606:      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) inject classes}
>> 607:      * in package {@code p}. </p>
> 
> Suggestion:
> 
>      * <p> A package {@code p} opened to module {@code M} means that code in
>      * {@code M} is allowed to do deep reflection on all types in the package.
>      * Further, if {@code M} reads this module it can obtain a
>      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that is allowed to
>      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) define classes}
>      * in package {@code p}. </p>
> 
> Trying to reuse existing terms. I am presuming deep reflection implies on all members and setAccessible so there is no need to mention it?
> 
> Also i don't see "inject" used in existing text, so just reuse "define"?

Using "define" is fine too. 

This method links to `AccessibleObject.setAccessible` and `MethodHandles.privateLookupIn`.   It may be adequate and no need to mention more.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 883:
> 
>> 881:      * of {@code T}. Extreme caution should be taken when opening a package
>> 882:      * to another module.  The injected classes have the same full privilege
>> 883:      * access as other members in the target module.
> 
> Suggestion:
> 
>      * <p>
>      * The {@code Lookup} object returned by {@code privateLookupIn} is allowed to
>      * {@linkplain Lookup#defineClass(byte[]) define classes} in the runtime package
>      * of {@code T}. Extreme caution should be taken when opening a package
>      * to another module as such defined classes have the same full privilege
>      * access as other members in the target module.
> 
> 
> You mention "target module" but i don't think i it is defined for the Lookup class JavaDoc. In this case are we referring to module M2?

yes, M2.  Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From psandoz at openjdk.org  Thu Jan 26 23:06:18 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 26 Jan 2023 23:06:18 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
Message-ID: <nNjvnMK9sV5ayiZytoGPjcYDO2iGNjg3qOC2jtDFgmo=.b4c730d3-f0ad-42b6-8df9-3b6fda77b908@github.com>

On Thu, 26 Jan 2023 22:27:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
>> 
>> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
>> 
>> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Looks good. All changes seem informational explaining the existing behavior so no CSR?

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12236

From mchung at openjdk.org  Thu Jan 26 23:36:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 26 Jan 2023 23:36:18 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <nNjvnMK9sV5ayiZytoGPjcYDO2iGNjg3qOC2jtDFgmo=.b4c730d3-f0ad-42b6-8df9-3b6fda77b908@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
 <nNjvnMK9sV5ayiZytoGPjcYDO2iGNjg3qOC2jtDFgmo=.b4c730d3-f0ad-42b6-8df9-3b6fda77b908@github.com>
Message-ID: <Qv4CoPlCmUQUADbVNJj4tbBRRvT0MP4LRvXQlVbLn8Q=.60b01cae-be44-4949-a3c4-9d1090e49120@github.com>

On Thu, 26 Jan 2023 23:03:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Looks good. All changes seem informational explaining the existing behavior so no CSR?

Since that's not spec change, no CSR is my take.

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From psandoz at openjdk.org  Thu Jan 26 23:54:16 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 26 Jan 2023 23:54:16 GMT
Subject: RFR: 8301190: [vectorapi] The typeChar of LaneType is incorrect
 when default locale is tr
In-Reply-To: <ETUoz92u2OUx71ZvbjnOFvNqWXp_lhz_Q4nVEJEoS98=.4cf22b56-733d-43f3-9d22-26cfccea602d@github.com>
References: <ETUoz92u2OUx71ZvbjnOFvNqWXp_lhz_Q4nVEJEoS98=.4cf22b56-733d-43f3-9d22-26cfccea602d@github.com>
Message-ID: <UQ27KU5MR3n8q9eZKWz4reuk2aKK6jYW2W63AHfSP2Q=.ac935986-d194-4b1f-b1d1-d52c2fbed1b1@github.com>

On Thu, 26 Jan 2023 21:56:22 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is tr, the letter `i` will be converted to `?` (U+0130) by `toUpperCase()`. This causes the assertion to fail.

Looks good. I am grateful the assert was in place.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12238

From smarks at openjdk.org  Fri Jan 27 00:22:17 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 27 Jan 2023 00:22:17 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
 <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
Message-ID: <6Axrj78CpMJ7ya0Mv4lH9iUD2okuqfHGsAIr4jPZOXg=.8ac2d90c-7f8f-4943-9c09-78a8b99f8952@github.com>

On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> number of minor cleanups could be done in Arrays and Collections utility classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
>> 
>> In Collections:
>> - A few obsolete "unchecked" and "rawtypes" suppressions
>> - Unnecessary local variable initializer in get() method
>> - Raw type can be avoided in a number of casts
>> - Explicit type parameters could be omitted or converted to diamonds
>> - A couple of javadoc links on private APIs are malformed
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert cast removal

src/java.base/share/classes/java/util/Collections.java line 1068:

> 1066: 
> 1067:         public Iterator<E> iterator() {
> 1068:             return new Iterator<>() {

Interesting, this whole family of changes is now possible because the original version of diamond didn't allow it to be used in the context of an anonymous inner class, because of non-denotability of types or some such. That restriction has been relaxed, but we never went back to fix these up.

I also note think that Martin objected to this sort of change in java.util.concurrent, but I'm OK with it here.

-------------

PR: https://git.openjdk.org/jdk/pull/12207

From smarks at openjdk.org  Fri Jan 27 00:36:19 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 27 Jan 2023 00:36:19 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
 <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
Message-ID: <Opo_Q2R3MTrys5U9ZQvCfadiv66Blr7Sc4XT79Py6RA=.29e41409-f0e2-4ba8-8e27-6b26454b0220@github.com>

On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> number of minor cleanups could be done in Arrays and Collections utility classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
>> 
>> In Collections:
>> - A few obsolete "unchecked" and "rawtypes" suppressions
>> - Unnecessary local variable initializer in get() method
>> - Raw type can be avoided in a number of casts
>> - Explicit type parameters could be omitted or converted to diamonds
>> - A couple of javadoc links on private APIs are malformed
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert cast removal

Overall looks good, no changes necessary, comments are just observations.

I'll come back and approve this when my CI build finishes.

src/java.base/share/classes/java/util/Collections.java line 1636:

> 1634:             @SuppressWarnings({"unchecked"})
> 1635:             UnmodifiableEntrySet(Set<? extends Map.Entry<? extends K, ? extends V>> s) {
> 1636:                 super((Set<Map.Entry<K, V>>)s);

Huh, good catch, there doesn't appear to be a "limitation in the type system" here, either currently or in older versions of javac going back to JDK 7.

src/java.base/share/classes/java/util/Collections.java line 5428:

> 5426:             return (o == this) ||
> 5427:                 (o instanceof ReverseComparator2<?> that &&
> 5428:                  cmp.equals(that.cmp));

Nice, using an instanceof pattern where we had missed it previously.

-------------

PR: https://git.openjdk.org/jdk/pull/12207

From darcy at openjdk.org  Fri Jan 27 00:51:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 00:51:26 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <6Axrj78CpMJ7ya0Mv4lH9iUD2okuqfHGsAIr4jPZOXg=.8ac2d90c-7f8f-4943-9c09-78a8b99f8952@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
 <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
 <6Axrj78CpMJ7ya0Mv4lH9iUD2okuqfHGsAIr4jPZOXg=.8ac2d90c-7f8f-4943-9c09-78a8b99f8952@github.com>
Message-ID: <h-dlxS04gp39J9sVEuNOqszwRD3GKjZZVNg2PKJiduE=.2f4ad7ad-0fa0-4583-b0a3-810fe4bf7b6b@github.com>

On Fri, 27 Jan 2023 00:19:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert cast removal
>
> src/java.base/share/classes/java/util/Collections.java line 1068:
> 
>> 1066: 
>> 1067:         public Iterator<E> iterator() {
>> 1068:             return new Iterator<>() {
> 
> Interesting, this whole family of changes is now possible because the original version of diamond didn't allow it to be used in the context of an anonymous inner class, because of non-denotability of types or some such. That restriction has been relaxed, but we never went back to fix these up.
> 
> I also note think that Martin objected to this sort of change in java.util.concurrent, but I'm OK with it here.

Yes, the improved version of diamond was
JDK-8062373: Project Coin: diamond and anonymous classes
as part of JEP 213.

-------------

PR: https://git.openjdk.org/jdk/pull/12207

From duke at openjdk.org  Fri Jan 27 01:20:31 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 01:20:31 GMT
Subject: Integrated: 8301190: [vectorapi] The typeChar of LaneType is incorrect
 when default locale is tr
In-Reply-To: <ETUoz92u2OUx71ZvbjnOFvNqWXp_lhz_Q4nVEJEoS98=.4cf22b56-733d-43f3-9d22-26cfccea602d@github.com>
References: <ETUoz92u2OUx71ZvbjnOFvNqWXp_lhz_Q4nVEJEoS98=.4cf22b56-733d-43f3-9d22-26cfccea602d@github.com>
Message-ID: <E1Z5Ncy6G-_VgtK-Zlou_qILszGfZDoDYcDvjX52tGw=.02133779-a26a-460a-9626-4d9564bdee8e@github.com>

On Thu, 26 Jan 2023 21:56:22 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is tr, the letter `i` will be converted to `?` (U+0130) by `toUpperCase()`. This causes the assertion to fail.

This pull request has now been integrated.

Changeset: c3ff1514
Author:    Glavo <zjx001202 at gmail.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3ff151457102cd45e3c7a49a235a04066beca60
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8301190: [vectorapi] The typeChar of LaneType is incorrect when default locale is tr

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/12238

From dnguyen at openjdk.org  Fri Jan 27 01:50:08 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 01:50:08 GMT
Subject: [jdk20] RFR: 8301206: Fix issue with LocaleData after JDK-8300719
Message-ID: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>

Localization update didn't include an update to LocaleData file. This PR addresses this by updating the file with the newly translated values. The LocaleDataTest now passes. This should address the recent related failures to LocaleData.

-------------

Commit messages:
 - Update LocaleData

Changes: https://git.openjdk.org/jdk20/pull/118/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301206
  Stats: 52 lines in 1 file changed: 0 ins; 0 del; 52 mod
  Patch: https://git.openjdk.org/jdk20/pull/118.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/118/head:pull/118

PR: https://git.openjdk.org/jdk20/pull/118

From naoto at openjdk.org  Fri Jan 27 02:05:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Jan 2023 02:05:24 GMT
Subject: [jdk20] RFR: 8301206: Fix issue with LocaleData after JDK-8300719
In-Reply-To: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
References: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
Message-ID: <guTqjx4Whb1GvmS6HlfJ-cJLLp033Zs_zMMybbr_nsA=.adeadfde-febc-4312-bb0c-3fdf80205e44@github.com>

On Fri, 27 Jan 2023 01:43:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Localization update didn't include an update to LocaleData file. This PR addresses this by updating the file with the newly translated values. The LocaleDataTest now passes. This should address the recent related failures to LocaleData.

The fix itself looks good. Add the bug id to `LocaleDataTest.java`

-------------

PR: https://git.openjdk.org/jdk20/pull/118

From dnguyen at openjdk.org  Fri Jan 27 02:34:37 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 02:34:37 GMT
Subject: [jdk20] RFR: 8301206: Fix issue with LocaleData after JDK-8300719
 [v2]
In-Reply-To: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
References: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
Message-ID: <UV2mu--XN_MBLhb6PWrE0i11q7b-d1UQFjIfARpSDks=.97ad5706-324d-45b6-a57c-2ee959f7d726@github.com>

> Localization update didn't include an update to LocaleData file. This PR addresses this by updating the file with the newly translated values. The LocaleDataTest now passes. This should address the recent related failures to LocaleData.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add bugid. Update year

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/118/files
  - new: https://git.openjdk.org/jdk20/pull/118/files/a1d7fc21..87a37655

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=118&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=118&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/118.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/118/head:pull/118

PR: https://git.openjdk.org/jdk20/pull/118

From dnguyen at openjdk.org  Fri Jan 27 02:54:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 02:54:16 GMT
Subject: [jdk20] RFR: 8301206: Fix issue with LocaleData after JDK-8300719
 [v2]
In-Reply-To: <guTqjx4Whb1GvmS6HlfJ-cJLLp033Zs_zMMybbr_nsA=.adeadfde-febc-4312-bb0c-3fdf80205e44@github.com>
References: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
 <guTqjx4Whb1GvmS6HlfJ-cJLLp033Zs_zMMybbr_nsA=.adeadfde-febc-4312-bb0c-3fdf80205e44@github.com>
Message-ID: <9AKbqVXq9FN90NcKKnCEKl0U8CV26o8p_2ogpQPXTbU=.ed3fe886-ce24-4380-a3b0-dbe0b9ce5203@github.com>

On Fri, 27 Jan 2023 02:02:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The fix itself looks good. Add the bug id to `LocaleDataTest.java`

Added BugID to the list of BugID's in `LocaleDataTest.java`

-------------

PR: https://git.openjdk.org/jdk20/pull/118

From xuelei.f at gmail.com  Fri Jan 27 05:17:56 2023
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Thu, 26 Jan 2023 21:17:56 -0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
Message-ID: <E9BF3B91-5664-4EDD-8531-E0B9F6A18E0B@gmail.com>

Just curious, this is a known issue for many years, how those areas like Turkish survive?  Is there a workaround for those areas or the use of the methods is not common any longer?

Xuelei 

> On Jan 26, 2023, at 4:35 AM, Glavo <zjx001202 at gmail.com> wrote:
> 
> At present, the no-parameter toLowerCase and toUpperCase methods of String are based on the default locale.
> 
> I checked all the uses of this method in OpenJDK, and found that most of the use cases are suspicious, and even there are some hidden bugs.
> For example, I just found that jdk.incubator.vector.LaneType will trigger assertion failure on Turkish locale, and opened a PR for this problem:
> 
> https://github.com/openjdk/panama-vector/pull/210
> 
> In addition to such obvious problems, some use cases behave suspiciously after calling Locale.setDefault.
> I am investigating these problems and preparing to open a PR to solve these hidden bugs.
> 
> In all the third-party libraries I have used, I have never seen the correct use of these two methods.
> Although the behavior of modifying API methods is destructive, I think it is worthwhile to consider whether to modify its behavior for such a suspicious method.
> If users need locale-sensitive case conversion, it may be better to explicitly use Locale.getDefault().
> Using Locale.ROOT as the default value also helps to keep the behavior of these two methods consistent with equalsIgnoreCase, Character.toLowerCase/toUpperCase and other methods.
> 
> This is my rough idea. I hope to get your suggestions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/8b6aacf6/attachment-0001.htm>

From zjx001202 at gmail.com  Fri Jan 27 05:27:43 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 27 Jan 2023 13:27:43 +0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <E9BF3B91-5664-4EDD-8531-E0B9F6A18E0B@gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <E9BF3B91-5664-4EDD-8531-E0B9F6A18E0B@gmail.com>
Message-ID: <CAJL5A3kD9AtxMp5FeRShXwrLK-E8m0-U1V-2qJ48gL9ZFanu1A@mail.gmail.com>

They only need to use "str".toLowerCase(Locale.ROOT).

On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fan <xuelei.f at gmail.com> wrote:

> Just curious, this is a known issue for many years, how those areas like
> Turkish survive?  Is there a workaround for those areas or the use of the
> methods is not common any longer?
>
> Xuelei
>
> On Jan 26, 2023, at 4:35 AM, Glavo <zjx001202 at gmail.com> wrote:
>
> At present, the no-parameter toLowerCase and toUpperCase methods of String
> are based on the default locale.
>
> I checked all the uses of this method in OpenJDK, and found that most of
> the use cases are suspicious, and even there are some hidden bugs.
> For example, I just found that jdk.incubator.vector.LaneType will trigger
> assertion failure on Turkish locale, and opened a PR for this problem:
>
> https://github.com/openjdk/panama-vector/pull/210
>
> In addition to such obvious problems, some use cases behave suspiciously
> after calling Locale.setDefault.
> I am investigating these problems and preparing to open a PR to solve
> these hidden bugs.
>
> In all the third-party libraries I have used, I have never seen the
> correct use of these two methods.
> Although the behavior of modifying API methods is destructive, I think it
> is worthwhile to consider whether to modify its behavior for such a
> suspicious method.
> If users need locale-sensitive case conversion, it may be better to
> explicitly use Locale.getDefault().
> Using Locale.ROOT as the default value also helps to keep the behavior of
> these two methods consistent with equalsIgnoreCase,
> Character.toLowerCase/toUpperCase and other methods.
>
> This is my rough idea. I hope to get your suggestions.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230127/c451c7d6/attachment.htm>

From zjx001202 at gmail.com  Fri Jan 27 05:42:14 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 27 Jan 2023 13:42:14 +0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAJL5A3kr0CYKtedysNa=Zd9gwgx_2K+d=59cM-cmrHnSN_a-8A@mail.gmail.com>

I analyzed the usage of toLowerCase and toUpperCase in OpenJDK more
carefully,
 and found that none of the use cases really expected locale-sensitive
behavior, **all** use cases were misused without exception.

I think more third-party libraries and applications should be investigated
to determine how common this situation is.
If most of the use cases are misusing it, I think its behavior should be
modified and marked as deprecated to avoid confusion.
Then, we can create new APIs as their substitutes.




On Thu, Jan 26, 2023 at 9:36 PM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Glavo" <zjx001202 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Thursday, January 26, 2023 1:35:06 PM
> *Subject: *[Proposal] Make toLowerCase and toUpperCase based on
> Locale.ROOT by default
>
> At present, the no-parameter toLowerCase and toUpperCase methods of String
> are based on the default locale.
>
> I checked all the uses of this method in OpenJDK, and found that most of
> the use cases are suspicious, and even there are some hidden bugs.
> For example, I just found that jdk.incubator.vector.LaneType will trigger
> assertion failure on Turkish locale, and opened a PR for this problem:
>
> https://github.com/openjdk/panama-vector/pull/210
>
> In addition to such obvious problems, some use cases behave suspiciously
> after calling Locale.setDefault.
> I am investigating these problems and preparing to open a PR to solve
> these hidden bugs.
>
> In all the third-party libraries I have used, I have never seen the
> correct use of these two methods.
> Although the behavior of modifying API methods is destructive, I think it
> is worthwhile to consider whether to modify its behavior for such a
> suspicious method.
> If users need locale-sensitive case conversion, it may be better to
> explicitly use Locale.getDefault().
> Using Locale.ROOT as the default value also helps to keep the behavior of
> these two methods consistent with equalsIgnoreCase,
> Character.toLowerCase/toUpperCase and other methods.
>
> This is my rough idea. I hope to get your suggestions.
>
>
> yes, it's a very very common bug, IntelliJ already warns when
> toLowerCase()/toUpperCase() is used without a Locale.
> I think the logical nest step is more to deprecate
> toLowerCase()/toUpperCase() than to change their implementation.
>
> regards,
> R?mi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230127/cf9f7433/attachment.htm>

From xuelei.f at gmail.com  Fri Jan 27 05:52:26 2023
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Thu, 26 Jan 2023 21:52:26 -0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <CAJL5A3kD9AtxMp5FeRShXwrLK-E8m0-U1V-2qJ48gL9ZFanu1A@mail.gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <E9BF3B91-5664-4EDD-8531-E0B9F6A18E0B@gmail.com>
 <CAJL5A3kD9AtxMp5FeRShXwrLK-E8m0-U1V-2qJ48gL9ZFanu1A@mail.gmail.com>
Message-ID: <C4EBBEA0-FFC3-4EC8-9901-DFF44AA9E8CA@gmail.com>



> On Jan 26, 2023, at 9:27 PM, Glavo <zjx001202 at gmail.com> wrote:
> 
> They only need to use "str".toLowerCase(Locale.ROOT).

Sorry, with a workaround I meant to have toLowerCase() work without modifying the existing source code to use toLowerCase(Locale.ROOT).

Xuelei

> 
> On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fan <xuelei.f at gmail.com <mailto:xuelei.f at gmail.com>> wrote:
>> Just curious, this is a known issue for many years, how those areas like Turkish survive?  Is there a workaround for those areas or the use of the methods is not common any longer?
>> 
>> Xuelei 
>> 
>>> On Jan 26, 2023, at 4:35 AM, Glavo <zjx001202 at gmail.com <mailto:zjx001202 at gmail.com>> wrote:
>>> 
>>> At present, the no-parameter toLowerCase and toUpperCase methods of String are based on the default locale.
>>> 
>>> I checked all the uses of this method in OpenJDK, and found that most of the use cases are suspicious, and even there are some hidden bugs.
>>> For example, I just found that jdk.incubator.vector.LaneType will trigger assertion failure on Turkish locale, and opened a PR for this problem:
>>> 
>>> https://github.com/openjdk/panama-vector/pull/210
>>> 
>>> In addition to such obvious problems, some use cases behave suspiciously after calling Locale.setDefault.
>>> I am investigating these problems and preparing to open a PR to solve these hidden bugs.
>>> 
>>> In all the third-party libraries I have used, I have never seen the correct use of these two methods.
>>> Although the behavior of modifying API methods is destructive, I think it is worthwhile to consider whether to modify its behavior for such a suspicious method.
>>> If users need locale-sensitive case conversion, it may be better to explicitly use Locale.getDefault().
>>> Using Locale.ROOT as the default value also helps to keep the behavior of these two methods consistent with equalsIgnoreCase, Character.toLowerCase/toUpperCase and other methods.
>>> 
>>> This is my rough idea. I hope to get your suggestions.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/f91397b7/attachment-0001.htm>

From xuelei.f at gmail.com  Fri Jan 27 06:17:16 2023
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Thu, 26 Jan 2023 22:17:16 -0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <C4EBBEA0-FFC3-4EC8-9901-DFF44AA9E8CA@gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <E9BF3B91-5664-4EDD-8531-E0B9F6A18E0B@gmail.com>
 <CAJL5A3kD9AtxMp5FeRShXwrLK-E8m0-U1V-2qJ48gL9ZFanu1A@mail.gmail.com>
 <C4EBBEA0-FFC3-4EC8-9901-DFF44AA9E8CA@gmail.com>
Message-ID: <C0D8921F-981A-40FD-8BBF-B70321A0139A@gmail.com>



> On Jan 26, 2023, at 9:52 PM, Xuelei Fan <Xuelei.F at Gmail.com> wrote:
> 
> 
> 
>> On Jan 26, 2023, at 9:27 PM, Glavo <zjx001202 at gmail.com> wrote:
>> 
>> They only need to use "str".toLowerCase(Locale.ROOT).
> 
> Sorry, with a workaround I meant to have toLowerCase() work without modifying the existing source code to use toLowerCase(Locale.ROOT).
> 

Never mind, google helped me. There is workaround <https://discuss.gradle.org/t/locale-specific-tolowercase-and-touppercase-breaks-the-build-on-turkish-os/17840/5> in practice by using System Properties, user.country and user.language.


Thanks,
Xuelei


> Xuelei
> 
>> 
>> On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fan <xuelei.f at gmail.com <mailto:xuelei.f at gmail.com>> wrote:
>>> Just curious, this is a known issue for many years, how those areas like Turkish survive?  Is there a workaround for those areas or the use of the methods is not common any longer?
>>> 
>>> Xuelei 
>>> 
>>>> On Jan 26, 2023, at 4:35 AM, Glavo <zjx001202 at gmail.com <mailto:zjx001202 at gmail.com>> wrote:
>>>> 
>>>> At present, the no-parameter toLowerCase and toUpperCase methods of String are based on the default locale.
>>>> 
>>>> I checked all the uses of this method in OpenJDK, and found that most of the use cases are suspicious, and even there are some hidden bugs.
>>>> For example, I just found that jdk.incubator.vector.LaneType will trigger assertion failure on Turkish locale, and opened a PR for this problem:
>>>> 
>>>> https://github.com/openjdk/panama-vector/pull/210
>>>> 
>>>> In addition to such obvious problems, some use cases behave suspiciously after calling Locale.setDefault.
>>>> I am investigating these problems and preparing to open a PR to solve these hidden bugs.
>>>> 
>>>> In all the third-party libraries I have used, I have never seen the correct use of these two methods.
>>>> Although the behavior of modifying API methods is destructive, I think it is worthwhile to consider whether to modify its behavior for such a suspicious method.
>>>> If users need locale-sensitive case conversion, it may be better to explicitly use Locale.getDefault().
>>>> Using Locale.ROOT as the default value also helps to keep the behavior of these two methods consistent with equalsIgnoreCase, Character.toLowerCase/toUpperCase and other methods.
>>>> 
>>>> This is my rough idea. I hope to get your suggestions.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/0eea3775/attachment.htm>

From darcy at openjdk.org  Fri Jan 27 06:59:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 06:59:49 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java
Message-ID: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>

Restarting the port of FDLIBM to Java with the log10 method.

There are two port, the first a near-transliteration from C port to use as a test reference in

test/jdk/java/lang/StrictMath/FdlibmTranslit.java

and a more idiomatic Java port in 

src/java.base/share/classes/java/lang/FdLibm.java

First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

-------------

Commit messages:
 - Reformat code some more.
 - Change to hex fp literals, misc updates.
 - Use more idiomatic style in ported FDLBIM code.
 - Merge branch 'master' into JDK-8301205
 - JDK-8301205: Port fdlibm log10 to Java

Changes: https://git.openjdk.org/jdk/pull/12242/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12242&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301205
  Stats: 222 lines in 4 files changed: 207 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12242.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12242/head:pull/12242

PR: https://git.openjdk.org/jdk/pull/12242

From darcy at openjdk.org  Fri Jan 27 07:31:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 07:31:17 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java
In-Reply-To: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
Message-ID: <iBIuJKlqqcIWt1l_rBQDtmc3GMaUKRuoGo6t2pUiFNA=.54a71cd9-717c-415a-8bf3-42044d420d92@github.com>

On Fri, 27 Jan 2023 06:52:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Restarting the port of FDLIBM to Java with the log10 method.
> 
> There are two port, the first a near-transliteration from C port to use as a test reference in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> and a more idiomatic Java port in 
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

PS The C file used as the basis of the port is

src/java.base/share/native/libfdlibm/e_log10.c

One difference to highlight between the original C and transliteration port is the line

i  = ((unsigned)k&0x80000000)>>31; // C version
vs
i  = (k&0x80000000)>>>31; // unsigned shift

-------------

PR: https://git.openjdk.org/jdk/pull/12242

From turbanoff at gmail.com  Fri Jan 27 08:04:27 2023
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Fri, 27 Jan 2023 11:04:27 +0300
Subject: ConcurrentModificationException has links to Vector, Hashtable,
 LinkedList
Message-ID: <CAF+DQ5de5kUt_FD19J8VvTonskvgFd_zOqe58GfxjDyY9g_TaQ@mail.gmail.com>

Hello.
I've noticed that ConcurrentModificationException javadoc has a "See
Also" section which contains links to legacy collections: Vector,
Hashtable, LinkedList.
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/ConcurrentModificationException.html
I wonder if it makes sense to replace/update this linkes to
ArrayList,HashMap instead?

I think it's better to "advertise" more modern collections.

Andrey Turbanov

From mbaesken at openjdk.org  Fri Jan 27 08:40:49 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jan 2023 08:40:49 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le
Message-ID: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>

On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
(especially when running with fastdebug binaries)
So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.

-------------

Commit messages:
 - JDK-8301163

Changes: https://git.openjdk.org/jdk/pull/12244/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301163
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12244.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12244/head:pull/12244

PR: https://git.openjdk.org/jdk/pull/12244

From rrich at openjdk.org  Fri Jan 27 08:44:19 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 27 Jan 2023 08:44:19 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le
In-Reply-To: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
Message-ID: <jd9DeKq9iIhZ4LI81gQwJIhxmqSM66AW_ByXummKhCw=.9b43429b-88cf-4206-9925-9d23ef159343@github.com>

On Fri, 27 Jan 2023 08:33:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
> (especially when running with fastdebug binaries)
> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.

test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 94:

> 92:                                        + "on macosx-aarch64");
> 93:         }
> 94:         if (Platform.isLinux() && Platform.isPPC()) {

I wouldn't limit to Linux.

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From mbaesken at openjdk.org  Fri Jan 27 08:52:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jan 2023 08:52:21 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v2]
In-Reply-To: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
Message-ID: <29uTfCWYTQMK3jM1idjzy4vWWoGcl3aE-nmuX-O08xU=.36bed675-8cf4-4bd1-8cf3-940d8610e17b@github.com>

> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
> (especially when running with fastdebug binaries)
> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Do not limit to Linux, handle all PPC platforms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12244/files
  - new: https://git.openjdk.org/jdk/pull/12244/files/856c99c7..74f2b80b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12244&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12244&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12244.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12244/head:pull/12244

PR: https://git.openjdk.org/jdk/pull/12244

From mbaesken at openjdk.org  Fri Jan 27 08:52:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jan 2023 08:52:23 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v2]
In-Reply-To: <jd9DeKq9iIhZ4LI81gQwJIhxmqSM66AW_ByXummKhCw=.9b43429b-88cf-4206-9925-9d23ef159343@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
 <jd9DeKq9iIhZ4LI81gQwJIhxmqSM66AW_ByXummKhCw=.9b43429b-88cf-4206-9925-9d23ef159343@github.com>
Message-ID: <aGuSVltocDnxkKxRBJ-pSuCVGlIvuYoga4TG5WU39Qs=.713fb2b9-7a9d-41ab-a69a-5aa1dedbd28a@github.com>

On Fri, 27 Jan 2023 08:41:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not limit to Linux, handle all PPC platforms
>
> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 94:
> 
>> 92:                                        + "on macosx-aarch64");
>> 93:         }
>> 94:         if (Platform.isLinux() && Platform.isPPC()) {
> 
> I wouldn't limit to Linux.

I changed it, removed the Linux related check.

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From duke at openjdk.org  Fri Jan 27 09:45:00 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 09:45:00 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
Message-ID: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>

I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.

Their return values can be trusted, so many unnecessary array duplication can be eliminated.

-------------

Commit messages:
 - fix checkstyle
 - Update ImmutableCollections
 - Merge branch 'master' into array-copy
 - Rollback Collectors
 - fix checkstyle
 - update
 - Update List.copyOf
 - Return value of toArray of collection types in java.base should be trusted

Changes: https://git.openjdk.org/jdk/pull/12212/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301220
  Stats: 14 lines in 6 files changed: 2 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12212.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12212/head:pull/12212

PR: https://git.openjdk.org/jdk/pull/12212

From stsypanov at openjdk.org  Fri Jan 27 09:45:02 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 27 Jan 2023 09:45:02 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
Message-ID: <Dw5Z-B9FvKAhcJ_ORZBfaqEmbr12I9eqBaOpZGChieg=.f5c5ee36-a2e2-4eb3-80ce-8f236244aed9@github.com>

On Thu, 26 Jan 2023 06:46:16 GMT, Glavo <duke at openjdk.org> wrote:

> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
> 
> Their return values can be trusted, so many unnecessary array duplication can be eliminated.

You could also have a look into `PriorityQueue.initElementsFromCollection()`

@Glavo I've filed https://bugs.openjdk.org/browse/JDK-8301220 so you can use it for this PR.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 746:

> 744:             int len = es.length;
> 745:             Object[] newElements;
> 746:             if (len == 0 && c.getClass().getModule() == Object.class.getModule()) {

I think as soon as we anyway assign the array from trusted collection, we don't need `len == 0` check here any more

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Fri Jan 27 09:45:04 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 09:45:04 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <Dw5Z-B9FvKAhcJ_ORZBfaqEmbr12I9eqBaOpZGChieg=.f5c5ee36-a2e2-4eb3-80ce-8f236244aed9@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <Dw5Z-B9FvKAhcJ_ORZBfaqEmbr12I9eqBaOpZGChieg=.f5c5ee36-a2e2-4eb3-80ce-8f236244aed9@github.com>
Message-ID: <E8Sh3jiPbpOq3zLjyJQmp-1i0nP8i3MDfJkXwlpGLVk=.0a9bc491-030a-4ba9-887f-423478f790b1@github.com>

On Fri, 27 Jan 2023 09:35:00 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> @Glavo I've filed https://bugs.openjdk.org/browse/JDK-8301220 so you can use it for this PR.

Thank you!

> I think as soon as we anyway assign the array from trusted collection, we don't need `len == 0` check here any more

I think it is necessary to check the length here. 

If the length of the current COWArrayList is not zero, it is necessary to copy the elements to a larger new array.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From stsypanov at openjdk.org  Fri Jan 27 09:45:07 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 27 Jan 2023 09:45:07 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <E8Sh3jiPbpOq3zLjyJQmp-1i0nP8i3MDfJkXwlpGLVk=.0a9bc491-030a-4ba9-887f-423478f790b1@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <Dw5Z-B9FvKAhcJ_ORZBfaqEmbr12I9eqBaOpZGChieg=.f5c5ee36-a2e2-4eb3-80ce-8f236244aed9@github.com>
 <E8Sh3jiPbpOq3zLjyJQmp-1i0nP8i3MDfJkXwlpGLVk=.0a9bc491-030a-4ba9-887f-423478f790b1@github.com>
Message-ID: <PaD2I2vEesJ3j_EYrA5oQY8vv5LivKoh0-mQLJotgu0=.cefb4287-aded-44d4-9092-d35b973ac3c0@github.com>

On Thu, 26 Jan 2023 10:01:21 GMT, Glavo <duke at openjdk.org> wrote:

>  it is necessary to copy the elements to a larger new array

Right, I missed this is addAll() method. Btw, in this class you could do similar optimization in constructor as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Fri Jan 27 09:45:07 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 09:45:07 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <PaD2I2vEesJ3j_EYrA5oQY8vv5LivKoh0-mQLJotgu0=.cefb4287-aded-44d4-9092-d35b973ac3c0@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <Dw5Z-B9FvKAhcJ_ORZBfaqEmbr12I9eqBaOpZGChieg=.f5c5ee36-a2e2-4eb3-80ce-8f236244aed9@github.com>
 <E8Sh3jiPbpOq3zLjyJQmp-1i0nP8i3MDfJkXwlpGLVk=.0a9bc491-030a-4ba9-887f-423478f790b1@github.com>
 <PaD2I2vEesJ3j_EYrA5oQY8vv5LivKoh0-mQLJotgu0=.cefb4287-aded-44d4-9092-d35b973ac3c0@github.com>
Message-ID: <JHB4NMEmtqzMFn2YeEVoENh5t8gLN8sur2EegGsvd7w=.c091ca64-da80-493c-8b37-6eaf46d7e742@github.com>

On Thu, 26 Jan 2023 10:05:28 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> > it is necessary to copy the elements to a larger new array
> 
> Right, I missed this is addAll() method. Btw, in this class you could do similar optimization in constructor as well.

Just now, I have pushed some updates and used similar optimizations in some places that were missed before.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From rrich at openjdk.org  Fri Jan 27 10:10:22 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 27 Jan 2023 10:10:22 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v2]
In-Reply-To: <29uTfCWYTQMK3jM1idjzy4vWWoGcl3aE-nmuX-O08xU=.36bed675-8cf4-4bd1-8cf3-940d8610e17b@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
 <29uTfCWYTQMK3jM1idjzy4vWWoGcl3aE-nmuX-O08xU=.36bed675-8cf4-4bd1-8cf3-940d8610e17b@github.com>
Message-ID: <6HMOpiB6bxmDjgC0im8kF5M4-u89MyZO699aGcWWKTs=.8ce7529f-3640-472a-a8b6-5f92a2ea8853@github.com>

On Fri, 27 Jan 2023 08:52:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
>> (especially when running with fastdebug binaries)
>> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not limit to Linux, handle all PPC platforms

test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 95:

> 93:         }
> 94:         if (Platform.isPPC()) {
> 95:             COMPILATION_TIMEOUT = COMPILATION_TIMEOUT * 2;

I guess this won't compile. COMPILATION_TIMEOUT is final.

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From mbaesken at openjdk.org  Fri Jan 27 10:20:26 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jan 2023 10:20:26 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v3]
In-Reply-To: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
Message-ID: <K7DWDyL6MROVbVLPPkXwwgxgMBAiyDHpS5jfBrM7Es8=.49661d68-7af7-457c-aaec-bc046f089c37@github.com>

> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
> (especially when running with fastdebug binaries)
> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  COMPILATION_TIMEOUT cannot be final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12244/files
  - new: https://git.openjdk.org/jdk/pull/12244/files/74f2b80b..e8e3c3c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12244&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12244&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12244.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12244/head:pull/12244

PR: https://git.openjdk.org/jdk/pull/12244

From mbaesken at openjdk.org  Fri Jan 27 10:20:31 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jan 2023 10:20:31 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v2]
In-Reply-To: <6HMOpiB6bxmDjgC0im8kF5M4-u89MyZO699aGcWWKTs=.8ce7529f-3640-472a-a8b6-5f92a2ea8853@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
 <29uTfCWYTQMK3jM1idjzy4vWWoGcl3aE-nmuX-O08xU=.36bed675-8cf4-4bd1-8cf3-940d8610e17b@github.com>
 <6HMOpiB6bxmDjgC0im8kF5M4-u89MyZO699aGcWWKTs=.8ce7529f-3640-472a-a8b6-5f92a2ea8853@github.com>
Message-ID: <hHQiJCTvIbYB5UOxsVs69duypl5XjU4snJKgHCDnd6Q=.9bafcdd4-4d77-4e08-ac77-65239836e501@github.com>

On Fri, 27 Jan 2023 10:07:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not limit to Linux, handle all PPC platforms
>
> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 95:
> 
>> 93:         }
>> 94:         if (Platform.isPPC()) {
>> 95:             COMPILATION_TIMEOUT = COMPILATION_TIMEOUT * 2;
> 
> I guess this won't compile. COMPILATION_TIMEOUT is final.

Yes correct, it cannot be final any more.

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From rrich at openjdk.org  Fri Jan 27 10:23:16 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 27 Jan 2023 10:23:16 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v3]
In-Reply-To: <K7DWDyL6MROVbVLPPkXwwgxgMBAiyDHpS5jfBrM7Es8=.49661d68-7af7-457c-aaec-bc046f089c37@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
 <K7DWDyL6MROVbVLPPkXwwgxgMBAiyDHpS5jfBrM7Es8=.49661d68-7af7-457c-aaec-bc046f089c37@github.com>
Message-ID: <YSrsmj4LpcqxT9H2kwxfCOWKkrzLyOUM_LJAdEPIwxI=.1bebf0d3-d1a1-4282-95f1-cabf1d1bdaad@github.com>

On Fri, 27 Jan 2023 10:20:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
>> (especially when running with fastdebug binaries)
>> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   COMPILATION_TIMEOUT cannot be final

Marked as reviewed by rrich (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From rrich at openjdk.org  Fri Jan 27 10:23:21 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 27 Jan 2023 10:23:21 GMT
Subject: RFR: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java increase
 COMPILATION_TIMEOUT for Linux ppc64le [v2]
In-Reply-To: <hHQiJCTvIbYB5UOxsVs69duypl5XjU4snJKgHCDnd6Q=.9bafcdd4-4d77-4e08-ac77-65239836e501@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
 <29uTfCWYTQMK3jM1idjzy4vWWoGcl3aE-nmuX-O08xU=.36bed675-8cf4-4bd1-8cf3-940d8610e17b@github.com>
 <6HMOpiB6bxmDjgC0im8kF5M4-u89MyZO699aGcWWKTs=.8ce7529f-3640-472a-a8b6-5f92a2ea8853@github.com>
 <hHQiJCTvIbYB5UOxsVs69duypl5XjU4snJKgHCDnd6Q=.9bafcdd4-4d77-4e08-ac77-65239836e501@github.com>
Message-ID: <UDjyAI9rTMRZK7tzNyONyYY3FowyiIa37Y2ZUrZ0Zi4=.8a8b4ba9-c115-4b4d-9131-176809e0fa4b@github.com>

On Fri, 27 Jan 2023 10:16:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 95:
>> 
>>> 93:         }
>>> 94:         if (Platform.isPPC()) {
>>> 95:             COMPILATION_TIMEOUT = COMPILATION_TIMEOUT * 2;
>> 
>> I guess this won't compile. COMPILATION_TIMEOUT is final.
>
> Yes correct, it cannot be final any more.

Well it could be final if you would add `(Platform.isPPC() ? 2 : 1) * ...` to the initialization. But I'm indifferent.

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From amaembo at gmail.com  Fri Jan 27 10:46:32 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 27 Jan 2023 11:46:32 +0100
Subject: Math.clamp method?
In-Reply-To: <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
 <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
Message-ID: <CAE+3fjZxoJFy=SyiT_uUA3HmzuMcj7yRu8C3u58WM_ALHr=ghg@mail.gmail.com>

Hello, all!

Thank you for an interesting discussion. As I see some interest
towards this feature, I've created a new issue to track this:
https://bugs.openjdk.org/browse/JDK-8301226
I haven't found an exact duplicate, only an issue with related
discussion JDK-4466549. Feel free to link duplicates if you can search
JIRA better than me :-)

On Thu, Jan 26, 2023 at 12:47 AM John Rose <john.r.rose at oracle.com> wrote:
>
> Dealing with numeric ranges is error-prone, so I welcome these.
>
> Another operation on ranges is membership. This is easy to derive
> from the clamp methods, I think:
>
>    checkRange(x,min,max) := clamp(x,min,max) == x

checkRange relates somehow to the methods we have in
java.util.Objects, namely checkFromIndexSize, checkIndex, etc. Though
these methods are throwing an exception, rather than returning false.
This could be considered as a separate enhancement.

> But I think there is no harm and real benefit from widening
> the value parameters, so value is always either long or double.
> That will save casts (which also cause bugs) for some use
> cases, such as doing 32x32-to-64-bit arithmetic followed
> by overflow checks and/or saturation. That?s a common use
> case for clamping.
>
> public static int clamp(long value, int min, int max)
> public static long clamp(long value, long min, long max)
> public static double clamp(double value, double min, double max)
> public static float clamp(double value, float min, float max)

I really like the idea of int clamp(long value, int min, int max), as
this makes the method much more useful. On the other hand, I have
doubles about
float clamp(double value, float min, float max), as it could be called
accidentally and we will have accidental precision loss. E.g., imagine
the following code:

// bounds are declared as floats for some reason
// this usually doesn't matter, as these numbers are exact in float
and in double
float lower = 0.0f;
float upper = 10.0f;

double v = 1/3.;
System.out.println(v);
v = Math.clamp(v, lower, upper); // oops!
System.out.println(v);

Having float clamp(double, float, float), this method will be linked
here, resulting in accidental precision loss. The output is:
0.3333333333333333
0.3333333432674408

Given that float type is rarely used, I'd stick to the following signatures:
public static int clamp(long value, int min, int max)
public static long clamp(long value, long min, long max)
public static double clamp(double value, double min, double max)
public static float clamp(float value, float min, float max)

> I thought about cross-domain clamps, which preserve 64 bit
> precision and double range at the same time in different places:
>
> public static long clamp(long value, double min, double max)
> public static long clamp(double value, long min, long max)

This is even more dangerous, as simply calling
double value = ...
value = clamp(value, 0, 1); // not 0.0 and 1.0
you will get 0 instead of the original value that fits the range.
I imagine that many people will step on this. If these methods are desired,
it would be better to name them differently, to avoid overload ambiguity.
For now, I would avoid this.

> The subexpression max-min never overflows, when it
> is regarded as an unsigned number, and the ?>>>1?
> immediately converts that unsigned number into the
> correctly signed positive number. That?s the only
> way to avoid overflow for all inputs. The third
> idiom above (the ?smartest? of the three) will fail,
> for example, if you feed it negative values.
> For some uses that is OK, but for others it isn?t.
>
> public static int midpoint(int min, int max)
> public static long midpoint(long min, long max)
> public static double midpoint(double min, double max)
> public static float midpoint(float min, float max)

midpoint is another great idea, I like it! Could also be considered separately.

With best regards,
Tagir Valeev.

From amaembo at gmail.com  Fri Jan 27 10:49:22 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 27 Jan 2023 11:49:22 +0100
Subject: Math.clamp method?
In-Reply-To: <820061872.5079210.1674656113573.JavaMail.zimbra@u-pem.fr>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
 <820061872.5079210.1674656113573.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAE+3fjbbgUyp+Ji9GUwvcZppWQJAypyJ_2KdYeK4q9vKTzd4Yw@mail.gmail.com>

Hello, Remi!

> Given that the semantics of NaN is clearly defined for Math.max/min (if one of the values is NaN the result is NaN),
> I don't believe we need a special case here for NaN.
>
> The semantics should be, this is equivalent to execute
>   Math.max(min, Math.min(max, value))
>
> So clamp(double) can be implemented using minsd and maxsd on x64, which is already what the VM does.

I agree that for NaN value, it's reasonable to return NaN. However, I
think it's better to throw if min or max is NaN,
as we should check the invariant that min <= max. We can do this in a
single check:
if (!(min <= max)) throw new IllegalArgumentException(...);

With best regards,
Tagir Valeev.

From alanb at openjdk.org  Fri Jan 27 11:38:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jan 2023 11:38:18 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
Message-ID: <dy9odhTl79Br9FPBjn-ADWpElyB1ien6Uj7FKOmVjE8=.d881b4db-ff66-42ad-b1a0-efe3a2d7e502@github.com>

On Thu, 26 Jan 2023 06:46:16 GMT, Glavo <duke at openjdk.org> wrote:

> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
> 
> Their return values can be trusted, so many unnecessary array duplication can be eliminated.

What about Collections.synchronizedCollection and other methods that may wrap/delagete to collections from other modules?

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From alanb at openjdk.org  Fri Jan 27 11:47:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jan 2023 11:47:23 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
Message-ID: <gNERtT3QrIjv5C0LJtcukIxU_IQAlzVkDzQzDnpYylo=.5bba7616-71c6-4fd2-84f3-10e5426968ec@github.com>

On Thu, 26 Jan 2023 22:27:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
>> 
>> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
>> 
>> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

src/java.base/share/classes/java/lang/Module.java line 605:

> 603:      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that is allowed to
> 604:      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) define classes}
> 605:      * in package {@code p}. </p>

I wonder if this should be an apiNote rather method description. There is also the no-arg isOpen method and maybe we should add a note there too. What would you think about linking "deep reflection" to AccessibleObject.setAccesssible(boolean) ?

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 240:

> 238:      * of {@code targetClass}. Extreme caution should be taken when opening a package
> 239:      * to another module as such defined classes have the same full privilege
> 240:      * access as other members in the target module.

"define classes" instead of inject classes is good.

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From david at dev-core.org  Fri Jan 27 11:50:17 2023
From: david at dev-core.org (David Schumann)
Date: Fri, 27 Jan 2023 12:50:17 +0100
Subject: Is ReDos seen as bug/vulnerability?
Message-ID: <CAMrs=adMzWqak4vAn6e=u6u6ruGHLp21L9FqUR+RZf6_nQQ7qw@mail.gmail.com>

Hello,

during a PenTest we found a ReDos issue in the JRE which causes
Matcher.matches() to go into an endless loop. Is such an issue considered a
bug for the JDK team (aka should I file a bug report)? Or is such an issue
considered "by design"?

The issue appears in current JRE versions (tested with 17 and 21)

Best Regards,
David Schumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230127/4dad5ae7/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jan 27 11:53:19 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Jan 2023 11:53:19 +0000
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <CAJL5A3kr0CYKtedysNa=Zd9gwgx_2K+d=59cM-cmrHnSN_a-8A@mail.gmail.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
 <CAJL5A3kr0CYKtedysNa=Zd9gwgx_2K+d=59cM-cmrHnSN_a-8A@mail.gmail.com>
Message-ID: <2ad63588-c105-1c5f-eb84-81cecc68a17d@oracle.com>

On 27/01/2023 05:42, Glavo wrote:
> I analyzed the usage of toLowerCase and toUpperCase in OpenJDK more 
> carefully,
> ?and found that none of the use cases really expected locale-sensitive 
> behavior

I expected that as there were a number of passes over these use-sites 
over the years. That said, if some of the remaining usages can be 
changed to specify the locale then it would avoid others puzzling over 
them too. Changing them probably needs careful review so changing them 
in specific areas or in smaller batches would make it easier for 
potential Reviewers.

In any case, I agree with R?mi that changing the existing methods is too 
subtle and maybe it's time to look at no-arg replacements.

-Alan

From duke at openjdk.org  Fri Jan 27 12:18:17 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 12:18:17 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <dy9odhTl79Br9FPBjn-ADWpElyB1ien6Uj7FKOmVjE8=.d881b4db-ff66-42ad-b1a0-efe3a2d7e502@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <dy9odhTl79Br9FPBjn-ADWpElyB1ien6Uj7FKOmVjE8=.d881b4db-ff66-42ad-b1a0-efe3a2d7e502@github.com>
Message-ID: <qJWNWQmJEowxgqiofY0ebhjTruZ2K7bO_DP-q-O75ik=.f97bc52d-e761-4c02-b298-dce26f35cc5b@github.com>

On Fri, 27 Jan 2023 11:35:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What about Collections.synchronizedCollection and other methods that may wrap/delagete to collections from other modules?

Good question, I missed this point. I think I should provide a helper method to check whether the collection is trusted.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From raffaello.giulietti at oracle.com  Fri Jan 27 12:55:54 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 12:55:54 +0000
Subject: Is ReDos seen as bug/vulnerability?
In-Reply-To: <CAMrs=adMzWqak4vAn6e=u6u6ruGHLp21L9FqUR+RZf6_nQQ7qw@mail.gmail.com>
References: <CAMrs=adMzWqak4vAn6e=u6u6ruGHLp21L9FqUR+RZf6_nQQ7qw@mail.gmail.com>
Message-ID: <BY5PR10MB4002E10AFF1BA08D7B3CC89B87CC9@BY5PR10MB4002.namprd10.prod.outlook.com>

Please file a bug report with the relevant (and disclosable) details.


From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Schumann <david at dev-core.org>
Date: Friday, 27 January 2023 at 12:50
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Is ReDos seen as bug/vulnerability?
Hello,

during a PenTest we found a ReDos issue in the JRE which causes Matcher.matches() to go into an endless loop. Is such an issue considered a bug for the JDK team (aka should I file a bug report)? Or is such an issue considered "by design"?

The issue appears in current JRE versions (tested with 17 and 21)

Best Regards,
David Schumann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230127/699a3956/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jan 27 13:03:45 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Jan 2023 13:03:45 +0000
Subject: Is ReDos seen as bug/vulnerability?
In-Reply-To: <CAMrs=adMzWqak4vAn6e=u6u6ruGHLp21L9FqUR+RZf6_nQQ7qw@mail.gmail.com>
References: <CAMrs=adMzWqak4vAn6e=u6u6ruGHLp21L9FqUR+RZf6_nQQ7qw@mail.gmail.com>
Message-ID: <e98ec8f6-63a3-c758-9125-298d5d46e6e5@oracle.com>

On 27/01/2023 11:50, David Schumann wrote:
> Hello,
>
> during a PenTest we found a ReDos issue in the JRE which causes 
> Matcher.matches() to go into an endless loop. Is such an issue 
> considered a bug for the JDK team (aka should I file a bug report)? Or 
> is such an issue considered "by design"?
>
> The issue appears in current JRE versions (tested with 17 and 21)
>

We can't discuss such matters here. If you think there is a security 
issue then please report it to OpenJDK vulnerability group [1].

-Alan.

[1] https://openjdk.org/groups/vulnerability/report

From naoto at openjdk.org  Fri Jan 27 13:32:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Jan 2023 13:32:21 GMT
Subject: [jdk20] RFR: 8301206: Fix issue with LocaleData after JDK-8300719
 [v2]
In-Reply-To: <UV2mu--XN_MBLhb6PWrE0i11q7b-d1UQFjIfARpSDks=.97ad5706-324d-45b6-a57c-2ee959f7d726@github.com>
References: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
 <UV2mu--XN_MBLhb6PWrE0i11q7b-d1UQFjIfARpSDks=.97ad5706-324d-45b6-a57c-2ee959f7d726@github.com>
Message-ID: <p7bGapE6fN-zVVWI3fBBRE8Vk0dfi7CW5sc7HcjXSUk=.97c735b0-428e-464d-8e9f-e47d53c6e85f@github.com>

On Fri, 27 Jan 2023 02:34:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Localization update didn't include an update to LocaleData file. This PR addresses this by updating the file with the newly translated values. The LocaleDataTest now passes. This should address the recent related failures to LocaleData.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bugid. Update year

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/118

From duke at openjdk.org  Fri Jan 27 13:42:17 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Fri, 27 Jan 2023 13:42:17 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <qJWNWQmJEowxgqiofY0ebhjTruZ2K7bO_DP-q-O75ik=.f97bc52d-e761-4c02-b298-dce26f35cc5b@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <dy9odhTl79Br9FPBjn-ADWpElyB1ien6Uj7FKOmVjE8=.d881b4db-ff66-42ad-b1a0-efe3a2d7e502@github.com>
 <qJWNWQmJEowxgqiofY0ebhjTruZ2K7bO_DP-q-O75ik=.f97bc52d-e761-4c02-b298-dce26f35cc5b@github.com>
Message-ID: <1BLS_YQr5-Odco6LdZjeW7u2DmjKCH3M7cYArMvJ2zI=.526c1293-cc3b-4e1d-836c-3da91606e6ae@github.com>

On Fri, 27 Jan 2023 12:15:34 GMT, Glavo <duke at openjdk.org> wrote:

> > What about Collections.synchronizedCollection and other methods that may wrap/delagete to collections from other modules?
> 
> Good question, I missed this point. I think I should provide a helper method to check whether the collection is trusted.

Maybe you can add an internal annotation and annotate all trusted collection classes with it.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From rgiulietti at openjdk.org  Fri Jan 27 13:50:23 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 13:50:23 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java
In-Reply-To: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
Message-ID: <UqptepsN4B526a1y0geZisGC3ls1Lcnhk0EklZrYMbM=.7a8fd221-feef-41eb-8375-c0e0d35c9388@github.com>

On Fri, 27 Jan 2023 06:52:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Restarting the port of FDLIBM to Java with the log10 method.
> 
> There are two port, the first a near-transliteration from C port to use as a test reference in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> and a more idiomatic Java port in 
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

src/java.base/share/classes/java/lang/FdLibm.java line 820:

> 818:             hx = (hx & 0x000f_ffff) | ((0x3ff - i) << 20);
> 819:             y  = (double)(k + i);
> 820:             x = __HI(x, hx);

`            x = __HI(x, hx);  // replace high word of x with hx`

-------------

PR: https://git.openjdk.org/jdk/pull/12242

From asotona at openjdk.org  Fri Jan 27 13:50:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 27 Jan 2023 13:50:22 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v10]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <w0mBUib_daL2PLjtfVU02ZbvxcOoTkiFeqPsSTPb-Og=.e94a0d45-d39c-4e77-8f9e-3964518cfd40@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  update of Java version constants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/931ca1c5..806b9025

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=08-09

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From rgiulietti at openjdk.org  Fri Jan 27 13:50:25 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 13:50:25 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java
In-Reply-To: <UqptepsN4B526a1y0geZisGC3ls1Lcnhk0EklZrYMbM=.7a8fd221-feef-41eb-8375-c0e0d35c9388@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
 <UqptepsN4B526a1y0geZisGC3ls1Lcnhk0EklZrYMbM=.7a8fd221-feef-41eb-8375-c0e0d35c9388@github.com>
Message-ID: <y_JpUNvf6u2HTrgsKsEsQteI6S1VISXzNGf9TnXYvQE=.5e87fde7-3e98-4335-8198-cc8dcac7f087@github.com>

On Fri, 27 Jan 2023 13:45:18 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Restarting the port of FDLIBM to Java with the log10 method.
>> 
>> There are two port, the first a near-transliteration from C port to use as a test reference in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> and a more idiomatic Java port in 
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 820:
> 
>> 818:             hx = (hx & 0x000f_ffff) | ((0x3ff - i) << 20);
>> 819:             y  = (double)(k + i);
>> 820:             x = __HI(x, hx);
> 
> `            x = __HI(x, hx);  // replace high word of x with hx`

Otherwise LGTM

-------------

PR: https://git.openjdk.org/jdk/pull/12242

From duke at openjdk.org  Fri Jan 27 13:53:45 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 13:53:45 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
Message-ID: <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>

> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
> 
> Their return values can be trusted, so many unnecessary array duplication can be eliminated.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Collections.isTrustedCollection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12212/files
  - new: https://git.openjdk.org/jdk/pull/12212/files/e0966d49..aecd79ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12212&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12212&range=00-01

  Stats: 51 lines in 8 files changed: 36 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12212.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12212/head:pull/12212

PR: https://git.openjdk.org/jdk/pull/12212

From alanb at openjdk.org  Fri Jan 27 14:31:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jan 2023 14:31:17 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
Message-ID: <Vt5eAwbiyF1jV60XBQ26DgpOxTJF5KkEX8w1dOot3IY=.72e92018-ff98-4d51-8086-1adcba282196@github.com>

On Fri, 27 Jan 2023 13:53:45 GMT, Glavo <duke at openjdk.org> wrote:

>> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
>> 
>> Their return values can be trusted, so many unnecessary array duplication can be eliminated.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collections.isTrustedCollection

I skimmed through the latest update. I see you've considered the possibility of a Matryoshka doll showing up but the optimization is still very very scary. I think it would require an audit of every API in java.base that potentially wraps a collection. It might be better to focus on a few specific cases that can be proven to be safe.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From asotona at openjdk.org  Fri Jan 27 14:54:35 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 27 Jan 2023 14:54:35 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v11]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <_11DUiHCBMysGNiXNNcBsd-iDN_CfvQk-IBKLPiGlvU=.1dac981f-99c8-46f3-ad78-ffe50217eb6c@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 106 commits:

 - Merge branch 'master' into JDK-8294982
 - update of Java version constants
 - unification of sealed class modifiers order
 - merged JAVAC_FLAGS and EXCLUDES in Java.gmk
 - removal of Preview.java and TransPatterns.java patch
   and enabled preview for java.base
 - jdk.compiler ClassWriter patch to avoid writing PREVIEW_MINOR_VERSION to classes participating in preview
 - Merge branch 'master' into JDK-8294982
 - Merge branch 'master' into JDK-8294982
 - javadoc cleanup
 - removal of AccessController::doPriviledged from ClassHierarchyResolver
 - ... and 96 more: https://git.openjdk.org/jdk/compare/e4252bb9...80213e61

-------------

Changes: https://git.openjdk.org/jdk/pull/10982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=10
  Stats: 53409 lines in 323 files changed: 53405 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From jjg at openjdk.org  Fri Jan 27 15:09:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 27 Jan 2023 15:09:22 GMT
Subject: [jdk20] RFR: 8300953: ClassDesc::ofInternalName missing @since tag
In-Reply-To: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
References: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
Message-ID: <jacYjgqKX2rwQZEZh_N_Xgrq2owX32bhM_NGIb-QZIg=.15a73e36-cccb-4eee-89e6-d42c3af423c5@github.com>

On Tue, 24 Jan 2023 13:35:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassDesc::ofInternalName was added in JDK 20, however @since tag is missing. 
> This patch fixes the javadoc. 
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/115

From asotona at openjdk.org  Fri Jan 27 15:13:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 27 Jan 2023 15:13:25 GMT
Subject: [jdk20] Integrated: 8300953: ClassDesc::ofInternalName missing @since
 tag
In-Reply-To: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
References: <Urx4LYxNWaiBzJHJ3-dtuS6MLItPbT_PonXWpB0eTFQ=.14577e28-81c9-4797-aecc-78b3102acca8@github.com>
Message-ID: <ryv0laDU6uH5Ta77-Yu1Z20zlSk4PQnTq3xSAr-bzbo=.f5c9b961-6822-40c1-9e09-75d8d7308e44@github.com>

On Tue, 24 Jan 2023 13:35:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassDesc::ofInternalName was added in JDK 20, however @since tag is missing. 
> This patch fixes the javadoc. 
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: b22e5216
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/b22e5216c4ead4621f137086db6f5b6a0c3982c7
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8300953: ClassDesc::ofInternalName missing @since tag

Reviewed-by: darcy, mchung, jjg

-------------

PR: https://git.openjdk.org/jdk20/pull/115

From rgiulietti at openjdk.org  Fri Jan 27 16:10:23 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 16:10:23 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter
Message-ID: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>

Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

-------------

Commit messages:
 - 8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Changes: https://git.openjdk.org/jdk/pull/12259/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300869
  Stats: 720 lines in 4 files changed: 319 ins; 372 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Fri Jan 27 16:18:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 16:18:17 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <s0mMi94Lg679mfyzEHikkWzYtstbxdCJ3UJarwHZTwU=.50102d54-09b3-41fd-b8e5-9f4c3413d390@github.com>

On Fri, 27 Jan 2023 16:02:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

The specification in `Formatter` explicitly refers to the outcome of `Double.toString(double)`. However, it currently uses another implementation for the floating-point to decimal conversion, which might end up in rare, slightly different outcomes than the ones described in the specification.

This fixes the discrepancy between specification and implementation in `Formatter`.

Class `jdk.internal.math.FormattedFPDecimal` replaces `jdk.internal.math.FormattedFloatingDecimal`, which is no longer needed.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From smarks at openjdk.org  Fri Jan 27 16:58:20 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 27 Jan 2023 16:58:20 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
 <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
Message-ID: <6T9yca1AQmq-rhE49OsKlU7zaFUjZvoiUeFZW9eK9mM=.c9ba4eca-4ea1-4d97-a335-f8991149b727@github.com>

On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> number of minor cleanups could be done in Arrays and Collections utility classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
>> 
>> In Collections:
>> - A few obsolete "unchecked" and "rawtypes" suppressions
>> - Unnecessary local variable initializer in get() method
>> - Raw type can be avoided in a number of casts
>> - Explicit type parameters could be omitted or converted to diamonds
>> - A couple of javadoc links on private APIs are malformed
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert cast removal

Test run looks good, ok to integrate.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12207

From mchung at openjdk.org  Fri Jan 27 17:10:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 17:10:22 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <gNERtT3QrIjv5C0LJtcukIxU_IQAlzVkDzQzDnpYylo=.5bba7616-71c6-4fd2-84f3-10e5426968ec@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
 <gNERtT3QrIjv5C0LJtcukIxU_IQAlzVkDzQzDnpYylo=.5bba7616-71c6-4fd2-84f3-10e5426968ec@github.com>
Message-ID: <qz-dtx2_st5g-ADHzoAaKlEeawAckH0_hklMzNI76XI=.68795776-e642-4d0b-a8f9-fa218e0a2208@github.com>

On Fri, 27 Jan 2023 11:44:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if this should be an apiNote rather method description. 

I considered this and no clear cut on this.  I don't have a strong opinion on this.   What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From mchung at openjdk.org  Fri Jan 27 17:17:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 17:17:28 GMT
Subject: Integrated: 8300924: Method::invoke throws wrong exception type when
 passing wrong number of arguments to method with 4 or more parameters
In-Reply-To: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
References: <A3YS-KTpE4m0k9_cfTP-a7hEqwqmMgV5jLsqpkhzjqs=.b3315c7d-504a-46b6-ba7a-582fa99111d9@github.com>
Message-ID: <Y9wD2DFTTlMiAAEnY5CCeBwG3lpIy1rPqRgFn6GPd0s=.6e4b07e7-345f-441a-bb07-debab9344d1d@github.com>

On Tue, 24 Jan 2023 18:19:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A simple fix in core reflection to check if the number of actual and formal parameters differ before invoking the method or the constructor regardless of whether it's a specialized case or not.

This pull request has now been integrated.

Changeset: 7aaf76c5
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7aaf76c5290a1688f9450a357aaae964615c29d0
Stats:     85 lines in 3 files changed: 67 ins; 10 del; 8 mod

8300924: Method::invoke throws wrong exception type when passing wrong number of arguments to method with 4 or more parameters

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12170

From naoto.sato at oracle.com  Fri Jan 27 17:24:38 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Jan 2023 09:24:38 -0800
Subject: [Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT
 by default
In-Reply-To: <2ad63588-c105-1c5f-eb84-81cecc68a17d@oracle.com>
References: <CAJL5A3mOd936NY0Ge_=qwjEU6unTFhSeFk_od_qeUHPrbu8xng@mail.gmail.com>
 <690688460.5825172.1674740076696.JavaMail.zimbra@u-pem.fr>
 <CAJL5A3kr0CYKtedysNa=Zd9gwgx_2K+d=59cM-cmrHnSN_a-8A@mail.gmail.com>
 <2ad63588-c105-1c5f-eb84-81cecc68a17d@oracle.com>
Message-ID: <0d301704-c71a-595e-f075-03e15fb5ca90@oracle.com>

+1

Unfortunately, it would be too disruptive to change the decades old 
behavior.

Naoto

On 1/27/23 3:53 AM, Alan Bateman wrote:
> On 27/01/2023 05:42, Glavo wrote:
>> I analyzed the usage of toLowerCase and toUpperCase in OpenJDK more 
>> carefully,
>> ?and found that none of the use cases really expected locale-sensitive 
>> behavior
> 
> I expected that as there were a number of passes over these use-sites 
> over the years. That said, if some of the remaining usages can be 
> changed to specify the locale then it would avoid others puzzling over 
> them too. Changing them probably needs careful review so changing them 
> in specific areas or in smaller batches would make it easier for 
> potential Reviewers.
> 
> In any case, I agree with R?mi that changing the existing methods is too 
> subtle and maybe it's time to look at no-arg replacements.
> 
> -Alan

From dnguyen at openjdk.org  Fri Jan 27 17:25:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Jan 2023 17:25:25 GMT
Subject: [jdk20] Integrated: 8301206: Fix issue with LocaleData after
 JDK-8300719
In-Reply-To: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
References: <ykaxESNIeYilvpUUvRNgFsjCWoFCpdCOrLlw0j4tMlc=.cecfc964-ce88-43b6-9c97-ab8339ee7e75@github.com>
Message-ID: <06LTdXFKqGB_hvVkZ4zUC0DsiY_WPwLuTt9d6Yqu6-k=.26533a47-ed2a-4e61-b749-0efbaab0010b@github.com>

On Fri, 27 Jan 2023 01:43:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Localization update didn't include an update to LocaleData file. This PR addresses this by updating the file with the newly translated values. The LocaleDataTest now passes. This should address the recent related failures to LocaleData.

This pull request has now been integrated.

Changeset: e5860ef6
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/e5860ef60a9353508afb09716158baf8bfb35559
Stats:     54 lines in 2 files changed: 1 ins; 0 del; 53 mod

8301206: Fix issue with LocaleData after JDK-8300719

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk20/pull/118

From lancea at openjdk.org  Fri Jan 27 17:40:19 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Jan 2023 17:40:19 GMT
Subject: RFR: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs [v8]
In-Reply-To: <hwuMkMb5Pba4Ju_TTUi9_EarFro2rBbfTfDCZ5w-vjA=.0af4f14b-a393-4f68-9a99-c3dea0180b36@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
 <hwuMkMb5Pba4Ju_TTUi9_EarFro2rBbfTfDCZ5w-vjA=.0af4f14b-a393-4f68-9a99-c3dea0180b36@github.com>
Message-ID: <7cn12dO4qpVd6nFJZ5ESzZUCux4lNRf7kpRELE2lFxc=.0b00adc3-d131-411c-a889-2f3b4952c02b@github.com>

On Wed, 25 Jan 2023 20:21:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
>> 
>> _TimeZone.getTimeZone(String ID)
>> TimeZone.setID(String ID)
>> TimeZone.inDaylightTime(Date date)_
>> 
>> For example, 
>> 
>> 
>> String someID = null;
>> TimeZone tz1 = TimeZone.getTimeZone(someID);
>> ``` 
>> 
>> throws a `NullPointerException`
>> 
>> 
>> This PR adds the missing  _ at throws:_ for the mentioned methods. The wording and specification is also adjusted for the overridable methods in TZ to use "_may throw_" over "_will throw_" because of the possibility of external sub-classes that may override the method.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   STZ.inDT can also be overriden

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From mchung at openjdk.org  Fri Jan 27 17:41:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 17:41:43 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v3]
In-Reply-To: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
Message-ID: <G1rlfRnTMmOijH5d71YLhtRK-m7VeF3iA-3nJtPlxMk=.f2acc041-7c82-4a11-9d1f-e11f30e7876e@github.com>

> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
> 
> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
> 
> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review feedback and add @apiNote

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12236/files
  - new: https://git.openjdk.org/jdk/pull/12236/files/4d3e879c..487baca5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=01-02

  Stats: 17 lines in 2 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12236.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12236/head:pull/12236

PR: https://git.openjdk.org/jdk/pull/12236

From mchung at openjdk.org  Fri Jan 27 17:41:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 17:41:45 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v2]
In-Reply-To: <qz-dtx2_st5g-ADHzoAaKlEeawAckH0_hklMzNI76XI=.68795776-e642-4d0b-a8f9-fa218e0a2208@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <2xw6l7Fo1ru4jcsyJ1sPNujxGSU_PLDVd3Oh0zIHpc0=.0822b7f5-1628-4916-9dfe-ddf660f72401@github.com>
 <gNERtT3QrIjv5C0LJtcukIxU_IQAlzVkDzQzDnpYylo=.5bba7616-71c6-4fd2-84f3-10e5426968ec@github.com>
 <qz-dtx2_st5g-ADHzoAaKlEeawAckH0_hklMzNI76XI=.68795776-e642-4d0b-a8f9-fa218e0a2208@github.com>
Message-ID: <FYJblbyoiXCTO0VPPR2rNRT3GoaQhjx7wl9K6u_qBDE=.94f0281c-534d-48ad-afdf-5d4ef2e59926@github.com>

On Fri, 27 Jan 2023 17:07:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 605:
>> 
>>> 603:      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that is allowed to
>>> 604:      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) define classes}
>>> 605:      * in package {@code p}. </p>
>> 
>> I wonder if this should be an apiNote rather method description. There is also the no-arg isOpen method and maybe we should add a note there too. What would you think about linking "deep reflection" to AccessibleObject.setAccesssible(boolean) ?
>
>> I wonder if this should be an apiNote rather method description. 
> 
> I considered this and no clear cut on this.  I don't have a strong opinion on this.   What do you think?

I updated with apiNote, which is clearer.

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From alanb at openjdk.org  Fri Jan 27 17:50:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jan 2023 17:50:23 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v3]
In-Reply-To: <G1rlfRnTMmOijH5d71YLhtRK-m7VeF3iA-3nJtPlxMk=.f2acc041-7c82-4a11-9d1f-e11f30e7876e@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <G1rlfRnTMmOijH5d71YLhtRK-m7VeF3iA-3nJtPlxMk=.f2acc041-7c82-4a11-9d1f-e11f30e7876e@github.com>
Message-ID: <CvJOUguEjpyqApw53eEUpkhKx4NgqrGbQS_J6L-A8WQ=.0630efc5-2df1-4555-9847-5d500c41e164@github.com>

On Fri, 27 Jan 2023 17:41:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
>> 
>> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
>> 
>> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and add @apiNote

The update looks good.

src/java.base/share/classes/java/lang/Module.java line 606:

> 604:      * {@link java.lang.invoke.MethodHandles.Lookup Lookup} object that is allowed to
> 605:      * {@link java.lang.invoke.MethodHandles.Lookup#defineClass(byte[]) define classes}
> 606:      * in package {@code p}.

A small suggestion here is to change "means that code in M" to "allows code in M".

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12236

From darcy at openjdk.org  Fri Jan 27 17:53:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 17:53:40 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java [v2]
In-Reply-To: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
Message-ID: <iIg3nd6JAdxCfbEWqoYPpJuTjE-WgTNFqVlUkKMYSvI=.27627b3b-b3f3-4eaf-99b9-78b1f4ad87a6@github.com>

> Restarting the port of FDLIBM to Java with the log10 method.
> 
> There are two port, the first a near-transliteration from C port to use as a test reference in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> and a more idiomatic Java port in 
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12242/files
  - new: https://git.openjdk.org/jdk/pull/12242/files/17cf431a..0f74dd5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12242&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12242&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12242.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12242/head:pull/12242

PR: https://git.openjdk.org/jdk/pull/12242

From darcy at openjdk.org  Fri Jan 27 17:53:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 17:53:44 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java [v2]
In-Reply-To: <y_JpUNvf6u2HTrgsKsEsQteI6S1VISXzNGf9TnXYvQE=.5e87fde7-3e98-4335-8198-cc8dcac7f087@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
 <UqptepsN4B526a1y0geZisGC3ls1Lcnhk0EklZrYMbM=.7a8fd221-feef-41eb-8375-c0e0d35c9388@github.com>
 <y_JpUNvf6u2HTrgsKsEsQteI6S1VISXzNGf9TnXYvQE=.5e87fde7-3e98-4335-8198-cc8dcac7f087@github.com>
Message-ID: <wLX21RkIoqhyyhPheGY7md4YgUosxbt8cH2kUnib1tg=.b1067cc7-583d-432d-a7c0-41164f766e9e@github.com>

On Fri, 27 Jan 2023 13:47:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 820:
>> 
>>> 818:             hx = (hx & 0x000f_ffff) | ((0x3ff - i) << 20);
>>> 819:             y  = (double)(k + i);
>>> 820:             x = __HI(x, hx);
>> 
>> `            x = __HI(x, hx);  // replace high word of x with hx`
>
> Otherwise LGTM

Okay; comment added back.

-------------

PR: https://git.openjdk.org/jdk/pull/12242

From jlu at openjdk.org  Fri Jan 27 18:14:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Jan 2023 18:14:25 GMT
Subject: Integrated: 8177418: NPE is not apparent for methods in
 java.util.TimeZone API docs
In-Reply-To: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
References: <e0D-hkr_2PlKrayyCTXFKx8H8IwYR4bjrhUM6pxjl9Y=.f7d9a063-f92c-4346-abec-37b9d37c9db8@github.com>
Message-ID: <RmocSAvsR0B_Tz8rK4oncf_KsSSEReiPEjuKApSfsX4=.2ee0a8ff-4845-4cdc-bc6f-3a5e3dcf9f10@github.com>

On Fri, 6 Jan 2023 22:38:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> When their input is null, the following methods in java.util.TimeZone throw a NullPointerException:
> 
> _TimeZone.getTimeZone(String ID)
> TimeZone.setID(String ID)
> TimeZone.inDaylightTime(Date date)_
> 
> For example, 
> 
> 
> String someID = null;
> TimeZone tz1 = TimeZone.getTimeZone(someID);
> ``` 
> 
> throws a `NullPointerException`
> 
> 
> This PR adds the missing  _ at throws:_ for the mentioned methods. The wording and specification is also adjusted for the overridable methods in TZ to use "_may throw_" over "_will throw_" because of the possibility of external sub-classes that may override the method.

This pull request has now been integrated.

Changeset: 22c976a9
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22c976a9b042b2d56e849ec8f9ef1dd3d146ca78
Stats:     19 lines in 2 files changed: 16 ins; 0 del; 3 mod

8177418: NPE is not apparent for methods in java.util.TimeZone API docs

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/11888

From stsypanov at openjdk.org  Fri Jan 27 18:18:19 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 27 Jan 2023 18:18:19 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <Vt5eAwbiyF1jV60XBQ26DgpOxTJF5KkEX8w1dOot3IY=.72e92018-ff98-4d51-8086-1adcba282196@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <Vt5eAwbiyF1jV60XBQ26DgpOxTJF5KkEX8w1dOot3IY=.72e92018-ff98-4d51-8086-1adcba282196@github.com>
Message-ID: <20OgB1iOE3bzC3AU4rSiEoNZahBWBymyZ1WLXGVoPZE=.84d98d81-dd63-4c47-a8b0-58b5e592983d@github.com>

On Fri, 27 Jan 2023 14:28:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be better to focus on a few specific cases that can be proven to be safe

As of trusted collections from java.base we have
- ArrayList
- Arrays.asList()
- HashSet
- LinkedHashSet
- TreeSet
- EnumSet
- ArrayDeque
- COWArrayList
- ConcurrentLinkedDeque
- Key/Value/EntrySets of Maps

Wouldn't it be too expensive to check whether incoming Collection's class is one of the enlisted?

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From rgiulietti at openjdk.org  Fri Jan 27 18:19:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 18:19:58 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
  
  Added tests for known differences between current and new behavior.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/bcbbe1e9..d42fbd03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=00-01

  Stats: 188 lines in 20 files changed: 168 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From mchung at openjdk.org  Fri Jan 27 18:20:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 18:20:42 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v4]
In-Reply-To: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
Message-ID: <aS3Rxq-Nh-84VxHMGU4P2TKYYab2c_u60LEGvT_m9HI=.96a71c39-bc43-4676-b20e-182e8bb25a28@github.com>

> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
> 
> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
> 
> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  fine tune wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12236/files
  - new: https://git.openjdk.org/jdk/pull/12236/files/487baca5..403cff53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12236&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12236.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12236/head:pull/12236

PR: https://git.openjdk.org/jdk/pull/12236

From rgiulietti at openjdk.org  Fri Jan 27 18:25:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 18:25:17 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
Message-ID: <t4WQCB08tO23KKB4gaIJodJ6dskRy6tK3wWuW2iOxLM=.fb86ea17-343d-4296-a2c6-0aa7ab733df3@github.com>

On Fri, 27 Jan 2023 18:19:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>   
>   Added tests for known differences between current and new behavior.

Added tests for known differences.

Most of the modified files are generated automatically by a script that, somewhat questionably, renews the copyright year in some of the files for no apparent reason.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From darcy at openjdk.org  Fri Jan 27 18:26:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 18:26:20 GMT
Subject: RFR: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections [v2]
In-Reply-To: <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
 <pIHclUhpCT0sld-SqwCb5ucplw8j0Qp3YNZL4XK0Sq4=.c9fe8a49-3b42-4842-aa7b-62d85243ee67@github.com>
Message-ID: <KRzxENB0kkuVObEojxqutZelUZwocyQ07bfSHU_FYY8=.a02217a5-3f52-493a-9c3b-a3f24956a7a6@github.com>

On Wed, 25 Jan 2023 22:23:26 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> number of minor cleanups could be done in Arrays and Collections utility classes.
>> In Arrays:
>> - Redundant import jdk.internal.misc.Unsafe;
>> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
>> 
>> In Collections:
>> - A few obsolete "unchecked" and "rawtypes" suppressions
>> - Unnecessary local variable initializer in get() method
>> - Raw type can be avoided in a number of casts
>> - Explicit type parameters could be omitted or converted to diamonds
>> - A couple of javadoc links on private APIs are malformed
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert cast removal

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12207

From darcy at openjdk.org  Fri Jan 27 18:26:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 27 Jan 2023 18:26:20 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v4]
In-Reply-To: <aS3Rxq-Nh-84VxHMGU4P2TKYYab2c_u60LEGvT_m9HI=.96a71c39-bc43-4676-b20e-182e8bb25a28@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <aS3Rxq-Nh-84VxHMGU4P2TKYYab2c_u60LEGvT_m9HI=.96a71c39-bc43-4676-b20e-182e8bb25a28@github.com>
Message-ID: <WxG7Lem1J51-agGSJO3B0BKdNY7HMABYPfisL3Nm7Go=.384ccf6d-8200-4c65-bb77-0d7a26f2f923@github.com>

On Fri, 27 Jan 2023 18:20:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
>> 
>> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
>> 
>> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tune wording

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From psandoz at openjdk.org  Fri Jan 27 18:26:21 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Jan 2023 18:26:21 GMT
Subject: RFR: 8217920: Lookup.defineClass injects a class that can access
 private members of any class in its own module [v4]
In-Reply-To: <aS3Rxq-Nh-84VxHMGU4P2TKYYab2c_u60LEGvT_m9HI=.96a71c39-bc43-4676-b20e-182e8bb25a28@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
 <aS3Rxq-Nh-84VxHMGU4P2TKYYab2c_u60LEGvT_m9HI=.96a71c39-bc43-4676-b20e-182e8bb25a28@github.com>
Message-ID: <CO9WA0Aw6p2snfbQnE8ifdUhyUKjQkn1QlBXxK6M7vo=.31c0e92e-a7fd-4b89-99c1-8cbf31f65151@github.com>

On Fri, 27 Jan 2023 18:20:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
>> 
>> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
>> 
>> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tune wording

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From duke at openjdk.org  Fri Jan 27 18:31:50 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Fri, 27 Jan 2023 18:31:50 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons 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 13 additional commits since the last revision:

 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - Merge branch 'openjdk:master' into Base64-AVX2
 - Address review comment
 - Remove whitespace
 - Fix wrong register usage
 - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ad44dd9d...3e66f7be

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/98728555..3e66f7be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=04-05

  Stats: 18402 lines in 710 files changed: 4705 ins; 3233 del; 10464 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From mchung at openjdk.org  Fri Jan 27 18:34:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 27 Jan 2023 18:34:27 GMT
Subject: Integrated: 8217920: Lookup.defineClass injects a class that can
 access private members of any class in its own module
In-Reply-To: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
References: <ltFquFmpWRoo1o3AANUBlPL-PjAsvoMnZGFppNjgX_s=.d2b9512e-df7b-48d3-807d-072d119aa83b@github.com>
Message-ID: <uTPVAJDSWbwMH9-DgxE3Y-ntpO0PYOl64uNLfAHLc-w=.48292035-36fa-4b28-b853-41fda1fda23e@github.com>

On Thu, 26 Jan 2023 21:03:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Currently, a `Lookup` object with `PACKAGE` access can be used to inject a class in the runtime package of the Lookup's lookup class via `Lookup::defineClass`.   The classes that are injected have the same access as other members in the module and can access private members of all types in the module via reflection.
> 
> However, changing `Lookup.defineClass` to require full privilege access (`PRIVATE` + `MODULE`) is an incompatible change that would break existing frameworks which use `privateLookupIn` and `Lookup::defineClass` to inject auxiliary classes in a module.   A module authorizes the framework by opening a package for it to access and `Lookup::defineClass` was the supported replacement for `setAccessible` on `ClassLoader::defineClass` hack in JDK 9.    
> 
> This PR proposes to keep existing behavior and provide better documentation to help developers to beware of the permissions given out when opening a package to another module. A class injected in a module has the same privilege as other module members.

This pull request has now been integrated.

Changeset: 7f05d57a
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f05d57a87d8b41b53194aa0dacc4057cbb58544
Stats:     31 lines in 2 files changed: 30 ins; 0 del; 1 mod

8217920: Lookup.defineClass injects a class that can access private members of any class in its own module

Reviewed-by: psandoz, alanb, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12236

From duke at openjdk.org  Fri Jan 27 18:43:34 2023
From: duke at openjdk.org (duke)
Date: Fri, 27 Jan 2023 18:43:34 GMT
Subject: Withdrawn: 8296546: Add @spec tags to API
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <Bmh8EC1Xp-UN0iY-YE8mDhTuf06aJtr4orDONeB7J8U=.6380dac7-c81f-45be-aee5-4a5a3e6e2a5e@github.com>

On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From tvaleev at openjdk.org  Fri Jan 27 19:27:34 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 27 Jan 2023 19:27:34 GMT
Subject: Integrated: 8301120: Cleanup utility classes java.util.Arrays and
 java.util.Collections
In-Reply-To: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
References: <izKfMfHKBGd_GBqZ3i_oU6FvMNZJGgjf54UGXLIRx48=.efcc63ce-9e04-40d7-af21-08e9db53d65f@github.com>
Message-ID: <kha3RhlA7Ez9uepDvi0C3_JjLprmrrwzIw-DwoZWSJU=.c249cf84-e4d5-44d0-8413-b7b9c137c60d@github.com>

On Wed, 25 Jan 2023 21:41:37 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> number of minor cleanups could be done in Arrays and Collections utility classes.
> In Arrays:
> - Redundant import jdk.internal.misc.Unsafe;
> - C-style array declaration is used in public static boolean equals(short[] a, short a2[]) (that's the only place in the whole file)
> 
> In Collections:
> - A few obsolete "unchecked" and "rawtypes" suppressions
> - Unnecessary local variable initializer in get() method
> - Raw type can be avoided in a number of casts
> - Explicit type parameters could be omitted or converted to diamonds
> - A couple of javadoc links on private APIs are malformed

This pull request has now been integrated.

Changeset: ae0e76d3
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae0e76d3dd42de9e66196843e740e75b06894f1f
Stats:     28 lines in 2 files changed: 0 ins; 6 del; 22 mod

8301120: Cleanup utility classes java.util.Arrays and java.util.Collections

Reviewed-by: smarks, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12207

From rriggs at openjdk.org  Fri Jan 27 19:59:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 27 Jan 2023 19:59:19 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
Message-ID: <YMTVFyVOttqomRFpf_yid9J32t4DxkrROKpnK9vG8Ac=.c0a3fa92-3602-48c2-b329-a113a041ad32@github.com>

On Fri, 27 Jan 2023 18:19:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>   
>   Added tests for known differences between current and new behavior.

test/jdk/java/util/Formatter/BasicInt.java line 1:

> 1: /*

It looks line the non-float/double test classes are unchanged, they could be dropped from the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From duke at openjdk.org  Fri Jan 27 20:43:15 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 20:43:15 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <Vt5eAwbiyF1jV60XBQ26DgpOxTJF5KkEX8w1dOot3IY=.72e92018-ff98-4d51-8086-1adcba282196@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <Vt5eAwbiyF1jV60XBQ26DgpOxTJF5KkEX8w1dOot3IY=.72e92018-ff98-4d51-8086-1adcba282196@github.com>
Message-ID: <a_NS-pIN6lfbHRzwbdBa0I8_STWWdm94BXhJX4l74KE=.80c65319-bc57-4531-8d8a-3a4791fe9270@github.com>

On Fri, 27 Jan 2023 14:28:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through the latest update. I see you've considered the possibility of a Matryoshka doll showing up but the optimization is still very very scary. I think it would require an audit of every API in java.base that potentially wraps a collection. It might be better to focus on a few specific cases that can be proven to be safe.

It is good to limit the trusted collection to a set of known collections. I am thinking about the best way to implement it. I hope that the impact on performance will be as small as possible.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From forax at openjdk.org  Fri Jan 27 21:01:16 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 27 Jan 2023 21:01:16 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
Message-ID: <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>

On Fri, 27 Jan 2023 13:53:45 GMT, Glavo <duke at openjdk.org> wrote:

>> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
>> 
>> Their return values can be trusted, so many unnecessary array duplication can be eliminated.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collections.isTrustedCollection

I think the simplest solution is to have a non public interface declared inside java.util. Like java.util.RandomAccess, but non public.
The main advantage to use an interface is that you can document it and it's easy to find all the implementations.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Fri Jan 27 21:05:15 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 27 Jan 2023 21:05:15 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>
Message-ID: <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>

On Fri, 27 Jan 2023 20:58:40 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I think the simplest solution is to have a non public interface declared inside java.util. Like java.util.RandomAccess, but non public. The main advantage to use an interface is that you can document it and it's easy to find all the implementations.

I think this is feasible, but it should be placed in a sub-package in `jdk.internal`, because some trusted collections are outside `java.util`.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From jwilhelm at openjdk.org  Fri Jan 27 21:08:40 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 21:08:40 GMT
Subject: RFR: Merge jdk20
Message-ID: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8301206: Fix issue with LocaleData after JDK-8300719
 - 8300953: ClassDesc::ofInternalName missing @since tag
 - 8300719: JDK 20 RDP2 L10n resource files update

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.1

Changes: https://git.openjdk.org/jdk/pull/12267/files
  Stats: 1078 lines in 85 files changed: 220 ins; 114 del; 744 mod
  Patch: https://git.openjdk.org/jdk/pull/12267.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12267/head:pull/12267

PR: https://git.openjdk.org/jdk/pull/12267

From rgiulietti at openjdk.org  Fri Jan 27 21:30:18 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 21:30:18 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <YMTVFyVOttqomRFpf_yid9J32t4DxkrROKpnK9vG8Ac=.c0a3fa92-3602-48c2-b329-a113a041ad32@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
 <YMTVFyVOttqomRFpf_yid9J32t4DxkrROKpnK9vG8Ac=.c0a3fa92-3602-48c2-b329-a113a041ad32@github.com>
Message-ID: <_KVrr_BXbGV8pPxdRL3L4CHHR-0A8Y6KuSSDGEZSG_w=.b6a9b4b0-ebe8-4f74-80c0-dc9a42f73a22@github.com>

On Fri, 27 Jan 2023 19:56:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>>   
>>   Added tests for known differences between current and new behavior.
>
> test/jdk/java/util/Formatter/BasicInt.java line 1:
> 
>> 1: /*
> 
> It looks line the non-float/double test classes are unchanged, they could be dropped from the PR.

The only changes I made myself in the test files are in Basic-X.java.template (including the copyright year). The other files were generated by a script, which happens to also change the copyright year for otherwise unmodified files.

If you agree, I'll happily remove the trivial copyright year changes and only retain those files containing more substantial modifications.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From rriggs at openjdk.org  Fri Jan 27 22:13:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 27 Jan 2023 22:13:19 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <_KVrr_BXbGV8pPxdRL3L4CHHR-0A8Y6KuSSDGEZSG_w=.b6a9b4b0-ebe8-4f74-80c0-dc9a42f73a22@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
 <YMTVFyVOttqomRFpf_yid9J32t4DxkrROKpnK9vG8Ac=.c0a3fa92-3602-48c2-b329-a113a041ad32@github.com>
 <_KVrr_BXbGV8pPxdRL3L4CHHR-0A8Y6KuSSDGEZSG_w=.b6a9b4b0-ebe8-4f74-80c0-dc9a42f73a22@github.com>
Message-ID: <9Bv6duFlBn492Tk9zzMa3P3c6Lzm7rViBUJwaAzkUlc=.0db9a6d8-f2e7-47c1-8647-c3a7d5be3069@github.com>

On Fri, 27 Jan 2023 21:27:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicInt.java line 1:
>> 
>>> 1: /*
>> 
>> It looks line the non-float/double test classes are unchanged, they could be dropped from the PR.
>
> The only changes I made myself in the test files are in Basic-X.java.template (including the copyright year). The other files were generated by a script, which happens to also change the copyright year for otherwise unmodified files.
> 
> If you agree, I'll happily remove the trivial copyright year changes and only retain those files containing more substantial modifications.

Fine with me, I figured it was the script that changed the copyright and otherwise generated the same as before.  tnx

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From weijun at openjdk.org  Fri Jan 27 22:19:20 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jan 2023 22:19:20 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v15]
In-Reply-To: <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
Message-ID: <ZwmdMuuevgFXvFNkDDqIwLiz2AGyzLWaFVgnJSRE4Yw=.62291bc3-26a0-4329-bf38-0429b74b4c21@github.com>

On Tue, 24 Jan 2023 12:31:30 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
>> 
>> The mentioned call sites needs updates to check and ignore such files.
>> 
>> A new test IgnoreUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add whitespace after keywords if and for

Marked as reviewed by weijun (Reviewer).

Yes, you're right. `ZipFile:: isSignatureRelated ` collects them for verification but `SignatureFileVerifier:: isSigningRelated` is about do not re-sign them while signing.

Maybe we can rename `ZipFile::isSignatureRelated` to `ZipFile::isBlockOrSF` as well?

I'll approved this PR. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From redestad at openjdk.org  Fri Jan 27 22:24:23 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 27 Jan 2023 22:24:23 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6]
In-Reply-To: <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com>
Message-ID: <XXsryYpVQwgwFSW9J0Ii9PDOIZN15oTfDo0izJWTp0s=.0e0e4e97-1675-4315-9f99-686879de365b@github.com>

On Fri, 27 Jan 2023 18:31:50 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons 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 13 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into Base64-AVX2
>  - Merge branch 'openjdk:master' into Base64-AVX2
>  - Merge branch 'openjdk:master' into Base64-AVX2
>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>  - Merge branch 'openjdk:master' into Base64-AVX2
>  - Address review comment
>  - Remove whitespace
>  - Fix wrong register usage
>  - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/50dc1196...3e66f7be

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2159:

> 2157: }
> 2158: 
> 2159: address StubGenerator::base64_AVX2_tables_addr() {

A casual reader might wonder why there's 3 other avx2-tables and then this, so for readability it'd be nice to add "decode" to the name of this new table.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2643:

> 2641:     // Handle isURL / MIME?!?!  r12 is used for length calculation (from out)
> 2642:     //
> 2643:     // rbx is out, r12 is saved out, rdx is size, rsi is src

It seems that on windows `r12` is in use, see line 2323. GHA seem to be having some trouble finishing Windows testing on time - could there be some issue here?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2647:

> 2645:     ////////////////////////////////////////////
> 2646: 
> 2647:     // *************** NEEDS TO BE FIXED ************

While it's fine to leave implementation of `getMimeDecoder` and `getUrlDecoder` for a follow-up, I think these comments needs to be cleaned up. E.g. a follow-up RFE filed and referenced.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2651:

> 2649:     __ jcc(Assembler::notZero, L_tailProc);
> 2650: 
> 2651:     __ cmpl(length, 44);

Perform `length` checks first to avoid unnecessary branches on small inputs?

Ideal might be to move this length check up just before the `_cmpl(length, 128)` in the AVX-512 block, so that if `AVX=3` short inputs branch directly to the scalar tail procedure without jumping around. This might also apply to the encode stub, though that's pre-existing.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2673:

> 2671:     __ vmovdqu(xmm13, Address(r13, 0xc8));
> 2672:     __ vmovdqu(xmm12, Address(r13, 0x08));
> 2673:     __ jmp(L_enterLoop);

This got me curious (sorry!) and maybe there's something going on here that I'm not getting... But why have you split the loop apart and jump into the middle of it? It'd seem not doing this would be more straightforward, with no difference semantically and one less jump? (align32 should just translate to a narrow nop instruction, if anything)

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From redestad at openjdk.org  Fri Jan 27 22:24:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 27 Jan 2023 22:24:25 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6]
In-Reply-To: <XXsryYpVQwgwFSW9J0Ii9PDOIZN15oTfDo0izJWTp0s=.0e0e4e97-1675-4315-9f99-686879de365b@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com>
 <XXsryYpVQwgwFSW9J0Ii9PDOIZN15oTfDo0izJWTp0s=.0e0e4e97-1675-4315-9f99-686879de365b@github.com>
Message-ID: <Q_aMyA9tI-RBMk1Gz7wVtTXd3cjTttndi8n6kavhEqI=.edb8c478-432f-4537-8ac0-56f42c2d15c2@github.com>

On Fri, 27 Jan 2023 21:36:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons 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 13 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Address review comment
>>  - Remove whitespace
>>  - Fix wrong register usage
>>  - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
>>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/50dc1196...3e66f7be
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2643:
> 
>> 2641:     // Handle isURL / MIME?!?!  r12 is used for length calculation (from out)
>> 2642:     //
>> 2643:     // rbx is out, r12 is saved out, rdx is size, rsi is src
> 
> It seems that on windows `r12` is in use, see line 2323. GHA seem to be having some trouble finishing Windows testing on time - could there be some issue here?

Nevermind, you're not using r12 and GHA Windows testing is green now.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From rgiulietti at openjdk.org  Fri Jan 27 22:26:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 22:26:58 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v3]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <v-sWtqqK5wqLDtr3DXGGRB6SP8KzjLKX1awPPMT5Lqw=.c889fe69-7bab-4e63-827c-45eab67f1802@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
  
  Reverted back copyright year of otherwise untouched files.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/d42fbd03..6f026d45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=01-02

  Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Fri Jan 27 22:26:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Jan 2023 22:26:58 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <9Bv6duFlBn492Tk9zzMa3P3c6Lzm7rViBUJwaAzkUlc=.0db9a6d8-f2e7-47c1-8647-c3a7d5be3069@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
 <YMTVFyVOttqomRFpf_yid9J32t4DxkrROKpnK9vG8Ac=.c0a3fa92-3602-48c2-b329-a113a041ad32@github.com>
 <_KVrr_BXbGV8pPxdRL3L4CHHR-0A8Y6KuSSDGEZSG_w=.b6a9b4b0-ebe8-4f74-80c0-dc9a42f73a22@github.com>
 <9Bv6duFlBn492Tk9zzMa3P3c6Lzm7rViBUJwaAzkUlc=.0db9a6d8-f2e7-47c1-8647-c3a7d5be3069@github.com>
Message-ID: <LKN9rhbeSQf0zsgki8ZSuJvqEsydDxIfDshuElOl6X0=.b444da48-00f0-428f-b6bc-2425891ec2fe@github.com>

On Fri, 27 Jan 2023 22:10:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The only changes I made myself in the test files are in Basic-X.java.template (including the copyright year). The other files were generated by a script, which happens to also change the copyright year for otherwise unmodified files.
>> 
>> If you agree, I'll happily remove the trivial copyright year changes and only retain those files containing more substantial modifications.
>
> Fine with me, I figured it was the script that changed the copyright and otherwise generated the same as before.  tnx

Otherwise untouched files are now reverted back with previous copyright year

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From duke at openjdk.org  Fri Jan 27 22:45:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 27 Jan 2023 22:45:17 GMT
Subject: RFR: 8300140: ZipFile.isSignatureRelated returns true for files in
 META-INF subdirectories [v15]
In-Reply-To: <ZwmdMuuevgFXvFNkDDqIwLiz2AGyzLWaFVgnJSRE4Yw=.62291bc3-26a0-4329-bf38-0429b74b4c21@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
 <EOmRiv7PORp4s9HdYYs5cp8hNIA51minXiwj_7zKcHw=.e42c89d0-8d3c-4a8f-a9b5-adbd8d94a987@github.com>
 <ZwmdMuuevgFXvFNkDDqIwLiz2AGyzLWaFVgnJSRE4Yw=.62291bc3-26a0-4329-bf38-0429b74b4c21@github.com>
Message-ID: <nMJ_iKy0nq28YrwDteblcuSjPv4wPbIwR-4D5EHF0VU=.24024237-b230-442f-92a0-c7f31747996a@github.com>

On Fri, 27 Jan 2023 22:16:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Maybe we can rename `ZipFile::isSignatureRelated` to `ZipFile::isBlockOrSF` as well?

The term "signature related" seems to be used quite extensively around ZipFile and also in JavaUtilZipFileAccess. Semantics are very similar, but not exactly equal. Because of this, I'm a bit reluctant to rename it.

> I'll approved this PR. Thanks.

Thank for your help and guidance in reviewing this PR!

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From jwilhelm at openjdk.org  Fri Jan 27 22:49:26 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 27 Jan 2023 22:49:26 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
References: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com>
Message-ID: <JVZE_mPEwJ2rcS4QD7ftXAXrVcbj_TksRnNb7Nmdi-U=.44286872-ced9-458a-b59d-879b09876ecf@github.com>

On Fri, 27 Jan 2023 21:00:03 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 5c59de52
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c59de52a31da937663ad2cef055213489b0516e
Stats:     1078 lines in 85 files changed: 220 ins; 114 del; 744 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12267

From duke at openjdk.org  Fri Jan 27 22:51:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 27 Jan 2023 22:51:28 GMT
Subject: Integrated: 8300140: ZipFile.isSignatureRelated returns true for files
 in META-INF subdirectories
In-Reply-To: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
References: <-kpEPG5OnZ-DK5Iso8Uyf3hg8jF1ugiWkeVzyHLTLTY=.e11d2991-30b5-46e2-bd8e-9eb744c1915c@github.com>
Message-ID: <xwxug3OHsdwdJmnLco67FQMX0yHGB9nE_sNjnGBLvzw=.1b798d44-3ec3-4247-a474-a537a08e9222@github.com>

On Thu, 12 Jan 2023 18:44:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that files reside in META-INF directly, and not in a subdirectory of META-INF.
> 
> The mentioned call sites needs updates to check and ignore such files.
> 
> A new test IgnoreUnrelatedSignatureFiles is added which verifies that [*.SF, *.RSA] files in META-INF/ subdirectories are indeed ignored.

This pull request has now been integrated.

Changeset: 5dfc4ec7
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5dfc4ec7d94af9fe39fdee9d83b06101b827a3c6
Stats:     429 lines in 6 files changed: 405 ins; 8 del; 16 mod

8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/11976

From eirbjo at gmail.com  Fri Jan 27 23:23:25 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 00:23:25 +0100
Subject: Why does ZipFile.Source.readFullyAt read in chunks?
Message-ID: <CA+pBWhuFUcajEz0t6SUNtd0DiBqiJV1=BB0wOEjh9SDS24WbMA@mail.gmail.com>

Hi,

ZipFile.Source.readFullyAt caps its calls to RandomAccessFile.readFully to
a maximum of 8192 bytes per call, like this:

int N = len;
> while (N > 0) {
>     int n = Math.min(BUF_SIZE, N);
>     zfile.readFully(buf, off, n);
>     off += n;
>     N -= n;
> }


I'm observing a ~10% speedup of the ZipFileOpen micro when I replace the
above with simply:

zfile.seek(pos);
> zfile.readFully(buf, off, len);


Does anyone know why readFullyAt is implemented this way? Is it trying to
limit blocking time somehow? Is there some hidden buffering deeper down I'm
not seeing?

If this is safe to remove, I'm happy to submit a PR. But code like this is
usually there for a reason..?

Cheers,
Eiirk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/58649bc9/attachment.htm>

From duke at openjdk.org  Sat Jan 28 04:06:51 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 04:06:51 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for ASCII
 compatible charsets
Message-ID: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>

This is the javadoc of `JavaLangAccess::newStringNoRepl`:


    /**
     * Constructs a new {@code String} by decoding the specified subarray of
     * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
     *
     * The caller of this method shall relinquish and transfer the ownership of
     * the byte array to the callee since the later will not make a copy.
     *
     * @param bytes the byte array source
     * @param cs the Charset
     * @return the newly created string
     * @throws CharacterCodingException for malformed or unmappable bytes
     */


It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.

However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.

This PR fixes this problem.

-------------

Commit messages:
 - newStringNoRepl should avoid copying arrays for ASCII compatible charsets

Changes: https://git.openjdk.org/jdk/pull/12119/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299807
  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12119.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12119/head:pull/12119

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 04:06:51 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 04:06:51 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <rXLM1qVTfrRQR5CaTmSP1W8slMHPDCEGslLNQCduC0s=.59986f36-05f1-42c4-ad9c-80d1ecd8a50e@github.com>

On Fri, 20 Jan 2023 16:47:27 GMT, Glavo <duke at openjdk.org> wrote:

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

I ran the tier1 and tier2 tests, and there were no new errors.

The only use case affected is `Files.readString`. I tested the performance of `readString` based on the memory file system.

baseline:

Benchmark                   (length)   Mode  Cnt        Score       Error  Units
NoRepl.testReadAscii               0  thrpt    5  5049760.744 ?  3563.324  ops/s
NoRepl.testReadAscii            1024  thrpt    5  3523083.785 ? 23747.078  ops/s
NoRepl.testReadAscii            8192  thrpt    5  2415952.140 ? 85884.289  ops/s
NoRepl.testReadAscii         1048576  thrpt    5    32425.563 ?   284.121  ops/s
NoRepl.testReadAscii        33554432  thrpt    5      872.492 ?     4.311  ops/s
NoRepl.testReadAscii       268435456  thrpt    5       58.736 ?     0.224  ops/s
NoRepl.testReadAsciiAsGBK          0  thrpt    5  4229547.832 ? 10997.381  ops/s
NoRepl.testReadAsciiAsGBK       1024  thrpt    5  3409472.580 ?   819.566  ops/s
NoRepl.testReadAsciiAsGBK       8192  thrpt    5  2179865.886 ? 16606.862  ops/s
NoRepl.testReadAsciiAsGBK    1048576  thrpt    5    32962.429 ?   249.385  ops/s
NoRepl.testReadAsciiAsGBK   33554432  thrpt    5      871.810 ?     1.812  ops/s
NoRepl.testReadAsciiAsGBK  268435456  thrpt    5       59.131 ?     0.172  ops/s
NoRepl.testReadGBK                 0  thrpt    5  4657464.074 ? 51849.667  ops/s
NoRepl.testReadGBK              1024  thrpt    5  1199083.242 ?  8653.846  ops/s
NoRepl.testReadGBK              8192  thrpt    5    75823.949 ?    46.493  ops/s
NoRepl.testReadGBK           1048576  thrpt    5      675.214 ?     1.729  ops/s
NoRepl.testReadGBK          33554432  thrpt    5       20.972 ?     2.280  ops/s
NoRepl.testReadGBK         268435456  thrpt    5        2.585 ?     0.394  ops/s
NoRepl.testReadUTF8                0  thrpt    5  5222403.558 ? 44728.740  ops/s
NoRepl.testReadUTF8             1024  thrpt    5  1417472.161 ? 23776.534  ops/s
NoRepl.testReadUTF8             8192  thrpt    5   185714.265 ?  2096.328  ops/s
NoRepl.testReadUTF8          1048576  thrpt    5     1318.763 ?    16.051  ops/s
NoRepl.testReadUTF8         33554432  thrpt    5       30.663 ?     0.114  ops/s
NoRepl.testReadUTF8        268435456  thrpt    5        3.782 ?     0.041  ops/s


This PR:

Benchmark                   (length)   Mode  Cnt        Score       Error  Units
NoRepl.testReadAscii               0  thrpt    5  5084610.141 ? 37449.826  ops/s
NoRepl.testReadAscii            1024  thrpt    5  3425713.961 ? 24060.542  ops/s
NoRepl.testReadAscii            8192  thrpt    5  2765684.248 ? 20586.103  ops/s
NoRepl.testReadAscii         1048576  thrpt    5    48074.603 ?   371.213  ops/s
NoRepl.testReadAscii        33554432  thrpt    5     1167.878 ?    14.427  ops/s
NoRepl.testReadAscii       268435456  thrpt    5       71.028 ?     0.439  ops/s
NoRepl.testReadAsciiAsGBK          0  thrpt    5  4783174.805 ?  9789.109  ops/s
NoRepl.testReadAsciiAsGBK       1024  thrpt    5  3518265.840 ? 18467.577  ops/s
NoRepl.testReadAsciiAsGBK       8192  thrpt    5  2775108.822 ? 19282.776  ops/s
NoRepl.testReadAsciiAsGBK    1048576  thrpt    5    46956.963 ?   147.593  ops/s
NoRepl.testReadAsciiAsGBK   33554432  thrpt    5     1165.036 ?    10.032  ops/s
NoRepl.testReadAsciiAsGBK  268435456  thrpt    5       70.878 ?     0.191  ops/s
NoRepl.testReadGBK                 0  thrpt    5  4910043.054 ? 27295.344  ops/s
NoRepl.testReadGBK              1024  thrpt    5  1177675.970 ? 15573.239  ops/s
NoRepl.testReadGBK              8192  thrpt    5    75417.479 ?   233.957  ops/s
NoRepl.testReadGBK           1048576  thrpt    5      674.620 ?     5.856  ops/s
NoRepl.testReadGBK          33554432  thrpt    5       19.899 ?     1.504  ops/s
NoRepl.testReadGBK         268435456  thrpt    5        2.705 ?     0.002  ops/s
NoRepl.testReadUTF8                0  thrpt    5  4851516.950 ?  9237.743  ops/s
NoRepl.testReadUTF8             1024  thrpt    5  1332016.420 ?  9570.465  ops/s
NoRepl.testReadUTF8             8192  thrpt    5   184177.766 ?  4662.562  ops/s
NoRepl.testReadUTF8          1048576  thrpt    5     1326.439 ?     3.420  ops/s
NoRepl.testReadUTF8         33554432  thrpt    5       30.782 ?     0.116  ops/s
NoRepl.testReadUTF8        268435456  thrpt    5        3.790 ?     0.011  ops/s


When reading an ASCII file as UTF-8 or GBK encoding, we can see that the throughput of `readString` has improved significantly. When reading ASCII files with a size of 1MiB, the throughput increased by 40%~50%, but for larger or smaller files, the throughput improvement will be smaller. 

For files containing non-ASCII characters, the throughput of `readString` is between 94% and 104% of the baseline.

This is the source code of the benchmark: https://gist.github.com/Glavo/f3d2060d0bd13cd0ce2add70e6060ea0

Can someone help me open an Issue on Java Bug System?

The throughput of reading ASCII files as UTF-8:

![image](https://user-images.githubusercontent.com/20694662/213833461-97e60b8d-2845-48fb-9331-585810c182b2.png)


The throughput of reading ASCII files as GBK:

![image](https://user-images.githubusercontent.com/20694662/213833687-d2811afb-efce-4d4e-9074-a797f2eea83a.png)

> /issue JDK-8299807

Thank you!

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From rriggs at openjdk.org  Sat Jan 28 04:06:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 28 Jan 2023 04:06:51 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <gl_3o_8wlhZo8o0Nfm4ZyiSZh0sVDUtzc535A0UAjxc=.fdf72d45-06c2-4068-9a5c-108004f059ec@github.com>

On Fri, 20 Jan 2023 16:47:27 GMT, Glavo <duke at openjdk.org> wrote:

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

It seems odd that the benchmark seems slower for smaller files; can you suggest why that might be?
I'd expect the size distribution for Files.readString to be biased toward the smaller files.
Can you repeat the benchmark using the default file system.  OS file caching should eliminate the disk speed effects.

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 04:06:51 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 04:06:51 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets
In-Reply-To: <gl_3o_8wlhZo8o0Nfm4ZyiSZh0sVDUtzc535A0UAjxc=.fdf72d45-06c2-4068-9a5c-108004f059ec@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
 <gl_3o_8wlhZo8o0Nfm4ZyiSZh0sVDUtzc535A0UAjxc=.fdf72d45-06c2-4068-9a5c-108004f059ec@github.com>
Message-ID: <yjC9PFj4x4II4UzxDqf9OjmrO9PLCd67UZEJUXsiWxg=.1d636a59-ab10-44bb-b323-5aba016a0fa1@github.com>

On Fri, 27 Jan 2023 16:04:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>> 
>> 
>>     /**
>>      * Constructs a new {@code String} by decoding the specified subarray of
>>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>>      *
>>      * The caller of this method shall relinquish and transfer the ownership of
>>      * the byte array to the callee since the later will not make a copy.
>>      *
>>      * @param bytes the byte array source
>>      * @param cs the Charset
>>      * @return the newly created string
>>      * @throws CharacterCodingException for malformed or unmappable bytes
>>      */
>> 
>> 
>> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
>> 
>> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
>> 
>> This PR fixes this problem.
>
> It seems odd that the benchmark seems slower for smaller files; can you suggest why that might be?
> I'd expect the size distribution for Files.readString to be biased toward the smaller files.
> Can you repeat the benchmark using the default file system.  OS file caching should eliminate the disk speed effects.

@RogerRiggs 

I rerun benchmark based on the default file system, and the test file size is between 0 and 32KiB.

The throughput of reading ASCII files as UTF-8:
![image](https://user-images.githubusercontent.com/20694662/215230987-ded941e1-6260-497a-8f50-e62f9651c320.png)

The throughput of reading ASCII files as GBK:
![image](https://user-images.githubusercontent.com/20694662/215231012-0bc715c5-6473-4152-8089-4e64128e164e.png)

The performance has been slightly improved, and there is no performance degradation.

For UTF-8 and GBK files with non-ASCII characters, the throughput fluctuates by no more than 4%.

Test code and original results: https://gist.github.com/Glavo/f3d2060d0bd13cd0ce2add70e6060ea0?permalink_comment_id=4451350#gistcomment-4451350

> It seems odd that the benchmark seems slower for smaller files; can you suggest why that might be?

The most likely reason is the cost of the newly added if judgment in newStringUTF8NoRepl.

I don't think this is an important issue, because when it comes to actual I/O operations, its impact is negligible.

The main purpose of this PR is to eliminate unnecessary temporary memory allocation, thus reducing GC pressure. The change in throughput is only a by-product.

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 07:11:20 2023
From: duke at openjdk.org (j3graham)
Date: Sat, 28 Jan 2023 07:11:20 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
Message-ID: <IEY_MWRYLaYFvMP60vBzEu7-h-Q15JVoop7K54UQTaU=.633ce33f-c821-4def-b210-f1a14c3bb1f6@github.com>

On Fri, 27 Jan 2023 13:53:45 GMT, Glavo <duke at openjdk.org> wrote:

>> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
>> 
>> Their return values can be trusted, so many unnecessary array duplication can be eliminated.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collections.isTrustedCollection

What about creating a public `Collections.toArray(Collection c)` method that would return `c.toArray` for trusted collections, otherwise return a copy? This would allow any code to get a trustable array, while avoiding the copy when possible.

Even if this method was packaged-scoped, it might be a more concise way to access this capability in most cases.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From alanb at openjdk.org  Sat Jan 28 09:08:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 28 Jan 2023 09:08:15 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>
 <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>
Message-ID: <QWoUPLAiG6bIKRv_iIwuXR-e9Do-KaBsvSDv9cEpoMw=.02f9dd46-c999-4663-9c46-ec7b7e5beed4@github.com>

On Fri, 27 Jan 2023 21:02:25 GMT, Glavo <duke at openjdk.org> wrote:

> I think this is feasible, but it should be placed in a sub-package in `jdk.internal`, because some trusted collections are outside `java.util`.

The proposals so far in this PR have major security implications. It's not clear to me this is the right PR to expand into defining a JDK internal notion of trusted collection. I don't wish to discourage contributors in this area but I think it would be better if this issue was owned by experienced Committer in the area.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From eirbjo at gmail.com  Sat Jan 28 12:13:57 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 13:13:57 +0100
Subject: PR: Update the field access methods in ZipUtils to use the VarHandle
 API
Message-ID: <CA+pBWhsx2E+SRQwvGjYSQjnABkpykFcTanxJbFwJuN29eZgWQA@mail.gmail.com>

Hi,

Please review the following PR which suggests updating the field access
methods in ZipUtils to use the VarHandle API when reading multibyte values
from byte arrays:

https://github.com/openjdk/jdk/pull/12273

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/ab1899d2/attachment-0001.htm>

From duke at openjdk.org  Sat Jan 28 14:36:15 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 14:36:15 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <QWoUPLAiG6bIKRv_iIwuXR-e9Do-KaBsvSDv9cEpoMw=.02f9dd46-c999-4663-9c46-ec7b7e5beed4@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>
 <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>
 <QWoUPLAiG6bIKRv_iIwuXR-e9Do-KaBsvSDv9cEpoMw=.02f9dd46-c999-4663-9c46-ec7b7e5beed4@github.com>
Message-ID: <S3t3f6r3gis4Hq2Z6CdAYTFVw2pb4rPwsZw0LX1iu0A=.874684bd-4a20-498a-980a-7092f3e190f3@github.com>

On Sat, 28 Jan 2023 09:05:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The proposals so far in this PR have major security implications. It's not clear to me this is the right PR to expand into defining a JDK internal notion of trusted collection. I don't wish to discourage contributors in this area but I think it would be better if this issue was owned by an experienced Committer in the area.

If there are senior OpenJDK developers willing to take over this issue, I would like to welcome them very much. But I am worried that this issue has been put on hold, so I still hope to continue to make some attempts before I am sure that someone will take over.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Sat Jan 28 14:49:15 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 14:49:15 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <V1eobE_m5BnP3KYKqLUC2rEfAeyB2qKnWi2Wt4bIelw=.f0581bfb-bd0a-4eb5-9e09-dcc4208110a8@github.com>
 <QNQ1cNnxT1coixw_2oKKH4gi_Hqx7o-zUDiUJtwvuSk=.59c3015b-2a2c-4774-908c-0e0e0030b2f2@github.com>
Message-ID: <PjVC5Wb_eeqXyNuc9jAKNGmmVJZZttFeVfuA_JuXiac=.0191f6f6-025b-4237-bed5-a47e95eb1f5c@github.com>

On Fri, 27 Jan 2023 21:02:25 GMT, Glavo <duke at openjdk.org> wrote:

> I think the simplest solution is to have a non public interface declared inside java.util. Like java.util.RandomAccess, but non public. The main advantage to use an interface is that you can document it and it's easy to find all the implementations.

I think again that using interfaces may not be a good choice. "Trusted" should be specific to specific classes and cannot be inherited, because trusted methods can be overwritten by untrusted implementations in subclasses.

I think maybe annotation is a better choice, but the cost needs to be tested.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From eirbjo at gmail.com  Sat Jan 28 15:18:56 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 16:18:56 +0100
Subject: PR: Update the field access methods in ZipUtils to use the
 VarHandle API
In-Reply-To: <CA+pBWhsx2E+SRQwvGjYSQjnABkpykFcTanxJbFwJuN29eZgWQA@mail.gmail.com>
References: <CA+pBWhsx2E+SRQwvGjYSQjnABkpykFcTanxJbFwJuN29eZgWQA@mail.gmail.com>
Message-ID: <CA+pBWhsxZ6anCY2ZpRvrfGzcrSLz8ju53ff3n0B2njNTwnkSGg@mail.gmail.com>

>
> Please review the following PR which suggests updating the field access
> methods in ZipUtils to use the VarHandle API
> https://github.com/openjdk/jdk/pull/12273
>

Never mind, Claes pointed out that VarHandles may take some time to warp up
and we did indeed measure a regression for cold-start opening of ZipFiles.

I've closed this PR.

Thanks,
Eirik.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/4070ee1f/attachment.htm>

From forax at openjdk.org  Sat Jan 28 15:37:16 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 28 Jan 2023 15:37:16 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
Message-ID: <NRHTWp3jHKCziRcYlz_Yhu9-4h4T-OF4JnatYi4QFKc=.971665fb-6cd0-4050-8356-51681ad33635@github.com>

On Fri, 27 Jan 2023 13:53:45 GMT, Glavo <duke at openjdk.org> wrote:

>> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
>> 
>> Their return values can be trusted, so many unnecessary array duplication can be eliminated.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collections.isTrustedCollection

This may change the startup time a lot because initializing the annotation parser (and the factory around) and creating the annotations is quite slow.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From Alan.Bateman at oracle.com  Sat Jan 28 15:46:59 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 28 Jan 2023 15:46:59 +0000
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
Message-ID: <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>

On 26/01/2023 18:57, Eirik Bj?rsn?s wrote:
> Hi,
>
> This PR updates the test TestTooManyEntries to not create gigabytes of
> ZIP files, allowing the test to run fast and non-manual:
>
> https://github.com/openjdk/jdk/pull/12231
>
> May I please get some help with filing a JBS for this PR?
The intention of the test was exercise a multi-GB CEN. So I think it 
would be great if it could be re-written as an automatic test but I 
think it should be a real ZIP file, make use of sparse files might help.

-Alan

From eirbjo at gmail.com  Sat Jan 28 16:10:15 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 17:10:15 +0100
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
 <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
Message-ID: <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>

On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> The intention of the test was exercise a multi-GB CEN. So I think it
>
would be great if it could be re-written as an automatic test but I
> think it should be a real ZIP file, make use of sparse files might help.
>

Alan,

Yes, this change does exploit some knowledge of the internals of ZipFile.
Specifically it assumes that:

1: ZipFile seeks to the end of the JAR where it parses the End of central
directory header, then seeks backward to parse an optional Zip64 End of
central directory record / locator. At this point the CEN size is known.
2: That a too-large CEN size (obtained from ZIP64 or the normal end-of-cen
record) will be rejected early, before any attempt of reading the CEN or
other contents of the ZIP.
3: That ZipFIle will treat a ZIP file starting with an End of Central
directory (ZIP64 or not) as empty, short-circuiting any checking of invalid
CEN sizes.

Based on these assumptions, the test knows as a fact that any data up to
and including the CEN is never read by ZipFile. It seems a bit wasteful to
create multiple GBs of data which we know will never be read?

If you still prefer the test to use ZIPs which are valid from top to
bottom, I can take a stab at making that faster than the current test.

WDYT?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/d98df43b/attachment.htm>

From duke at openjdk.org  Sat Jan 28 16:18:14 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 16:18:14 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v2]
In-Reply-To: <NRHTWp3jHKCziRcYlz_Yhu9-4h4T-OF4JnatYi4QFKc=.971665fb-6cd0-4050-8356-51681ad33635@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <INKn0uJDwEz_0OfxPWb_mKD_Fi_I1x6D1hT0GPeQ6HM=.6f020452-48d1-4a3c-961a-262f5b17f62b@github.com>
 <NRHTWp3jHKCziRcYlz_Yhu9-4h4T-OF4JnatYi4QFKc=.971665fb-6cd0-4050-8356-51681ad33635@github.com>
Message-ID: <OhC-YrY-MRP6qqCL6BeN4GOPWUsw-NVBYdiRszG6mfI=.bfa609bf-6f23-46f4-8233-2ac9a84f13d0@github.com>

On Sat, 28 Jan 2023 15:34:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

> This may change the startup time a lot because initializing the annotation parser (and the factory around) and creating the annotations is quite slow.

Another option is to create a class list of trusted collection types. 

I will test it later, hoping that it will not load redundant classes or break bootstrap.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From amaembo at gmail.com  Sat Jan 28 16:20:59 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 28 Jan 2023 17:20:59 +0100
Subject: Math.clamp method?
In-Reply-To: <CAE+3fjZxoJFy=SyiT_uUA3HmzuMcj7yRu8C3u58WM_ALHr=ghg@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
 <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
 <CAE+3fjZxoJFy=SyiT_uUA3HmzuMcj7yRu8C3u58WM_ALHr=ghg@mail.gmail.com>
Message-ID: <CAE+3fjZXb0SUgr-g43eU5bht_r_NzrZN=706NzXUs2wG-eKujg@mail.gmail.com>

I also posted a CSR draft:
https://bugs.openjdk.org/browse/JDK-8301301

On Fri, Jan 27, 2023 at 11:46 AM Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello, all!
>
> Thank you for an interesting discussion. As I see some interest
> towards this feature, I've created a new issue to track this:
> https://bugs.openjdk.org/browse/JDK-8301226
> I haven't found an exact duplicate, only an issue with related
> discussion JDK-4466549. Feel free to link duplicates if you can search
> JIRA better than me :-)
>
> On Thu, Jan 26, 2023 at 12:47 AM John Rose <john.r.rose at oracle.com> wrote:
> >
> > Dealing with numeric ranges is error-prone, so I welcome these.
> >
> > Another operation on ranges is membership. This is easy to derive
> > from the clamp methods, I think:
> >
> >    checkRange(x,min,max) := clamp(x,min,max) == x
>
> checkRange relates somehow to the methods we have in
> java.util.Objects, namely checkFromIndexSize, checkIndex, etc. Though
> these methods are throwing an exception, rather than returning false.
> This could be considered as a separate enhancement.
>
> > But I think there is no harm and real benefit from widening
> > the value parameters, so value is always either long or double.
> > That will save casts (which also cause bugs) for some use
> > cases, such as doing 32x32-to-64-bit arithmetic followed
> > by overflow checks and/or saturation. That?s a common use
> > case for clamping.
> >
> > public static int clamp(long value, int min, int max)
> > public static long clamp(long value, long min, long max)
> > public static double clamp(double value, double min, double max)
> > public static float clamp(double value, float min, float max)
>
> I really like the idea of int clamp(long value, int min, int max), as
> this makes the method much more useful. On the other hand, I have
> doubles about
> float clamp(double value, float min, float max), as it could be called
> accidentally and we will have accidental precision loss. E.g., imagine
> the following code:
>
> // bounds are declared as floats for some reason
> // this usually doesn't matter, as these numbers are exact in float
> and in double
> float lower = 0.0f;
> float upper = 10.0f;
>
> double v = 1/3.;
> System.out.println(v);
> v = Math.clamp(v, lower, upper); // oops!
> System.out.println(v);
>
> Having float clamp(double, float, float), this method will be linked
> here, resulting in accidental precision loss. The output is:
> 0.3333333333333333
> 0.3333333432674408
>
> Given that float type is rarely used, I'd stick to the following signatures:
> public static int clamp(long value, int min, int max)
> public static long clamp(long value, long min, long max)
> public static double clamp(double value, double min, double max)
> public static float clamp(float value, float min, float max)
>
> > I thought about cross-domain clamps, which preserve 64 bit
> > precision and double range at the same time in different places:
> >
> > public static long clamp(long value, double min, double max)
> > public static long clamp(double value, long min, long max)
>
> This is even more dangerous, as simply calling
> double value = ...
> value = clamp(value, 0, 1); // not 0.0 and 1.0
> you will get 0 instead of the original value that fits the range.
> I imagine that many people will step on this. If these methods are desired,
> it would be better to name them differently, to avoid overload ambiguity.
> For now, I would avoid this.
>
> > The subexpression max-min never overflows, when it
> > is regarded as an unsigned number, and the ?>>>1?
> > immediately converts that unsigned number into the
> > correctly signed positive number. That?s the only
> > way to avoid overflow for all inputs. The third
> > idiom above (the ?smartest? of the three) will fail,
> > for example, if you feed it negative values.
> > For some uses that is OK, but for others it isn?t.
> >
> > public static int midpoint(int min, int max)
> > public static long midpoint(long min, long max)
> > public static double midpoint(double min, double max)
> > public static float midpoint(float min, float max)
>
> midpoint is another great idea, I like it! Could also be considered separately.
>
> With best regards,
> Tagir Valeev.

From lance.andersen at oracle.com  Sat Jan 28 16:29:21 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 28 Jan 2023 16:29:21 +0000
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
 <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
 <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>
Message-ID: <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>

I think it is fine to move the validation immediately following findEND() though I am not sure there is a big win overall.

I also would prefer to see the test based off of an actual ZIP(or at least have the current/modified version of the test).   I would prefer to avoid having another place where we have  duplicate code creating a CEN et al as it is another maintenance point.

One option is to look at, is to store a zip in a byte array and modify the cenlen offset(you would want to provide the steps that were used to create the zip/byte array, I can provide you a trivial example if interested)

 Best,
Lance

On Jan 28, 2023, at 11:10 AM, Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>> wrote:
The intention of the test was exercise a multi-GB CEN. So I think it
would be great if it could be re-written as an automatic test but I
think it should be a real ZIP file, make use of sparse files might help.

Alan,

Yes, this change does exploit some knowledge of the internals of ZipFile. Specifically it assumes that:

1: ZipFile seeks to the end of the JAR where it parses the End of central directory header, then seeks backward to parse an optional Zip64 End of central directory record / locator. At this point the CEN size is known.
2: That a too-large CEN size (obtained from ZIP64 or the normal end-of-cen record) will be rejected early, before any attempt of reading the CEN or other contents of the ZIP.
3: That ZipFIle will treat a ZIP file starting with an End of Central directory (ZIP64 or not) as empty, short-circuiting any checking of invalid CEN sizes.

Based on these assumptions, the test knows as a fact that any data up to and including the CEN is never read by ZipFile. It seems a bit wasteful to create multiple GBs of data which we know will never be read?

If you still prefer the test to use ZIPs which are valid from top to bottom, I can take a stab at making that faster than the current test.

WDYT?

Eirik.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/08b0ce4c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/08b0ce4c/oracle_sig_logo.gif>

From john.r.rose at oracle.com  Sat Jan 28 16:37:40 2023
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 28 Jan 2023 16:37:40 +0000
Subject: Math.clamp method?
In-Reply-To: <CAE+3fjZxoJFy=SyiT_uUA3HmzuMcj7yRu8C3u58WM_ALHr=ghg@mail.gmail.com>
References: <CAE+3fja_Nb3dDvaryG3Xv7X=1oe7ALzZg0LDDMxAgmLyviyfMA@mail.gmail.com>
 <296EEDF3-4CCF-48E8-BF91-F73606468D54@oracle.com>
 <CAE+3fjZxoJFy=SyiT_uUA3HmzuMcj7yRu8C3u58WM_ALHr=ghg@mail.gmail.com>
Message-ID: <CB62EFF6-CD6C-4AA4-AABF-8EC0C13681F4@oracle.com>


> On Jan 27, 2023, at 2:46 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> ??
>> 
>> 
>> public static int clamp(long value, int min, int max)
>> public static long clamp(long value, long min, long max)
>> public static double clamp(double value, double min, double max)
>> public static float clamp(double value, float min, float max)
> 
> I really like the idea of int clamp(long value, int min, int max), as
> this makes the method much more useful. On the other hand, I have
> doubles about
> float clamp(double value, float min, float max), as it could be called
> accidentally and we will have accidental precision loss. E.g., imagine
> the following code:

That was a typo. Oops, sorry. All I am trying to suggest is to widen both the first argument and the return value to long or double. 
> 
> // bounds are declared as floats for some reason
> // this usually doesn't matter, as these numbers are exact in float
> and in double
> float lower = 0.0f;
> float upper = 10.0f;
> 
> double v = 1/3.;
> System.out.println(v);
> v = Math.clamp(v, lower, upper); // oops!
> System.out.println(v);
> 
> Having float clamp(double, float, float), this method will be linked
> here, resulting in accidental precision loss. The output is:
> 0.3333333333333333
> 0.3333333432674408
> 
> Given that float type is rarely used, I'd stick to the following signatures:
> public static int clamp(long value, int min, int max)
> public static long clamp(long value, long min, long max)
> public static double clamp(double value, double min, double max)
> public static float clamp(float value, float min, float max)
> 
>> I thought about cross-domain clamps, which preserve 64 bit
>> precision and double range at the same time in different places:
>> 
>> public static long clamp(long value, double min, double max)
>> public static long clamp(double value, long min, long max)
> 
> This is even more dangerous, as simply calling
> double value = ...
> value = clamp(value, 0, 1); // not 0.0 and 1.0
> you will get 0 instead of the original value that fits the range.
> I imagine that many people will step on this. If these methods are desired,
> it would be better to name them differently, to avoid overload ambiguity.
> For now, I would avoid this.

Of course. Widen the return if you widen the first argument. Then it works out. 
> 
>> The subexpression max-min never overflows, when it
>> is regarded as an unsigned number, and the ?>>>1?
>> immediately converts that unsigned number into the
>> correctly signed positive number. That?s the only
>> way to avoid overflow for all inputs. The third
>> idiom above (the ?smartest? of the three) will fail,
>> for example, if you feed it negative values.
>> For some uses that is OK, but for others it isn?t.
>> 
>> public static int midpoint(int min, int max)
>> public static long midpoint(long min, long max)
>> public static double midpoint(double min, double max)
>> public static float midpoint(float min, float max)
> 
> midpoint is another great idea, I like it! Could also be considered separately.
> 
> With best regards,
> Tagir Valeev.

From Alan.Bateman at oracle.com  Sat Jan 28 17:06:14 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 28 Jan 2023 17:06:14 +0000
Subject: Why does ZipFile.Source.readFullyAt read in chunks?
In-Reply-To: <CA+pBWhuFUcajEz0t6SUNtd0DiBqiJV1=BB0wOEjh9SDS24WbMA@mail.gmail.com>
References: <CA+pBWhuFUcajEz0t6SUNtd0DiBqiJV1=BB0wOEjh9SDS24WbMA@mail.gmail.com>
Message-ID: <10763b87-97ad-063c-59bd-889e5ab2a681@oracle.com>

On 27/01/2023 23:23, Eirik Bj?rsn?s wrote:
> :
>
> If this is safe to remove, I'm happy to submit a PR. But code like 
> this is usually?there for a reason..?
>
8k is the threshold at which RAF spills into a temporary malloc'ed 
buffer for the I/O operation. At some point the RAF implementation will 
be replaced (we need to do this for a Project Loom), but in the mean 
time, it probably would require testing on a wide set of platforms and 
conditions to see the impact.

-Alan.

From eirbjo at gmail.com  Sat Jan 28 17:37:53 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 18:37:53 +0100
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
 <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
 <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>
 <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
Message-ID: <CA+pBWhv3bD5OWx2-zNUfm6nSyU7kq12aQwF3SAeSDcYNP=NWFA@mail.gmail.com>

On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen <lance.andersen at oracle.com>
wrote:

> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).   I would prefer to avoid
> having another place where we have  duplicate code creating a CEN et al as
> it is another maintenance point.
>
> One option is to look at, is to store a zip in a byte array and modify the
> cenlen offset(you would want to provide the steps that were used to create
> the zip/byte array, I can provide you a trivial example if interested)
>

Thanks Lance!

This inspired me to update the PR with the following changes:

- Make "real" ZIP files using ZipOutputStream as suggested, avoiding
duplicating ZIP format internals
- Put one entry in the ZIP files instead of being empty
- Surgically update the CEN size in the END record to the desired value
- Remove all code to create and test ZIP64 files. What we are testing here
is rejection of certain CEN values, not how they are parsed

The test case for the "big but valid" ZIP is updated to detect that the CEN
size is rejected for being invalid (but not too large). ZipFIle is updated
accordingly to move the CEN size checking closer to the other tests (after
the zero-entry-short-circuit test)

While the ZIPs are still not GB-huge, and they are still invalid, the test
now at least asserts them as such.

What do you think of this update?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/2f84a335/attachment.htm>

From eirbjo at gmail.com  Sat Jan 28 17:53:39 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 28 Jan 2023 18:53:39 +0100
Subject: Why does ZipFile.Source.readFullyAt read in chunks?
In-Reply-To: <10763b87-97ad-063c-59bd-889e5ab2a681@oracle.com>
References: <CA+pBWhuFUcajEz0t6SUNtd0DiBqiJV1=BB0wOEjh9SDS24WbMA@mail.gmail.com>
 <10763b87-97ad-063c-59bd-889e5ab2a681@oracle.com>
Message-ID: <CA+pBWhuqCiY5q3XNgE67eUOZDLTgUS6Tm6PLrWXqJqjH8s9=uw@mail.gmail.com>

On Sat, Jan 28, 2023 at 6:06 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 8k is the threshold at which RAF spills into a temporary malloc'ed
> buffer for the I/O operation. At some point the RAF implementation will
> be replaced (we need to do this for a Project Loom), but in the mean
> time, it probably would require testing on a wide set of platforms and
> conditions to see the impact.
>

Makes sense!

Would it be worth going through a PR to add a comment to document this
somewhat obscure code?

https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:raf-buf-threshold

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/3ed85769/attachment-0001.htm>

From rriggs at openjdk.org  Sat Jan 28 19:31:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 28 Jan 2023 19:31:19 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <Sns08pDdI21hc889TxflRCaltLpgkbCoc_sbgdsau8E=.5d7190b2-387e-4466-9abf-314430673ec3@github.com>

On Fri, 20 Jan 2023 16:47:27 GMT, Glavo <duke at openjdk.org> wrote:

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

src/java.base/share/classes/java/lang/String.java line 701:

> 699:      * Throws iae, instead of replacing, if malformed or unmappable.
> 700:      */
> 701:     static String newStringUTF8NoRepl(byte[] bytes, int offset, int length, boolean noCopy) {

The parameter will be easier to understand if `true` means that the string created must not share the byte array supplied.
For example,

@param noShare {@code true} if the resulting string MUST NOT share the byte array, {@code false} if the byte array can be exclusively used to construct the string and is not modified or used for any other purpose.

This flips the boolean argument in the uses below.

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 19:43:24 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 19:43:24 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v2]
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <z9aAKGFI1lumfmIN47lkMlTvTd8_q2VECl_UVrDVbjE=.66608aa7-331b-4f25-af1a-9392753d400d@github.com>

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12119/files
  - new: https://git.openjdk.org/jdk/pull/12119/files/9ec85ef0..5a0feb8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=00-01

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12119.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12119/head:pull/12119

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 19:43:27 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 19:43:27 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v2]
In-Reply-To: <Sns08pDdI21hc889TxflRCaltLpgkbCoc_sbgdsau8E=.5d7190b2-387e-4466-9abf-314430673ec3@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
 <Sns08pDdI21hc889TxflRCaltLpgkbCoc_sbgdsau8E=.5d7190b2-387e-4466-9abf-314430673ec3@github.com>
Message-ID: <XxiZcUjdnd1_sAovs63F-NTRrkIRzn5y8_LsfLOUWLw=.082ec813-3709-4b1d-bf5d-5912ea455f3e@github.com>

On Sat, 28 Jan 2023 19:28:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The parameter will be easier to understand if `true` means that the string created must not share the byte array supplied. For example,
> 
> @param noShare {@code true} if the resulting string MUST NOT share the byte array, {@code false} if the byte array can be exclusively used to construct the string and is not modified or used for any other purpose.
> 
> This flips the boolean argument in the uses below.

I modified it according to your suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 19:49:23 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 19:49:23 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v3]
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <20BQbWejxWVwm-UMBMmyaUi42Inro6bSXyp44RFCSEM=.f2268c5f-19b0-435c-8cce-0512a1ba6ab6@github.com>

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  fix checkstyle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12119/files
  - new: https://git.openjdk.org/jdk/pull/12119/files/5a0feb8b..0e85eb0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12119.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12119/head:pull/12119

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Sat Jan 28 19:54:32 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 28 Jan 2023 19:54:32 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v4]
In-Reply-To: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
Message-ID: <Vx28T_kz1S269a338ZKHml6BsD2PSys4n_3InHizsEI=.6fa9ef82-7a95-467b-bd05-4217548eed9e@github.com>

> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
> 
> 
>     /**
>      * Constructs a new {@code String} by decoding the specified subarray of
>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>      *
>      * The caller of this method shall relinquish and transfer the ownership of
>      * the byte array to the callee since the later will not make a copy.
>      *
>      * @param bytes the byte array source
>      * @param cs the Charset
>      * @return the newly created string
>      * @throws CharacterCodingException for malformed or unmappable bytes
>      */
> 
> 
> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
> 
> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
> 
> This PR fixes this problem.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12119/files
  - new: https://git.openjdk.org/jdk/pull/12119/files/0e85eb0f..cae6e8cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12119&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12119.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12119/head:pull/12119

PR: https://git.openjdk.org/jdk/pull/12119

From ihse at openjdk.org  Sat Jan 28 21:11:19 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 28 Jan 2023 21:11:19 GMT
Subject: RFR: 8298045: Fix hidden but significant trailing whitespace in
 properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <w7KccocVX-Hjgp7XUeeMx_MdQOyPQM_PoX6M9avXCas=.ecef766b-8db5-460b-92a6-79a8ae8a3512@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

Bot-Keep-Alive-Ping

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From duke at openjdk.org  Sun Jan 29 03:43:51 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 03:43:51 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection
Message-ID: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>

Adding the following methods to check the nullity of elements of an array or a collection:


java.util.Arrays:
public static <E> E[] requireNoNulls(E[] array)
public static <E> E[] requireNoNulls(E[] array, String message)
public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
public static <E> E[] requireNoNullsCopied(E[] array)
public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
public static <E> E[] requireNoNullsCopied(E[] array, String message)

java.util.Collections:
public static <C extends Iterable<?>> C requireNoNulls(C collection)
public static <M extends Map<?, ?>> M requireNoNulls(M map)
public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)

-------------

Commit messages:
 - Update Arrays.java
 - Update Collections.java
 - Fix whitespace
 - Fix whitespace
 - Update Collections.java
 - Update Arrays.java
 - Update Collections.java
 - Update Arrays.java

Changes: https://git.openjdk.org/jdk/pull/12276/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301042
  Stats: 377 lines in 2 files changed: 377 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12276.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12276/head:pull/12276

PR: https://git.openjdk.org/jdk/pull/12276

From duke at openjdk.org  Sun Jan 29 04:09:36 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 04:09:36 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection [v2]
In-Reply-To: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
Message-ID: <qabe22yTWfWAgyfP4iNQXvVXgyLfwonaKd9UV8ewlCY=.e36f4a2e-43e5-44d0-8642-d28c3d35ae30@github.com>

> Adding the following methods to check the nullity of elements of an array or a collection:
> 
> 
> java.util.Arrays:
> public static <E> E[] requireNoNulls(E[] array)
> public static <E> E[] requireNoNulls(E[] array, String message)
> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array)
> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array, String message)
> 
> java.util.Collections:
> public static <C extends Iterable<?>> C requireNoNulls(C collection)
> public static <M extends Map<?, ?>> M requireNoNulls(M map)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  `requireNoNullsCopied` should return `result`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12276/files
  - new: https://git.openjdk.org/jdk/pull/12276/files/81fe5962..46cabde5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12276.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12276/head:pull/12276

PR: https://git.openjdk.org/jdk/pull/12276

From duke at openjdk.org  Sun Jan 29 04:34:35 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 04:34:35 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection [v3]
In-Reply-To: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
Message-ID: <TwS1pCoK5wcrmcxZrvhEXGc5eCNn3_kgZY5DUzDh3y8=.b7ea6d16-a6cf-4508-8ccf-95bfb0439219@github.com>

> Adding the following methods to check the nullity of elements of an array or a collection:
> 
> 
> java.util.Arrays:
> public static <E> E[] requireNoNulls(E[] array)
> public static <E> E[] requireNoNulls(E[] array, String message)
> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array)
> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array, String message)
> 
> java.util.Collections:
> public static <C extends Iterable<?>> C requireNoNulls(C collection)
> public static <M extends Map<?, ?>> M requireNoNulls(M map)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Add `replace` methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12276/files
  - new: https://git.openjdk.org/jdk/pull/12276/files/46cabde5..11a7e87b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=01-02

  Stats: 67 lines in 1 file changed: 67 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12276.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12276/head:pull/12276

PR: https://git.openjdk.org/jdk/pull/12276

From duke at openjdk.org  Sun Jan 29 04:53:27 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 04:53:27 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection [v4]
In-Reply-To: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
Message-ID: <Ku5rNQYRYfE0yPgRD4Yl5_l1ZWcisJLtXolHw7RygS4=.9b9519e5-51d2-487c-8e85-863374b1373b@github.com>

> Adding the following methods to check the nullity of elements of an array or a collection:
> 
> 
> java.util.Arrays:
> public static <E> E[] requireNoNulls(E[] array)
> public static <E> E[] requireNoNulls(E[] array, String message)
> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array)
> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array, String message)
> 
> java.util.Collections:
> public static <C extends Iterable<?>> C requireNoNulls(C collection)
> public static <M extends Map<?, ?>> M requireNoNulls(M map)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)

Tingjun Yuan has updated the pull request incrementally with two additional commits since the last revision:

 - Fix the type parameter doc
 - Add `replace` method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12276/files
  - new: https://git.openjdk.org/jdk/pull/12276/files/11a7e87b..3744b35d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=02-03

  Stats: 34 lines in 1 file changed: 34 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12276.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12276/head:pull/12276

PR: https://git.openjdk.org/jdk/pull/12276

From duke at openjdk.org  Sun Jan 29 06:50:03 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 06:50:03 GMT
Subject: RFR: 8301043: Super-interface for PrintStream and PrintWriter
Message-ID: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>

Add `java.io.PrintOutput` to represent print operations, and modify `java.io.PrintStream` and `java.io.PrintWriter` to implement it.

-------------

Commit messages:
 - remove `@since 1.5`
 - Make PrintWriter implement PrintOutput
 - Make PrintStream implement PrintOutput
 - Create PrintOutput.java

Changes: https://git.openjdk.org/jdk/pull/12277/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12277&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301043
  Stats: 589 lines in 3 files changed: 587 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12277.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12277/head:pull/12277

PR: https://git.openjdk.org/jdk/pull/12277

From duke at openjdk.org  Sun Jan 29 07:11:26 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 07:11:26 GMT
Subject: RFR: 8301043: Super-interface for PrintStream and PrintWriter [v2]
In-Reply-To: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>
References: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>
Message-ID: <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>

> Add `java.io.PrintOutput` to represent print operations, and modify `java.io.PrintStream` and `java.io.PrintWriter` to implement it.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Fix grammar mistakes in the doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12277/files
  - new: https://git.openjdk.org/jdk/pull/12277/files/0c8495da..645e30d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12277&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12277&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12277.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12277/head:pull/12277

PR: https://git.openjdk.org/jdk/pull/12277

From duke at openjdk.org  Sun Jan 29 10:39:22 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 10:39:22 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection [v5]
In-Reply-To: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
Message-ID: <j4n3QQ41VK1sUteOM3oRjWAflUsbOGKJwfFYnB6YCgM=.a824d796-1a25-42f7-a46f-54f340425e65@github.com>

> Adding the following methods to check the nullity of elements of an array or a collection:
> 
> 
> java.util.Arrays:
> public static <E> E[] requireNoNulls(E[] array)
> public static <E> E[] requireNoNulls(E[] array, String message)
> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
> public static <E> E[] requireNoNullsCopied(E[] array)
> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
> public static <E> E[] requireNoNullsCopied(E[] array, String message)
> public static <E> E[] requireNoNullsCopiedElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
> 
> java.util.Collections:
> public static <C extends Iterable<?>> C requireNoNulls(C collection)
> public static <M extends Map<?, ?>> M requireNoNulls(M map)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)
> public static <E, L extends List<? super E>> L requireNoNullsElseReplace(L list, IntFunction<? extends E> replaceFunction)

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  `requireNoNullsCopiedElseReplace` should modify `result`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12276/files
  - new: https://git.openjdk.org/jdk/pull/12276/files/3744b35d..bfb8225f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12276&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12276.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12276/head:pull/12276

PR: https://git.openjdk.org/jdk/pull/12276

From john.hendrikx at gmail.com  Sun Jan 29 15:28:39 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 29 Jan 2023 16:28:39 +0100
Subject: NPE throwing behavior of immutable collections
Message-ID: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>

TLDR; why does contains(null) not just return false for collections that 
don't allow nulls. Just because the interface allows it, does not mean 
it should do it as it devalues the usefulness of the abstraction 
provided by the interface.

Background:

I'm someone that likes to check correctness of any constructor or method 
parameter before allowing an object to be constructed or to be modified, 
in order to maintain invariants that are provided by the class to its users.

This ranges from simple null checks, to range checks on numeric values, 
to complete checks like "is a collection sorted" or is a list of nodes 
acyclic. Anything I can check in the constructor that may avoid problems 
further down the line or that may affect what I can guarantee on its own 
API methods.? For example, if I check in the constructor that something 
is not null, then the associated getter will guarantee that the returned 
value is not null.? If I check that a List doesn't contain nulls, then 
the associated getter will reflect that as well (assuming it is 
immutable or defensivily copied).

For collections, this is currently becoming harder and harder because 
more and more new collections are written to be null hostile.? It is 
fine if a collection doesn't accept nulls, but throwing NPE when I ask 
such a collection if it contains null seems to be counter productive, 
and reduces the usefulness of the collection interfaces.

This strict interpretation makes the collection interfaces harder to use 
than necessary. Interfaces are only useful when their contract is well 
defined. The more things an interface allows or leaves unspecified, the 
less useful it is for its users.

I know that the collection interfaces allow this, but you have to ask 
yourself this important question: how useful is an interface that makes 
almost no guarantees about what its methods will do? Interfaces like 
`List`, `Map` and `Set` are passed as method parameters a lot, and to 
make these useful, implementations of these interfaces should do their 
best to provide as consistent an experience as is reasonably possible.? 
The alternative is that these interfaces will slowly decline in 
usefulness as methods will start asking for `ArrayList` instead of 
`List` to avoid having to deal with a too lenient specification.

With the collection interfaces I get the impression that recently there 
has been too much focus on what would be easy for the collection 
implementation instead of what would be easy for the users of said 
interfaces. In my opinion, the concerns of the user of interfaces almost 
always far outweigh the concerns of the implementors of said interfaces.

In the past, immutable collections were rare, but they get are getting 
more and more common all the time.? For example, in unit testing. 
Unfortunately, these immutable collections differ quite a bit from their 
mutable counterparts.? Some parts are only midly annoying (not accepting 
`null` as the **value** in a `Map` for example), but other parts require 
code to be rewritten for it to be able to work as a drop-in replacement 
for the mutable variant. A simple example is this:

 ??? public void addShoppingItems(Collection<String> shoppingItems) {
 ??????? if (shoppingItems.contains(null)) {? // this looks quite 
reasonable and safe...
 ??????????? throw new IllegalArgumentException("shoppingItems should 
not contain nulls");
 ??????? }

 ??????? this.shoppingItems.addAll(shoppingItems);
 ??? }

Testing this code is annoying:

 ???? x.addShoppingItems(List.of("a", null"));?? // can't construct 
immutable collection with null

 ???? x.addShoppingItems(Arrays.asList("a", null"));? // fine, go back 
to what we did before then...

The above problems, I suppose we can live with it; immutable collections 
don't want `null` although I don't see any reason to not allow it as I 
can write a similar `List.of` that returns immutable collections that do 
allow `null`. For JDK code this is a bit disconcerting, as it is 
supposed to be as flexible as is reasonable without having too much of 
an opinion about what is good or bad.

This next one however:

 ?? ? assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a", 
"b")));? // not allowed, contains(null) in application code throws NPE

This is much more insidious; the `contains(null)` check has been a very 
practical way to check if collections contain null, and this works for 
almost all collections in common use, so there is no problem.? But now, 
more and more collections are starting to just throw NPE immediately 
even just to **check** if a null element is present. This only serves to 
distinguish themselves loudly from other similar collections that will 
simply return `false`.

I think this behavior is detrimental to the java collection interfaces 
in general, especially since there is a clear answer to the question if 
such a collection contains null or not. In fact, why `contains` was ever 
allowed to throw an exception aside from "UnsupportedOperationException" 
is a mystery to me, and throwing one when one could just as easily 
return the correct and expected answer seems very opiniated and almost 
malicious -- not behavior I'd expect from JDK core libraries.

Also note that there is no way to know in advance if `contains(null)` is 
going to be throwing the NPE. If interfaces had a method `allowsNulls()` 
that would already be an improvement.

--John



From plevart at openjdk.org  Sun Jan 29 16:10:16 2023
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 29 Jan 2023 16:10:16 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
Message-ID: <YqQ7Hhi61ORhRgZw5nisy3dfzJ9_qTVbZyVqMIF7n0U=.17b2eeec-e80b-4128-8769-503da4cc0620@github.com>

On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

>> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
>> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.
>
> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about method inlining

Hi Christian, I can sponsor to pull this change if you like.

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From javalists at cbfiddle.com  Sun Jan 29 17:00:59 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 29 Jan 2023 09:00:59 -0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
Message-ID: <31E4BD99-1058-4323-9434-C3B39A039BAD@cbfiddle.com>

I tend to agree.

Presumably it is similar reasoning that led to Collection<E>.contains() to take Object rather than E.

> On Jan 29, 2023, at 7:28 AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> TLDR; why does contains(null) not just return false for collections that don't allow nulls. Just because the interface allows it, does not mean it should do it as it devalues the usefulness of the abstraction provided by the interface.
> 
> Background:
> 
> I'm someone that likes to check correctness of any constructor or method parameter before allowing an object to be constructed or to be modified, in order to maintain invariants that are provided by the class to its users.
> 
> This ranges from simple null checks, to range checks on numeric values, to complete checks like "is a collection sorted" or is a list of nodes acyclic. Anything I can check in the constructor that may avoid problems further down the line or that may affect what I can guarantee on its own API methods.  For example, if I check in the constructor that something is not null, then the associated getter will guarantee that the returned value is not null.  If I check that a List doesn't contain nulls, then the associated getter will reflect that as well (assuming it is immutable or defensivily copied).
> 
> For collections, this is currently becoming harder and harder because more and more new collections are written to be null hostile.  It is fine if a collection doesn't accept nulls, but throwing NPE when I ask such a collection if it contains null seems to be counter productive, and reduces the usefulness of the collection interfaces.
> 
> This strict interpretation makes the collection interfaces harder to use than necessary. Interfaces are only useful when their contract is well defined. The more things an interface allows or leaves unspecified, the less useful it is for its users.
> 
> I know that the collection interfaces allow this, but you have to ask yourself this important question: how useful is an interface that makes almost no guarantees about what its methods will do? Interfaces like `List`, `Map` and `Set` are passed as method parameters a lot, and to make these useful, implementations of these interfaces should do their best to provide as consistent an experience as is reasonably possible.  The alternative is that these interfaces will slowly decline in usefulness as methods will start asking for `ArrayList` instead of `List` to avoid having to deal with a too lenient specification.
> 
> With the collection interfaces I get the impression that recently there has been too much focus on what would be easy for the collection implementation instead of what would be easy for the users of said interfaces. In my opinion, the concerns of the user of interfaces almost always far outweigh the concerns of the implementors of said interfaces.
> 
> In the past, immutable collections were rare, but they get are getting more and more common all the time.  For example, in unit testing. Unfortunately, these immutable collections differ quite a bit from their mutable counterparts.  Some parts are only midly annoying (not accepting `null` as the **value** in a `Map` for example), but other parts require code to be rewritten for it to be able to work as a drop-in replacement for the mutable variant. A simple example is this:
> 
>     public void addShoppingItems(Collection<String> shoppingItems) {
>         if (shoppingItems.contains(null)) {  // this looks quite reasonable and safe...
>             throw new IllegalArgumentException("shoppingItems should not contain nulls");
>         }
> 
>         this.shoppingItems.addAll(shoppingItems);
>     }
> 
> Testing this code is annoying:
> 
>      x.addShoppingItems(List.of("a", null"));   // can't construct immutable collection with null
> 
>      x.addShoppingItems(Arrays.asList("a", null"));  // fine, go back to what we did before then...
> 
> The above problems, I suppose we can live with it; immutable collections don't want `null` although I don't see any reason to not allow it as I can write a similar `List.of` that returns immutable collections that do allow `null`. For JDK code this is a bit disconcerting, as it is supposed to be as flexible as is reasonable without having too much of an opinion about what is good or bad.
> 
> This next one however:
> 
>      assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a", "b")));  // not allowed, contains(null) in application code throws NPE
> 
> This is much more insidious; the `contains(null)` check has been a very practical way to check if collections contain null, and this works for almost all collections in common use, so there is no problem.  But now, more and more collections are starting to just throw NPE immediately even just to **check** if a null element is present. This only serves to distinguish themselves loudly from other similar collections that will simply return `false`.
> 
> I think this behavior is detrimental to the java collection interfaces in general, especially since there is a clear answer to the question if such a collection contains null or not. In fact, why `contains` was ever allowed to throw an exception aside from "UnsupportedOperationException" is a mystery to me, and throwing one when one could just as easily return the correct and expected answer seems very opiniated and almost malicious -- not behavior I'd expect from JDK core libraries.
> 
> Also note that there is no way to know in advance if `contains(null)` is going to be throwing the NPE. If interfaces had a method `allowsNulls()` that would already be an improvement.
> 
> --John
> 
> 


From zjx001202 at gmail.com  Sun Jan 29 17:37:02 2023
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 30 Jan 2023 01:37:02 +0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
Message-ID: <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>

I quite agree with you. I think the collection framework is in a very
puzzling state.

The hostility of the new collection factory method introduced by Java 9 to
null has brought us trouble.
I can understand that this is to expect users to explicitly declare that
the elements of the list cannot be null, rather than in an ambiguous state.
However, this makes migration more difficult, and the cost of scanning all
elements to ensure that they are not null is also unpleasant.
I hope to provide an additional set of factory methods for the collection
to accept nullable elements.

In addition, it is also confusing to share the same interface between
mutable collections and immutable collections .
Before encountering UnsupportedOperationException, we can't even know what
operations a collection supports.
This problem has existed for a long time, but no solution has been given.


On Sun, Jan 29, 2023 at 11:28 PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> TLDR; why does contains(null) not just return false for collections that
> don't allow nulls. Just because the interface allows it, does not mean
> it should do it as it devalues the usefulness of the abstraction
> provided by the interface.
>
> Background:
>
> I'm someone that likes to check correctness of any constructor or method
> parameter before allowing an object to be constructed or to be modified,
> in order to maintain invariants that are provided by the class to its
> users.
>
> This ranges from simple null checks, to range checks on numeric values,
> to complete checks like "is a collection sorted" or is a list of nodes
> acyclic. Anything I can check in the constructor that may avoid problems
> further down the line or that may affect what I can guarantee on its own
> API methods.  For example, if I check in the constructor that something
> is not null, then the associated getter will guarantee that the returned
> value is not null.  If I check that a List doesn't contain nulls, then
> the associated getter will reflect that as well (assuming it is
> immutable or defensivily copied).
>
> For collections, this is currently becoming harder and harder because
> more and more new collections are written to be null hostile.  It is
> fine if a collection doesn't accept nulls, but throwing NPE when I ask
> such a collection if it contains null seems to be counter productive,
> and reduces the usefulness of the collection interfaces.
>
> This strict interpretation makes the collection interfaces harder to use
> than necessary. Interfaces are only useful when their contract is well
> defined. The more things an interface allows or leaves unspecified, the
> less useful it is for its users.
>
> I know that the collection interfaces allow this, but you have to ask
> yourself this important question: how useful is an interface that makes
> almost no guarantees about what its methods will do? Interfaces like
> `List`, `Map` and `Set` are passed as method parameters a lot, and to
> make these useful, implementations of these interfaces should do their
> best to provide as consistent an experience as is reasonably possible.
> The alternative is that these interfaces will slowly decline in
> usefulness as methods will start asking for `ArrayList` instead of
> `List` to avoid having to deal with a too lenient specification.
>
> With the collection interfaces I get the impression that recently there
> has been too much focus on what would be easy for the collection
> implementation instead of what would be easy for the users of said
> interfaces. In my opinion, the concerns of the user of interfaces almost
> always far outweigh the concerns of the implementors of said interfaces.
>
> In the past, immutable collections were rare, but they get are getting
> more and more common all the time.  For example, in unit testing.
> Unfortunately, these immutable collections differ quite a bit from their
> mutable counterparts.  Some parts are only midly annoying (not accepting
> `null` as the **value** in a `Map` for example), but other parts require
> code to be rewritten for it to be able to work as a drop-in replacement
> for the mutable variant. A simple example is this:
>
>      public void addShoppingItems(Collection<String> shoppingItems) {
>          if (shoppingItems.contains(null)) {  // this looks quite
> reasonable and safe...
>              throw new IllegalArgumentException("shoppingItems should
> not contain nulls");
>          }
>
>          this.shoppingItems.addAll(shoppingItems);
>      }
>
> Testing this code is annoying:
>
>       x.addShoppingItems(List.of("a", null"));   // can't construct
> immutable collection with null
>
>       x.addShoppingItems(Arrays.asList("a", null"));  // fine, go back
> to what we did before then...
>
> The above problems, I suppose we can live with it; immutable collections
> don't want `null` although I don't see any reason to not allow it as I
> can write a similar `List.of` that returns immutable collections that do
> allow `null`. For JDK code this is a bit disconcerting, as it is
> supposed to be as flexible as is reasonable without having too much of
> an opinion about what is good or bad.
>
> This next one however:
>
>       assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a",
> "b")));  // not allowed, contains(null) in application code throws NPE
>
> This is much more insidious; the `contains(null)` check has been a very
> practical way to check if collections contain null, and this works for
> almost all collections in common use, so there is no problem.  But now,
> more and more collections are starting to just throw NPE immediately
> even just to **check** if a null element is present. This only serves to
> distinguish themselves loudly from other similar collections that will
> simply return `false`.
>
> I think this behavior is detrimental to the java collection interfaces
> in general, especially since there is a clear answer to the question if
> such a collection contains null or not. In fact, why `contains` was ever
> allowed to throw an exception aside from "UnsupportedOperationException"
> is a mystery to me, and throwing one when one could just as easily
> return the correct and expected answer seems very opiniated and almost
> malicious -- not behavior I'd expect from JDK core libraries.
>
> Also note that there is no way to know in advance if `contains(null)` is
> going to be throwing the NPE. If interfaces had a method `allowsNulls()`
> that would already be an improvement.
>
> --John
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230130/750e5410/attachment.htm>

From smarks at openjdk.org  Sun Jan 29 21:59:17 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sun, 29 Jan 2023 21:59:17 GMT
Subject: RFR: 8301042: Need methods to check null elements in an array or a
 collection [v5]
In-Reply-To: <j4n3QQ41VK1sUteOM3oRjWAflUsbOGKJwfFYnB6YCgM=.a824d796-1a25-42f7-a46f-54f340425e65@github.com>
References: <epNUkMH0qh0P8-TGgqvCeg_FzJ23mHTeLQoH-BrNh0U=.c35f37fb-26ba-455c-b72b-1d0ba2cd920a@github.com>
 <j4n3QQ41VK1sUteOM3oRjWAflUsbOGKJwfFYnB6YCgM=.a824d796-1a25-42f7-a46f-54f340425e65@github.com>
Message-ID: <b6s8ZXB0gni9e8Wl2_ZBhvrAjJTM65xWXmybL8_e92I=.1aa92464-1d47-4264-a9eb-bab19a963a61@github.com>

On Sun, 29 Jan 2023 10:39:22 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Adding the following methods to check the nullity of elements of an array or a collection:
>> 
>> 
>> java.util.Arrays:
>> public static <E> E[] requireNoNulls(E[] array)
>> public static <E> E[] requireNoNulls(E[] array, String message)
>> public static <E> E[] requireNoNulls(E[] array, IntFunction<String> messageGenerator)
>> public static <E> E[] requireNoNullsElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
>> public static <E> E[] requireNoNullsCopied(E[] array)
>> public static <E> E[] requireNoNullsCopied(E[] array, IntFunction<String> messageGenerator)
>> public static <E> E[] requireNoNullsCopied(E[] array, String message)
>> public static <E> E[] requireNoNullsCopiedElseReplace(E[] array, IntFunction<? extends E> replaceFunction)
>> 
>> java.util.Collections:
>> public static <C extends Iterable<?>> C requireNoNulls(C collection)
>> public static <M extends Map<?, ?>> M requireNoNulls(M map)
>> public static <C extends Iterable<?>> C requireNoNulls(C collection, String message)
>> public static <M extends Map<?, ?>> M requireNoNulls(M map, String message)
>> public static <C extends Iterable<?>> C requireNoNulls(C collection, Supplier<String> messageSupplier)
>> public static <M extends Map<?, ?>> M requireNoNulls(M map, Supplier<String> messageSupplier)
>> public static <L extends List<?>> L requireNoNulls(L list, IntFunction<String> messageGenerator)
>> public static <E, L extends List<? super E>> L requireNoNullsElseReplace(L list, IntFunction<? extends E> replaceFunction)
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   `requireNoNullsCopiedElseReplace` should modify `result`

I don't think we need these methods. Most of what they do can be done by the following:

    coll.forEach(Objects::requireNonNull)
    Arrays.asList(array).forEach(Objects::requireNonNull)

-------------

PR: https://git.openjdk.org/jdk/pull/12276

From duke at openjdk.org  Sun Jan 29 23:56:17 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Sun, 29 Jan 2023 23:56:17 GMT
Subject: RFR: 8301043: Super-interface for PrintStream and PrintWriter [v2]
In-Reply-To: <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>
References: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>
 <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>
Message-ID: <jjtERiHCJ4iaLJwaW8bOjZVLE4uJiyykE3BKny1mBGw=.cbf5f7be-8fab-4d50-94a5-17bfd72d49f0@github.com>

On Sun, 29 Jan 2023 07:11:26 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Add `java.io.PrintOutput` to represent print operations, and modify `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix grammar mistakes in the doc

I cannot create a CSR request because I don't have write access to the JBS.  The [issue](https://bugs.openjdk.org/browse/JDK-8301043) is not open either.

I'm converting this PR to draft until the issue is open and someone helps me to create a CSR request.  I will close it if you think this PR should never be integrated.

Thanks for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12277

From duke at openjdk.org  Mon Jan 30 02:17:17 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 30 Jan 2023 02:17:17 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v4]
In-Reply-To: <Vx28T_kz1S269a338ZKHml6BsD2PSys4n_3InHizsEI=.6fa9ef82-7a95-467b-bd05-4217548eed9e@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
 <Vx28T_kz1S269a338ZKHml6BsD2PSys4n_3InHizsEI=.6fa9ef82-7a95-467b-bd05-4217548eed9e@github.com>
Message-ID: <rMhQh1ZbPPJsRfTzvHS6lNsuml6zgVyFzTc-yeBCi8M=.89bf5724-b1e4-49ca-a833-a4e99b56c593@github.com>

On Sat, 28 Jan 2023 19:54:32 GMT, Glavo <duke at openjdk.org> wrote:

>> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>> 
>> 
>>     /**
>>      * Constructs a new {@code String} by decoding the specified subarray of
>>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>>      *
>>      * The caller of this method shall relinquish and transfer the ownership of
>>      * the byte array to the callee since the later will not make a copy.
>>      *
>>      * @param bytes the byte array source
>>      * @param cs the Charset
>>      * @return the newly created string
>>      * @throws CharacterCodingException for malformed or unmappable bytes
>>      */
>> 
>> 
>> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
>> 
>> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
>> 
>> This PR fixes this problem.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Benchmark results for large files (128KiB~256MiB) on the default file system:

![image](https://user-images.githubusercontent.com/20694662/215372915-2988bb4e-8c35-4def-9fe9-a6bc4f033708.png)

![image](https://user-images.githubusercontent.com/20694662/215372925-2a7995dc-00f4-4a91-9b2a-e73c97192008.png)

For files of about 1MiB, the throughput can be improved by more than 55%.

Original results: https://gist.github.com/Glavo/f3d2060d0bd13cd0ce2add70e6060ea0?permalink_comment_id=4452798#gistcomment-4452798

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Mon Jan 30 02:55:24 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 30 Jan 2023 02:55:24 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
Message-ID: <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>

> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
> 
> Their return values can be trusted, so many unnecessary array duplication can be eliminated.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Add trusted collection list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12212/files
  - new: https://git.openjdk.org/jdk/pull/12212/files/aecd79ff..8c2caca6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12212&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12212&range=01-02

  Stats: 61 lines in 1 file changed: 56 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12212.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12212/head:pull/12212

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Mon Jan 30 03:00:19 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 30 Jan 2023 03:00:19 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
Message-ID: <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>

On Mon, 30 Jan 2023 02:55:24 GMT, Glavo <duke at openjdk.org> wrote:

>> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
>> 
>> Their return values can be trusted, so many unnecessary array duplication can be eliminated.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add trusted collection list

src/java.base/share/classes/java/util/Collections.java line 5838:

> 5836:     }
> 5837: 
> 5838:     private static final Set<String> trustedCollections = Set.of(

Why not use set of classes?

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Mon Jan 30 03:05:16 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 30 Jan 2023 03:05:16 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
 <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>
Message-ID: <b5h9X-XLcRtSKe_XVwh3TgNy7QKkRzFr0Hw21BUYTi8=.435384d3-4656-4bac-aaf1-b1a899a3fb15@github.com>

On Mon, 30 Jan 2023 02:57:52 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Why not use set of classes?

Because some classes are not visible here (such as `Arrays.ArrayList`). 

I'm not sure what the best choice is, so I'm trying to explore the implementation plan.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From cwimmer at openjdk.org  Mon Jan 30 03:12:19 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 30 Jan 2023 03:12:19 GMT
Subject: RFR: JDK-8262994: Refactor String.split to help method inlining
 [v2]
In-Reply-To: <YqQ7Hhi61ORhRgZw5nisy3dfzJ9_qTVbZyVqMIF7n0U=.17b2eeec-e80b-4128-8769-503da4cc0620@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
 <tAWd2EORxFPPMHapksTBcqxu3K5SLKiiUfcspG3wX4Y=.6f2a4608-9f2e-419f-85a4-282c1a7f37cb@github.com>
 <YqQ7Hhi61ORhRgZw5nisy3dfzJ9_qTVbZyVqMIF7n0U=.17b2eeec-e80b-4128-8769-503da4cc0620@github.com>
Message-ID: <lzQPgLALxD5FMwRXWFmxfVlQlyJTJnxMhR_p6w5W6LY=.0222571b-3027-4d70-9979-27c1bf571745@github.com>

On Sun, 29 Jan 2023 16:07:08 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Christian Wimmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about method inlining
>
> Hi Christian, I can sponsor to pull this change if you like.

@plevart  yes please sponsor

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From duke at openjdk.org  Mon Jan 30 03:16:16 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 30 Jan 2023 03:16:16 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <b5h9X-XLcRtSKe_XVwh3TgNy7QKkRzFr0Hw21BUYTi8=.435384d3-4656-4bac-aaf1-b1a899a3fb15@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
 <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>
 <b5h9X-XLcRtSKe_XVwh3TgNy7QKkRzFr0Hw21BUYTi8=.435384d3-4656-4bac-aaf1-b1a899a3fb15@github.com>
Message-ID: <Tb8_AEbBDXOtiEQ3stEWS_3mG0wv-sGgquIg6PhEQiY=.276c316f-833d-43aa-8f6e-5477ec0855eb@github.com>

On Mon, 30 Jan 2023 03:02:33 GMT, Glavo <duke at openjdk.org> wrote:

> > Why not use set of classes?
> 
> Because some classes are not visible here (such as `Arrays.ArrayList`).
> 
> I'm not sure what the best choice is, so I'm trying to explore the implementation plan.

Only `Arrays.ArrayList` is not visible here.  You can change it into package-private.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From duke at openjdk.org  Mon Jan 30 03:16:17 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 30 Jan 2023 03:16:17 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <Tb8_AEbBDXOtiEQ3stEWS_3mG0wv-sGgquIg6PhEQiY=.276c316f-833d-43aa-8f6e-5477ec0855eb@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
 <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>
 <b5h9X-XLcRtSKe_XVwh3TgNy7QKkRzFr0Hw21BUYTi8=.435384d3-4656-4bac-aaf1-b1a899a3fb15@github.com>
 <Tb8_AEbBDXOtiEQ3stEWS_3mG0wv-sGgquIg6PhEQiY=.276c316f-833d-43aa-8f6e-5477ec0855eb@github.com>
Message-ID: <0dRAGAS3vCAyRTvj_20L56QJVbMmMSu1dwy00zT61HE=.4558906d-22a3-4541-ae35-eb6d8166723c@github.com>

On Mon, 30 Jan 2023 03:09:53 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>>> Why not use set of classes?
>> 
>> Because some classes are not visible here (such as `Arrays.ArrayList`). 
>> 
>> I'm not sure what the best choice is, so I'm trying to explore the implementation plan.
>
>> > Why not use set of classes?
>> 
>> Because some classes are not visible here (such as `Arrays.ArrayList`).
>> 
>> I'm not sure what the best choice is, so I'm trying to explore the implementation plan.
> 
> Only `Arrays.ArrayList` is not visible here.  You can change it into package-private.

> > > Why not use set of classes?
> > 
> > 
> > Because some classes are not visible here (such as `Arrays.ArrayList`).
> > I'm not sure what the best choice is, so I'm trying to explore the implementation plan.
> 
> Only `Arrays.ArrayList` is not visible here. You can change it to package-private.

Another problem is that use set of classes may cause unnecessary classes to be loaded, which has a negative impact on startup speed. I want to do some tests in the next few days.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From xgong at openjdk.org  Mon Jan 30 03:29:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 30 Jan 2023 03:29:16 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <2qVUjzI54duZendHLzYBgzMfXTts5E_ehYabh38Du8o=.267353cc-b74c-4aec-8ba2-c55e5e2ca4f4@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

Hi @PaulSandoz , @jatin-bhateja, @sviswa7, could you please help to take a look at this optimization? Any feedback is welcome. Thanks in advance!

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From david.holmes at oracle.com  Mon Jan 30 07:50:18 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jan 2023 17:50:18 +1000
Subject: Circular initialization between EmptyNavigableMap and
 UnmodifiableNavigableMap
In-Reply-To: <CAE+3fjaWjKeAEeroGieaXvb5Gg2t80-2oTHZzHvW6A8b9yEyTA@mail.gmail.com>
References: <CAE+3fjaWjKeAEeroGieaXvb5Gg2t80-2oTHZzHvW6A8b9yEyTA@mail.gmail.com>
Message-ID: <c7658667-b0fc-4f7e-4f6c-f3e346b2ca24@oracle.com>

On 26/01/2023 7:49 pm, Tagir Valeev wrote:
> Hello!
> 
> Not sure if this should be considered as a problem that requires
> attention but there's an initialization loop between

There are probably still quite a number of "initialization loops" in the 
core libraries. But they can only trigger if you explicitly load and 
initialize internal implementation classes. So no, this is not generally 
considered a problem.

Cheers,
David

> java.util.Collections$UnmodifiableNavigableMap and
> java.util.Collections$UnmodifiableNavigableMap$EmptyNavigableMap
> classes. E.g., the following program may stuck in a classloader
> deadlock (happens to me in ~30% of launches):
> 
> import static java.util.concurrent.CompletableFuture.supplyAsync;
> 
> public class Test {
> public static void main(String[] args) {
> var future1 = supplyAsync(() ->
> loadClass("java.util.Collections$UnmodifiableNavigableMap$EmptyNavigableMap"));
> var future2 = supplyAsync(() ->
> loadClass("java.util.Collections$UnmodifiableNavigableMap"));
> System.out.println(future1.join()+":"+future2.join());
> }
> 
> private static Class<?> loadClass(String className) {
> try {
> return Class.forName(className);
> } catch (ClassNotFoundException e) {
> throw new RuntimeException(e);
> }
> }
> }
> 
> This is due to the EMPTY_NAVIGABLE_MAP which is declared in
> UnmodifiableNavigableMap but its type is a subclass of
> UnmodifiableNavigableMap. Moving the field inside EmptyNavigableMap
> will likely solve the problem. On the other hand, I was not able to
> reproduce the problem without explicit Class.forName call, and given
> that EmptyNavigableMap class is an implementation detail, we probably
> can ignore this.
> 
> With best regards,
> Tagir Valeev.

From david.holmes at oracle.com  Mon Jan 30 07:58:31 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jan 2023 17:58:31 +1000
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>
Message-ID: <72761254-4b55-0212-30a5-c73a9ec67cbc@oracle.com>



On 30/01/2023 3:37 am, Glavo wrote:
> I quite agree with you. I think the collection framework is in a very 
> puzzling state.
> 
> The hostility of the new collection factory method introduced by Java 9 
> to null has brought us trouble.
> I can understand that this is to expect users to explicitly declare that 
> the elements of the list cannot be null, rather than in an ambiguous state.
> However, this makes migration more difficult, and the cost of scanning 
> all elements to ensure that they are not null is also unpleasant.
> I hope to provide an additional set of factory methods for the 
> collection to accept nullable elements.
> 
> In addition, it is also confusing to share the same interface between 
> mutable collections and immutable?collections?.
> Before encountering UnsupportedOperationException, we can't even know 
> what operations a collection supports.
> This problem has existed for a long time, but no solution has been given.

There is no "solution" because it is not a "problem" it is a design 
decision:

https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html

You might not like it, or agree with it, but it is what it is.

Cheers,
David

> 
> On Sun, Jan 29, 2023 at 11:28 PM John Hendrikx <john.hendrikx at gmail.com 
> <mailto:john.hendrikx at gmail.com>> wrote:
> 
>     TLDR; why does contains(null) not just return false for collections
>     that
>     don't allow nulls. Just because the interface allows it, does not mean
>     it should do it as it devalues the usefulness of the abstraction
>     provided by the interface.
> 
>     Background:
> 
>     I'm someone that likes to check correctness of any constructor or
>     method
>     parameter before allowing an object to be constructed or to be
>     modified,
>     in order to maintain invariants that are provided by the class to
>     its users.
> 
>     This ranges from simple null checks, to range checks on numeric values,
>     to complete checks like "is a collection sorted" or is a list of nodes
>     acyclic. Anything I can check in the constructor that may avoid
>     problems
>     further down the line or that may affect what I can guarantee on its
>     own
>     API methods.? For example, if I check in the constructor that something
>     is not null, then the associated getter will guarantee that the
>     returned
>     value is not null.? If I check that a List doesn't contain nulls, then
>     the associated getter will reflect that as well (assuming it is
>     immutable or defensivily copied).
> 
>     For collections, this is currently becoming harder and harder because
>     more and more new collections are written to be null hostile.? It is
>     fine if a collection doesn't accept nulls, but throwing NPE when I ask
>     such a collection if it contains null seems to be counter productive,
>     and reduces the usefulness of the collection interfaces.
> 
>     This strict interpretation makes the collection interfaces harder to
>     use
>     than necessary. Interfaces are only useful when their contract is well
>     defined. The more things an interface allows or leaves unspecified, the
>     less useful it is for its users.
> 
>     I know that the collection interfaces allow this, but you have to ask
>     yourself this important question: how useful is an interface that makes
>     almost no guarantees about what its methods will do? Interfaces like
>     `List`, `Map` and `Set` are passed as method parameters a lot, and to
>     make these useful, implementations of these interfaces should do their
>     best to provide as consistent an experience as is reasonably possible.
>     The alternative is that these interfaces will slowly decline in
>     usefulness as methods will start asking for `ArrayList` instead of
>     `List` to avoid having to deal with a too lenient specification.
> 
>     With the collection interfaces I get the impression that recently there
>     has been too much focus on what would be easy for the collection
>     implementation instead of what would be easy for the users of said
>     interfaces. In my opinion, the concerns of the user of interfaces
>     almost
>     always far outweigh the concerns of the implementors of said interfaces.
> 
>     In the past, immutable collections were rare, but they get are getting
>     more and more common all the time.? For example, in unit testing.
>     Unfortunately, these immutable collections differ quite a bit from
>     their
>     mutable counterparts.? Some parts are only midly annoying (not
>     accepting
>     `null` as the **value** in a `Map` for example), but other parts
>     require
>     code to be rewritten for it to be able to work as a drop-in replacement
>     for the mutable variant. A simple example is this:
> 
>      ???? public void addShoppingItems(Collection<String> shoppingItems) {
>      ???????? if (shoppingItems.contains(null)) {? // this looks quite
>     reasonable and safe...
>      ???????????? throw new IllegalArgumentException("shoppingItems should
>     not contain nulls");
>      ???????? }
> 
>      ???????? this.shoppingItems.addAll(shoppingItems);
>      ???? }
> 
>     Testing this code is annoying:
> 
>      ????? x.addShoppingItems(List.of("a", null"));?? // can't construct
>     immutable collection with null
> 
>      ????? x.addShoppingItems(Arrays.asList("a", null"));? // fine, go back
>     to what we did before then...
> 
>     The above problems, I suppose we can live with it; immutable
>     collections
>     don't want `null` although I don't see any reason to not allow it as I
>     can write a similar `List.of` that returns immutable collections
>     that do
>     allow `null`. For JDK code this is a bit disconcerting, as it is
>     supposed to be as flexible as is reasonable without having too much of
>     an opinion about what is good or bad.
> 
>     This next one however:
> 
>      ??? ? assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a",
>     "b")));? // not allowed, contains(null) in application code throws NPE
> 
>     This is much more insidious; the `contains(null)` check has been a very
>     practical way to check if collections contain null, and this works for
>     almost all collections in common use, so there is no problem.? But now,
>     more and more collections are starting to just throw NPE immediately
>     even just to **check** if a null element is present. This only
>     serves to
>     distinguish themselves loudly from other similar collections that will
>     simply return `false`.
> 
>     I think this behavior is detrimental to the java collection interfaces
>     in general, especially since there is a clear answer to the question if
>     such a collection contains null or not. In fact, why `contains` was
>     ever
>     allowed to throw an exception aside from
>     "UnsupportedOperationException"
>     is a mystery to me, and throwing one when one could just as easily
>     return the correct and expected answer seems very opiniated and almost
>     malicious -- not behavior I'd expect from JDK core libraries.
> 
>     Also note that there is no way to know in advance if
>     `contains(null)` is
>     going to be throwing the NPE. If interfaces had a method
>     `allowsNulls()`
>     that would already be an improvement.
> 
>     --John
> 
> 

From duke at openjdk.org  Mon Jan 30 08:11:03 2023
From: duke at openjdk.org (Amit Kumar)
Date: Mon, 30 Jan 2023 08:11:03 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
Message-ID: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>

DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

-------------

Commit messages:
 - fixes test failure for s390

Changes: https://git.openjdk.org/jdk/pull/12283/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12283&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299748
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12283.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12283/head:pull/12283

PR: https://git.openjdk.org/jdk/pull/12283

From mbaesken at openjdk.org  Mon Jan 30 08:18:24 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Jan 2023 08:18:24 GMT
Subject: Integrated: JDK-8301163: jdk/internal/vm/Continuation/Fuzz.java
 increase COMPILATION_TIMEOUT for Linux ppc64le
In-Reply-To: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
References: <TVlu9UlT3iUG3onOb11se5eisqJqU-TL7IY-UaN-srE=.e76a0252-990a-41e1-9278-0ec6de799235@github.com>
Message-ID: <v1p09_lwnqJFB_AjtTPZwm_1BhUEEjbbAyLJfBmC1Pg=.840b126d-c543-439d-bfa2-73faf70f2bee@github.com>

On Fri, 27 Jan 2023 08:33:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On our Linux ppc64le test machines we quite often see compilation timeouts in the test jdk/internal/vm/Continuation/Fuzz.java.
> (especially when running with fastdebug binaries)
> So it probably makes sense to use a higher compilation timeout (maybe factor 2) on this platform.

This pull request has now been integrated.

Changeset: cbefe1fd
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbefe1fd35a4ad59ec979bdaee519617efac9ecf
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8301163: jdk/internal/vm/Continuation/Fuzz.java increase COMPILATION_TIMEOUT for Linux ppc64le

Reviewed-by: rrich

-------------

PR: https://git.openjdk.org/jdk/pull/12244

From jpai at openjdk.org  Mon Jan 30 08:22:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jan 2023 08:22:17 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <shVacO8KR01NARAaRdWEg6aMajdDGWJudMbAUyXeOF4=.5edc01ae-13a5-44a6-9954-a682dddf41fe@github.com>

On Mon, 30 Jan 2023 08:03:38 GMT, Amit Kumar <duke at openjdk.org> wrote:

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

Hello Amit, either here or in the JBS, would you be able to include the original exception stacktrace and failure that you notice without this change?

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From jpai at openjdk.org  Mon Jan 30 08:27:16 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jan 2023 08:27:16 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>

On Mon, 30 Jan 2023 08:03:38 GMT, Amit Kumar <duke at openjdk.org> wrote:

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

Additionally, on this system where this is failing, is the OS's zlib being used or is the JDK that is being tested have the zlib bundled within itself?

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From duke at openjdk.org  Mon Jan 30 08:41:16 2023
From: duke at openjdk.org (Amit Kumar)
Date: Mon, 30 Jan 2023 08:41:16 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>
Message-ID: <n9yyttjOa9MR3Q2sqNd4qlyiQBof4NdFFbeH5U6Ll1k=.88010c9d-59cd-47ee-8bab-e85c48453cf4@github.com>

On Mon, 30 Jan 2023 08:24:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Additionally, on this system where this is failing, is the OS's zlib being used or is the JDK that is being tested have the zlib bundled within itself?

Hi @jaikiran ,
On my system OS's zlib is being used. and here is stack-trace.

----------System.out:(2/78)----------
level:-1, strategy: 0, dowrap: false
m=525312, n=498060, len=524288, eq=false
----------System.err:(11/585)----------
java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
    at DeInflate.check(DeInflate.java:141)
    at DeInflate.main(DeInflate.java:290)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
    at java.base/java.lang.Thread.run(Thread.java:1623)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579

test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From pminborg at openjdk.org  Mon Jan 30 08:44:32 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 30 Jan 2023 08:44:32 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
Message-ID: <zuFvcomZE_5IcTlrRO7ZJUP8xntWg_hpB7XSRaod7tk=.28a214b2-330a-4867-bb1c-1bd816561d00@github.com>

On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk <duke at openjdk.org> wrote:

> java.time.ZoneOffset

Maybe I am blind but can you provide a direct reference to an exising JDK method in `java.time` where we can apply similar optimizations?

-------------

PR: https://git.openjdk.org/jdk/pull/11840

From duke at openjdk.org  Mon Jan 30 09:02:32 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Mon, 30 Jan 2023 09:02:32 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]
In-Reply-To: <zuFvcomZE_5IcTlrRO7ZJUP8xntWg_hpB7XSRaod7tk=.28a214b2-330a-4867-bb1c-1bd816561d00@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <8sAs67UpxNzQMAVJdjcF9rl_yc-cwTzW5FvkiywbcKs=.f08bbd9c-2497-4b86-a23e-f400a4d42417@github.com>
 <zV2Ouj7-LVf8-Rlj3AlwwaOs1AdHYmvNIfl4Risu7co=.e4561b6f-797e-4488-a075-fd0c38ffb089@github.com>
 <F_vEaZlUxQirfK0sF2X3_GV52pf09rjJ_MXoFJ4t3GM=.892af2e2-b6ec-439a-8db5-95c3ebfbb6c2@github.com>
 <j-3qMc5hKaLu3Qv91lOuHDYHSVChDAgTV5AEBXeqSOw=.3122c55a-c5a1-461d-b5d8-6a961f71895d@github.com>
 <6wXWYPWHVU-A9WkczvoDwVm-Ezo0-eBsR9RVLv_2N4M=.d53478ed-d7b9-41df-980f-1f26c67a78bf@github.com>
 <zuFvcomZE_5IcTlrRO7ZJUP8xntWg_hpB7XSRaod7tk=.28a214b2-330a-4867-bb1c-1bd816561d00@github.com>
Message-ID: <5-XOpKDl1nLEQHy-PA6YT0F9NUbCFIKk4QT0jNrVtGE=.5488e0dc-dd2a-48c3-894b-2d6d849b33c3@github.com>

On Mon, 30 Jan 2023 08:41:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > java.time.ZoneOffset
> 
> Maybe I am blind but can you provide a direct reference to an exising JDK method in `java.time` where we can apply similar optimizations?

No problem! We can start from `java.time.ZoneOffset` and its `parse` and `toString` methods.

-------------

PR: https://git.openjdk.org/jdk/pull/11840

From zjx001202 at gmail.com  Mon Jan 30 09:11:01 2023
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 30 Jan 2023 17:11:01 +0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <72761254-4b55-0212-30a5-c73a9ec67cbc@oracle.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>
 <72761254-4b55-0212-30a5-c73a9ec67cbc@oracle.com>
Message-ID: <CAJL5A3nnTWnj1-OnP-yB3_zmVGWaUwcOZSyKCnQ_s1nk_QQbrw@mail.gmail.com>

Thank you for your reply, which explains why there are so few interfaces in
the collection framework.
But I think it still doesn't answer my question: Why doesn't it provide a
means to judge the features supported by the collection?

Now that we have the interface default method, can we add a new method to
the Collection to obtain the support status of the feature, like this:

public record CollectionFeature(String name) {
    public enum Status {
        SUPPORTED, UNSUPPORTED, UNKNOWN
    }
}

public interface Collection<E> extends Iterable<E> {
    CollectionFeature ADD_ELEMENT = new CollectionFeature("ADD_ELEMENT");

    // ...

    default CollectionFeature.Status supports(CollectionFeature feature) {
        return UNKNOWN;
    }
}

public interface List<E> extends Collection<E> {
    CollectionFeature RANDOM_ACCESS = new CollectionFeature("RANDOM_ACCESS");
    CollectionFeature UPDATE_ELEMENT = new CollectionFeature("UPDATE_ELEMENT");

    // ...

    @Override
    default CollectionFeature.Status supports(CollectionFeature feature) {
        if (feature == RANDOM_ACCESS)
            return this instanceof RandomAccess ? SUPPORTED : UNSUPPORTED;
        else
            return UNKNOWN;
    }
}


Is there anything preventing us from doing this? Or "users should not know
what features a collection object supports" is also part of the design?

On Mon, Jan 30, 2023 at 3:58 PM David Holmes <david.holmes at oracle.com>
wrote:

>
>
> On 30/01/2023 3:37 am, Glavo wrote:
> > I quite agree with you. I think the collection framework is in a very
> > puzzling state.
> >
> > The hostility of the new collection factory method introduced by Java 9
> > to null has brought us trouble.
> > I can understand that this is to expect users to explicitly declare that
> > the elements of the list cannot be null, rather than in an ambiguous
> state.
> > However, this makes migration more difficult, and the cost of scanning
> > all elements to ensure that they are not null is also unpleasant.
> > I hope to provide an additional set of factory methods for the
> > collection to accept nullable elements.
> >
> > In addition, it is also confusing to share the same interface between
> > mutable collections and immutable collections .
> > Before encountering UnsupportedOperationException, we can't even know
> > what operations a collection supports.
> > This problem has existed for a long time, but no solution has been given.
>
> There is no "solution" because it is not a "problem" it is a design
> decision:
>
>
> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html
>
> You might not like it, or agree with it, but it is what it is.
>
> Cheers,
> David
>
> >
> > On Sun, Jan 29, 2023 at 11:28 PM John Hendrikx <john.hendrikx at gmail.com
> > <mailto:john.hendrikx at gmail.com>> wrote:
> >
> >     TLDR; why does contains(null) not just return false for collections
> >     that
> >     don't allow nulls. Just because the interface allows it, does not
> mean
> >     it should do it as it devalues the usefulness of the abstraction
> >     provided by the interface.
> >
> >     Background:
> >
> >     I'm someone that likes to check correctness of any constructor or
> >     method
> >     parameter before allowing an object to be constructed or to be
> >     modified,
> >     in order to maintain invariants that are provided by the class to
> >     its users.
> >
> >     This ranges from simple null checks, to range checks on numeric
> values,
> >     to complete checks like "is a collection sorted" or is a list of
> nodes
> >     acyclic. Anything I can check in the constructor that may avoid
> >     problems
> >     further down the line or that may affect what I can guarantee on its
> >     own
> >     API methods.  For example, if I check in the constructor that
> something
> >     is not null, then the associated getter will guarantee that the
> >     returned
> >     value is not null.  If I check that a List doesn't contain nulls,
> then
> >     the associated getter will reflect that as well (assuming it is
> >     immutable or defensivily copied).
> >
> >     For collections, this is currently becoming harder and harder because
> >     more and more new collections are written to be null hostile.  It is
> >     fine if a collection doesn't accept nulls, but throwing NPE when I
> ask
> >     such a collection if it contains null seems to be counter productive,
> >     and reduces the usefulness of the collection interfaces.
> >
> >     This strict interpretation makes the collection interfaces harder to
> >     use
> >     than necessary. Interfaces are only useful when their contract is
> well
> >     defined. The more things an interface allows or leaves unspecified,
> the
> >     less useful it is for its users.
> >
> >     I know that the collection interfaces allow this, but you have to ask
> >     yourself this important question: how useful is an interface that
> makes
> >     almost no guarantees about what its methods will do? Interfaces like
> >     `List`, `Map` and `Set` are passed as method parameters a lot, and to
> >     make these useful, implementations of these interfaces should do
> their
> >     best to provide as consistent an experience as is reasonably
> possible.
> >     The alternative is that these interfaces will slowly decline in
> >     usefulness as methods will start asking for `ArrayList` instead of
> >     `List` to avoid having to deal with a too lenient specification.
> >
> >     With the collection interfaces I get the impression that recently
> there
> >     has been too much focus on what would be easy for the collection
> >     implementation instead of what would be easy for the users of said
> >     interfaces. In my opinion, the concerns of the user of interfaces
> >     almost
> >     always far outweigh the concerns of the implementors of said
> interfaces.
> >
> >     In the past, immutable collections were rare, but they get are
> getting
> >     more and more common all the time.  For example, in unit testing.
> >     Unfortunately, these immutable collections differ quite a bit from
> >     their
> >     mutable counterparts.  Some parts are only midly annoying (not
> >     accepting
> >     `null` as the **value** in a `Map` for example), but other parts
> >     require
> >     code to be rewritten for it to be able to work as a drop-in
> replacement
> >     for the mutable variant. A simple example is this:
> >
> >           public void addShoppingItems(Collection<String> shoppingItems)
> {
> >               if (shoppingItems.contains(null)) {  // this looks quite
> >     reasonable and safe...
> >                   throw new IllegalArgumentException("shoppingItems
> should
> >     not contain nulls");
> >               }
> >
> >               this.shoppingItems.addAll(shoppingItems);
> >           }
> >
> >     Testing this code is annoying:
> >
> >            x.addShoppingItems(List.of("a", null"));   // can't construct
> >     immutable collection with null
> >
> >            x.addShoppingItems(Arrays.asList("a", null"));  // fine, go
> back
> >     to what we did before then...
> >
> >     The above problems, I suppose we can live with it; immutable
> >     collections
> >     don't want `null` although I don't see any reason to not allow it as
> I
> >     can write a similar `List.of` that returns immutable collections
> >     that do
> >     allow `null`. For JDK code this is a bit disconcerting, as it is
> >     supposed to be as flexible as is reasonable without having too much
> of
> >     an opinion about what is good or bad.
> >
> >     This next one however:
> >
> >            assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a",
> >     "b")));  // not allowed, contains(null) in application code throws
> NPE
> >
> >     This is much more insidious; the `contains(null)` check has been a
> very
> >     practical way to check if collections contain null, and this works
> for
> >     almost all collections in common use, so there is no problem.  But
> now,
> >     more and more collections are starting to just throw NPE immediately
> >     even just to **check** if a null element is present. This only
> >     serves to
> >     distinguish themselves loudly from other similar collections that
> will
> >     simply return `false`.
> >
> >     I think this behavior is detrimental to the java collection
> interfaces
> >     in general, especially since there is a clear answer to the question
> if
> >     such a collection contains null or not. In fact, why `contains` was
> >     ever
> >     allowed to throw an exception aside from
> >     "UnsupportedOperationException"
> >     is a mystery to me, and throwing one when one could just as easily
> >     return the correct and expected answer seems very opiniated and
> almost
> >     malicious -- not behavior I'd expect from JDK core libraries.
> >
> >     Also note that there is no way to know in advance if
> >     `contains(null)` is
> >     going to be throwing the NPE. If interfaces had a method
> >     `allowsNulls()`
> >     that would already be an improvement.
> >
> >     --John
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230130/e74ac7e9/attachment-0001.htm>

From kasperni at gmail.com  Mon Jan 30 10:23:34 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 30 Jan 2023 10:23:34 +0000
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <CAJL5A3nnTWnj1-OnP-yB3_zmVGWaUwcOZSyKCnQ_s1nk_QQbrw@mail.gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>
 <72761254-4b55-0212-30a5-c73a9ec67cbc@oracle.com>
 <CAJL5A3nnTWnj1-OnP-yB3_zmVGWaUwcOZSyKCnQ_s1nk_QQbrw@mail.gmail.com>
Message-ID: <CAPs6153AUPuAtSduL2yrheb0gm0ErgX9Kaqc25-tEWYpbfh1jw@mail.gmail.com>

On Mon, 30 Jan 2023 at 09:11, Glavo <zjx001202 at gmail.com> wrote:
> Now that we have the interface default method, can we add a new method to the Collection to obtain the support status of the feature, like this:
>
> public record CollectionFeature(String name) {
>     public enum Status {
>         SUPPORTED, UNSUPPORTED, UNKNOWN
>     }
> }
>
> public interface Collection<E> extends Iterable<E> {
>     CollectionFeature ADD_ELEMENT = new CollectionFeature("ADD_ELEMENT");
>
>     // ...
>
>     default CollectionFeature.Status supports(CollectionFeature feature) {
>         return UNKNOWN;
>     }
> }
>
> public interface List<E> extends Collection<E> {
>     CollectionFeature RANDOM_ACCESS = new CollectionFeature("RANDOM_ACCESS");
>     CollectionFeature UPDATE_ELEMENT = new CollectionFeature("UPDATE_ELEMENT");
>
>     // ...
>
>     @Override
>     default CollectionFeature.Status supports(CollectionFeature feature) {
>         if (feature == RANDOM_ACCESS)
>             return this instanceof RandomAccess ? SUPPORTED : UNSUPPORTED;
>         else
>             return UNKNOWN;
>     }
> }
>
>
> Is there anything preventing us from doing this?

Not anything other than this is a solution looking for a problem.

What are you going to do with this information at runtime? Not insert the
element in a collection if it doesn't support Update? In 99% of all cases,
this is a failure scenario, and you will want to throw an exception. Which
Collection#add() will do for you by throwing an
UnsupportedOperationException.

RandomAccess you can check by instanceof java.util.RandomAccess

And best you could use such a feature for debugging. Instead, just print out
the class name and go read the Javadocs for the class.

And if you are going to support this for Collection, people also want this for
queues, map, sets, etc. Further complicating a Collection API that is already
complex enough.

/Kasper

From djelinski at openjdk.org  Mon Jan 30 11:48:01 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jan 2023 11:48:01 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
Message-ID: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>

Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.

This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.

The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

-------------

Commit messages:
 - Reduce socket timeout

Changes: https://git.openjdk.org/jdk/pull/12292/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12292&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301214
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12292.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12292/head:pull/12292

PR: https://git.openjdk.org/jdk/pull/12292

From zjx001202 at gmail.com  Mon Jan 30 11:56:22 2023
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 30 Jan 2023 19:56:22 +0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <CAPs6153AUPuAtSduL2yrheb0gm0ErgX9Kaqc25-tEWYpbfh1jw@mail.gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <CAJL5A3n2qBzBfsmGEKzJiASczgMVDHSRhLxGxSDXS7d4g6etfA@mail.gmail.com>
 <72761254-4b55-0212-30a5-c73a9ec67cbc@oracle.com>
 <CAJL5A3nnTWnj1-OnP-yB3_zmVGWaUwcOZSyKCnQ_s1nk_QQbrw@mail.gmail.com>
 <CAPs6153AUPuAtSduL2yrheb0gm0ErgX9Kaqc25-tEWYpbfh1jw@mail.gmail.com>
Message-ID: <CAJL5A3k-1sQpjJsk5FNedccuqeFtb8Fg4p-LQ+taafuEEvYQ9w@mail.gmail.com>

One of the meanings is debug.

Now it is even difficult to detect whether a list has these features
through assertions.
We want to see exceptions, but when we actually call unsupported methods,
the wrong object
may have been propagated to other methods or even threads, so that we can't
see the problematic method on the stack frame.

Secondly, understanding the characteristics of the collection can help us
optimize.
Although "Premature Optimization Is the Root of All Evil", stupid defensive
replication is everywhere and is not what I want to see.

RandomAccess you can check by instanceof java.util.RandomAccess
>

I think that using interfaces to express the characteristics of collection
support is an ancient design left over for historical reasons, right?

Is there any difference between the operations supported by
Collections.UnmodifiableList and Collections.UnmodifiableRandomAccessList?
If we use a method to express these characteristics, we just need to
delegate the method to the original collection.
However, because RandomAccess is an interface, we have to create two
classes, even if they are not different.

It also eliminates the possibility of creating other similar interfaces,
because the number of collection wrappers will grow exponentially.
Expose more characteristics (e.g., whether to support efficient insertion
into the head) to help optimize the collection util methods in the
third-party library.

And if you are going to support this for Collection, people also want this
> for
> queues, map, sets, etc. Further complicating a Collection API that is
> already
> complex enough.
>

Shouldn't they be supported?

I don't think the Java collection framework is complex enough, nor do I
think adding such a method will significantly increase complexity.

On Mon, Jan 30, 2023 at 6:23 PM Kasper Nielsen <kasperni at gmail.com> wrote:

> On Mon, 30 Jan 2023 at 09:11, Glavo <zjx001202 at gmail.com> wrote:
> > Now that we have the interface default method, can we add a new method
> to the Collection to obtain the support status of the feature, like this:
> >
> > public record CollectionFeature(String name) {
> >     public enum Status {
> >         SUPPORTED, UNSUPPORTED, UNKNOWN
> >     }
> > }
> >
> > public interface Collection<E> extends Iterable<E> {
> >     CollectionFeature ADD_ELEMENT = new CollectionFeature("ADD_ELEMENT");
> >
> >     // ...
> >
> >     default CollectionFeature.Status supports(CollectionFeature feature)
> {
> >         return UNKNOWN;
> >     }
> > }
> >
> > public interface List<E> extends Collection<E> {
> >     CollectionFeature RANDOM_ACCESS = new
> CollectionFeature("RANDOM_ACCESS");
> >     CollectionFeature UPDATE_ELEMENT = new
> CollectionFeature("UPDATE_ELEMENT");
> >
> >     // ...
> >
> >     @Override
> >     default CollectionFeature.Status supports(CollectionFeature feature)
> {
> >         if (feature == RANDOM_ACCESS)
> >             return this instanceof RandomAccess ? SUPPORTED :
> UNSUPPORTED;
> >         else
> >             return UNKNOWN;
> >     }
> > }
> >
> >
> > Is there anything preventing us from doing this?
>
> Not anything other than this is a solution looking for a problem.
>
> What are you going to do with this information at runtime? Not insert the
> element in a collection if it doesn't support Update? In 99% of all cases,
> this is a failure scenario, and you will want to throw an exception. Which
> Collection#add() will do for you by throwing an
> UnsupportedOperationException.
>
> RandomAccess you can check by instanceof java.util.RandomAccess
>
> And best you could use such a feature for debugging. Instead, just print
> out
> the class name and go read the Javadocs for the class.
>
> And if you are going to support this for Collection, people also want this
> for
> queues, map, sets, etc. Further complicating a Collection API that is
> already
> complex enough.
>
> /Kasper
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230130/eb7bd629/attachment-0001.htm>

From eirbjo at gmail.com  Mon Jan 30 12:01:55 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 30 Jan 2023 13:01:55 +0100
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
 <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
 <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>
 <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
Message-ID: <CA+pBWhuWQi4k2HcBHdw6CHFPtZWd+uFOWZB-QggUyvOvNnB1Tw@mail.gmail.com>

On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen <lance.andersen at oracle.com>
wrote:

> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).
>

Consensus seems to be we leave the existing manual test alone. I've updated
the PR to leave the existing test as-is, and instead added the
CenSizeTooLarge test which runs fast and automatic.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230130/0c08494b/attachment.htm>

From vtewari at openjdk.org  Mon Jan 30 12:57:16 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 30 Jan 2023 12:57:16 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
In-Reply-To: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
Message-ID: <ETtgqQlFiQyp7C4zKNL2Gw-2mg0YPdNLyGhU3Zqqmec=.630667bd-211a-4e33-be40-3ab661acc3e7@github.com>

On Mon, 30 Jan 2023 11:06:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
> 
> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
> 
> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

test/jdk/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java line 59:

> 57:     public static void main(String[] args) throws Exception {
> 58: 
> 59:         System.setProperty("sun.rmi.transport.tcp.handshakeTimeout", "1");

I can see that this test uses "TIMEOUT" down in test 
/*
         * Wait for call attempt to finished, and analyze result.
         */
        t.join(TIMEOUT);

i will suggest you to reduce the "TIMEOUT"  constant instead of hard coding it to "1" second.

-------------

PR: https://git.openjdk.org/jdk/pull/12292

From djelinski at openjdk.org  Mon Jan 30 14:11:20 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jan 2023 14:11:20 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
In-Reply-To: <ETtgqQlFiQyp7C4zKNL2Gw-2mg0YPdNLyGhU3Zqqmec=.630667bd-211a-4e33-be40-3ab661acc3e7@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
 <ETtgqQlFiQyp7C4zKNL2Gw-2mg0YPdNLyGhU3Zqqmec=.630667bd-211a-4e33-be40-3ab661acc3e7@github.com>
Message-ID: <5gSOo_3JwnnABX6Y6RJufs3O-C0XnEiUXiu3Q1tEtec=.0e766660-ab0c-45f6-8a8f-e97e135eaf0c@github.com>

On Mon, 30 Jan 2023 12:54:34 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> I can see that this test uses "TIMEOUT" down in test

Right, this is why I didn't remove the TIMEOUT constant
> i will suggest you to reduce the "TIMEOUT" constant instead of hard coding it to "1" second.

I can't; this would make the test fail more often. I could introduce a separate timeout constant for `handshakeTimeout` to make it clear that the two are not related.

Note that this test uses 2 timeouts:
- the `handshakeTimeout`, which is the time limit for socket operations; when this amount of time passes waiting for a response from the server, an exception is thrown
- the `TIMEOUT`, which is the amount of time after which we expect to get the exception. This includes the `handshakeTimeout`, but also includes all other operations performed during the handshake, like class loading, initialization, TLS handshake etc.

Alternatively I could change the test descriptor to:

 * @run main/othervm/timeout=10 -Dsun.rmi.transport.tcp.handshakeTimeout=1 HandshakeTimeout

and drop both constants from the code.
What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/12292

From rgiulietti at openjdk.org  Mon Jan 30 14:33:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Jan 2023 14:33:06 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/6f026d45..d5592324

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=02-03

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From vtewari at openjdk.org  Mon Jan 30 14:52:18 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 30 Jan 2023 14:52:18 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
In-Reply-To: <5gSOo_3JwnnABX6Y6RJufs3O-C0XnEiUXiu3Q1tEtec=.0e766660-ab0c-45f6-8a8f-e97e135eaf0c@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
 <ETtgqQlFiQyp7C4zKNL2Gw-2mg0YPdNLyGhU3Zqqmec=.630667bd-211a-4e33-be40-3ab661acc3e7@github.com>
 <5gSOo_3JwnnABX6Y6RJufs3O-C0XnEiUXiu3Q1tEtec=.0e766660-ab0c-45f6-8a8f-e97e135eaf0c@github.com>
Message-ID: <B-1cbWkBWY8zv5E6bkmBlIKxqZGjkgafkhbgz-aezq8=.8efcff8b-267c-4f99-bb0a-60da54a34925@github.com>

On Mon, 30 Jan 2023 14:08:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java line 59:
>> 
>>> 57:     public static void main(String[] args) throws Exception {
>>> 58: 
>>> 59:         System.setProperty("sun.rmi.transport.tcp.handshakeTimeout", "1");
>> 
>> I can see that this test uses "TIMEOUT" down in test 
>> /*
>>          * Wait for call attempt to finished, and analyze result.
>>          */
>>         t.join(TIMEOUT);
>> 
>> i will suggest you to reduce the "TIMEOUT"  constant instead of hard coding it to "1" second.
>
>> I can see that this test uses "TIMEOUT" down in test
> 
> Right, this is why I didn't remove the TIMEOUT constant
>> i will suggest you to reduce the "TIMEOUT" constant instead of hard coding it to "1" second.
> 
> I can't; this would make the test fail more often. I could introduce a separate timeout constant for `handshakeTimeout` to make it clear that the two are not related.
> 
> Note that this test uses 2 timeouts:
> - the `handshakeTimeout`, which is the time limit for socket operations; when this amount of time passes waiting for a response from the server, an exception is thrown
> - the `TIMEOUT`, which is the amount of time after which we expect to get the exception. This includes the `handshakeTimeout`, but also includes all other operations performed during the handshake, like class loading, initialization, TLS handshake etc.
> 
> Alternatively I could change the test descriptor to:
> 
>  * @run main/othervm/timeout=10 -Dsun.rmi.transport.tcp.handshakeTimeout=1 HandshakeTimeout
> 
> and drop both constants from the code.
> What do you think?

setting System property(sun.rmi.transport.tcp.handshakeTimeout) as argument is good idea and this will increase the code readability as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12292

From rriggs at openjdk.org  Mon Jan 30 15:53:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 30 Jan 2023 15:53:32 GMT
Subject: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v7]
In-Reply-To: <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
References: <yFLoePM2lXP2XIqqfVp0c2uXApWHW27Csxe0BceJMws=.333214f3-652e-4d23-a208-55f083bf45e4@github.com>
 <Ld-C1pqntfxcJjKlfYU8eym3CgPwf3gDO6tsZXZMkhg=.f89e05cb-045a-40ad-abd3-e86581e41635@github.com>
Message-ID: <6fEpJW5zgghgSdlBnJf-V7Ml4sXzQa-Z12AJif_km0o=.85b83804-ab8a-494c-a7fb-01f01ddafafb@github.com>

On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Currently, `java.io.Bits` is using explicit logic to read/write various primitive types to/from byte arrays. Switching to the use of `VarHandle` access would provide better performance and less code. 
>> 
>> Also, using a standard API for these conversions means future `VarHandle` improvements will benefit `Bits` too. 
>> 
>> Improvements in `Bits` will propagate to `ObjectInputStream`, `ObjectOutputStream` and `RandomAccessFile`.
>> 
>> Initial benchmarks and performance discussions can be found here: https://github.com/openjdk/panama-foreign/pull/762
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove faulty test tag, improve other test tag, fix comments

The code in ZoneOffset isn't applicable for multiple reasons.  
1) Its a CharSequence (concretely a String), not a byte array. 
2) Adjacent elements are not binary and joined by a 8bit shift; there's a multiply by 10 in the middle.

-------------

PR: https://git.openjdk.org/jdk/pull/11840

From naoto at openjdk.org  Mon Jan 30 17:09:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 30 Jan 2023 17:09:28 GMT
Subject: Integrated: 8300916: Re-examine the initialization of JNU Charset in
 StaticProperty
In-Reply-To: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
References: <n4B3SvKfoa84W1hVT2YtoJvJ5c3wv5DINNfcYT36fCo=.a800995c-9031-4907-9e3b-a1caf733b544@github.com>
Message-ID: <arw4gbesvvymaKaZq4rhTSYAhEo9-RqvqJ3mtF7JYgQ=.6ec0fcbb-d42b-48c8-8401-440c8dfe9836@github.com>

On Tue, 24 Jan 2023 21:13:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.

This pull request has now been integrated.

Changeset: 32381398
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/323813985b71c63c915cdfce5221fc65a2ad043d
Stats:     41 lines in 4 files changed: 7 ins; 18 del; 16 mod

8300916: Re-examine the initialization of JNU Charset in StaticProperty

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12171

From mchung at openjdk.org  Mon Jan 30 18:14:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 30 Jan 2023 18:14:14 GMT
Subject: RFR: 8301207: (jdeps) Deprecate jdeps -profile option
Message-ID: <o_EgH5TlANXKguonYZm8Ls1I7ts_NOJmOKxCa38b8RM=.132bcecc-e950-47ad-a007-39c8f89ffe61@github.com>

jdeps -profile option shows which compact profile of the types that a class depends on instead.  By default jdeps shows the types and their modules that a class depend on.  Compact profiles becomes legacy since Java SE 9 when modules are defined.   The `-profile` option can be deprecated and removed in a future release to reduce the maintenance.

CSR: https://bugs.openjdk.org/browse/JDK-8301295

-------------

Commit messages:
 - 8301207: (jdeps) Deprecate jdeps -profile option

Changes: https://git.openjdk.org/jdk/pull/12297/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301207
  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12297.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12297/head:pull/12297

PR: https://git.openjdk.org/jdk/pull/12297

From alanb at openjdk.org  Mon Jan 30 18:19:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 30 Jan 2023 18:19:26 GMT
Subject: RFR: 8301207: (jdeps) Deprecate jdeps -profile option
In-Reply-To: <o_EgH5TlANXKguonYZm8Ls1I7ts_NOJmOKxCa38b8RM=.132bcecc-e950-47ad-a007-39c8f89ffe61@github.com>
References: <o_EgH5TlANXKguonYZm8Ls1I7ts_NOJmOKxCa38b8RM=.132bcecc-e950-47ad-a007-39c8f89ffe61@github.com>
Message-ID: <4tlDAklKNzNTb6SreFd9ZMSoxuKOnjNy37NFoVjXwNI=.5295a581-2153-4cfe-a528-d5582f56080f@github.com>

On Mon, 30 Jan 2023 18:06:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> jdeps -profile option shows which compact profile of the types that a class depends on instead.  By default jdeps shows the types and their modules that a class depend on.  Compact profiles becomes legacy since Java SE 9 when modules are defined.   The `-profile` option can be deprecated and removed in a future release to reduce the maintenance.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8301295

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12297

From darcy at openjdk.org  Mon Jan 30 18:44:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Jan 2023 18:44:43 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v2]
In-Reply-To: <t4WQCB08tO23KKB4gaIJodJ6dskRy6tK3wWuW2iOxLM=.fb86ea17-343d-4296-a2c6-0aa7ab733df3@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <WP5KdKGGohLfRD71Ib1Vns2SXHrKrzlBnNM8ONak5oY=.bb259add-26d2-41c1-bcdc-9f754a4e8d4c@github.com>
 <t4WQCB08tO23KKB4gaIJodJ6dskRy6tK3wWuW2iOxLM=.fb86ea17-343d-4296-a2c6-0aa7ab733df3@github.com>
Message-ID: <caggYBj9mnEZVW9WQKL3xWzgFbKly8VYfYtK7tRwbuA=.3553f44c-12ed-4353-a0aa-bf3b3bf22c89@github.com>

On Fri, 27 Jan 2023 18:22:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>>   
>>   Added tests for known differences between current and new behavior.
>
> Added tests for known differences.
> 
> Most of the modified files are generated automatically by a script that, somewhat questionably, renews the copyright year in some of the files for no apparent reason.

I've spoken to @rgiulietti about this PR; since there behavioral changes of possible interest, I'm requesting a CSR to cover those changes.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From darcy at openjdk.org  Mon Jan 30 18:50:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Jan 2023 18:50:14 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
Message-ID: <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>

On Mon, 30 Jan 2023 14:33:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

test/jdk/java/util/Formatter/Basic-X.java.template line 935:

> 933: 
> 934:         //---------------------------------------------------------------------
> 935:         // %e - adoption of Double.toString(double) algorithm (8300869)

Nit: we generally don't use the bug ids in comments like this, usually at most relying on a bug listed in the test "@bug" line.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Mon Jan 30 18:54:32 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Jan 2023 18:54:32 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
 <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
Message-ID: <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>

On Mon, 30 Jan 2023 18:47:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>
> test/jdk/java/util/Formatter/Basic-X.java.template line 935:
> 
>> 933: 
>> 934:         //---------------------------------------------------------------------
>> 935:         // %e - adoption of Double.toString(double) algorithm (8300869)
> 
> Nit: we generally don't use the bug ids in comments like this, usually at most relying on a bug listed in the test "@bug" line.

The bug id was added there because I'm not sure there's a way to add the @bug line to Basic-X.java.template`.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From kasperni at gmail.com  Mon Jan 30 19:32:07 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Mon, 30 Jan 2023 19:32:07 +0000
Subject: module opens directive and Lookup::defineClass
Message-ID: <CAPs6151RJSd71PKNVj+AhjwHOP8riyxbtBQNHY935ogb5sxoaQ@mail.gmail.com>

Hi,

I just saw the pull request for 8217920 (Lookup.defineClass injects a class
that can access private members of any class in its own module.)

The PR details how you can generate a class in a package that has been opened
to you via a module declaration. This generated class can then create a new
lookup object with full privileged access and pass it back to you. You can
then use this lookup object to reflective access *any* class in the module,
not only the packages that were opened to you.

In practice, this now means that the opens package directive is a wildcard
directive.

module mymodule {   opens some.package to some.other.module; }

means

module mymodule {   opens *all-my-packages* to some.other.module; }

Which conflicts with JLS 7.7.2. Exported and Opened Packages that says:

The opens directive specifies the name of a package to be opened by the
current module. For code in other modules, this grants access at run time,
but not compile time, to the public and protected types in the package, and
the public and protected members of those types. It also grants reflective
access to all types in the package, and all their members, for code in other
modules.

I understand the need to be backward compatible. But I find this behavior
of 'opens' surprising given that the directive takes a package name.
Also, the paragraph does say anything about granting the right to define new
classes in the package. It only talks about reflective access.

For those that are curious. I've made a simple demo that exploits this here
[1]. It takes a Lookup object and a class and will return a private lookup
object to the specified class if there is at least one open clause from the
module (of the specified class) to the caller. Irregardless if the specified
class is in an open package.

/Kasper

[1] https://gist.github.com/kaspernielsen/e072a38654d63f2918540e24e9d0380e

From rgiulietti at openjdk.org  Mon Jan 30 19:49:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Jan 2023 19:49:31 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v5]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <CJCv_oHe_qAce16TnfsoD6_DC4wayTuyRryfNSyDFeg=.257910a4-5505-4a1a-8f5c-7321ed768c3d@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/d5592324..0c72b743

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=03-04

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Mon Jan 30 19:49:32 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Jan 2023 19:49:32 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
Message-ID: <EISn4xaV2Y3-yF7uXDRyOS1VGJKnOkQQaSRss3ERxfo=.d97b2fd4-5b05-4e52-98e3-51b97b3c3dbc@github.com>

On Mon, 30 Jan 2023 14:33:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

The CSR has been added.

It covers both a behavioral change due to the implementation change in this PR, _and_ a specification change to align it with the implementation (current and proposed), resolving a long standing mismatch in the `e`, `f`, and `g` conversions on `float` values.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From msheppar at openjdk.org  Mon Jan 30 19:50:09 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 30 Jan 2023 19:50:09 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
In-Reply-To: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
Message-ID: <ulsT1qOtPBacPwiXPkdEbuNYh-NY_UIIAJEQuRAAiRA=.00a3d2f8-61b0-4907-b038-9fe678914cbb@github.com>

On Mon, 30 Jan 2023 11:06:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
> 
> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
> 
> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

What is the motivation for reducing the timeout for the handshake? 

I think the failure in the bug hints at a few potential issues that may be worth a deeper look.

There are two runs of this test ... plain socket and ssl socket. The failures is on the second ssl scenario. 

This is unexpected and question arises why did it happen. Is it an obscure issue in the RMI layer, or in the SSL layer, or perhaps in the native code associated with "select" for the timeout on the read/write ? 

Reducing the handshake timeout for the first scenario seems ok. But reducing the handshake to 1 millisecond for the ssl scenario maybe masking an issue with the SSL timers or within the RMI layer -- the failure could be suggesting some deeper issues. 

What the failure suggestion is that additional diagnostics would be helpful for determining how the main thread has reached the no timeout condition: 
?????????if (connector.exception == null) { 
????????????????throw new RuntimeException( 
????????????????????"TEST FAILED: remote call did not time out"); 
????????????} else { 

Did the Connector thread actually run? Is it in the RTR state waiting to be scheduled when the test completed? is it still alive? should additional state be added to indicate that the Connector thread has started? Should the Connector thread and the main thread synchronise on a countDownLatch before the thread join ? 

Thus, the failure suggests that a bit of restructuring would be useful, to add a bit of Connect run state, or check the state of the Connector thread prior to join, and some synchronization between the Connector thread and the main thread before the join to ensure that the Connector thread has started. The main thread waits for the Connector thread to actually start.

-------------

PR: https://git.openjdk.org/jdk/pull/12292

From darcy at openjdk.org  Mon Jan 30 19:51:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Jan 2023 19:51:56 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
 <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
 <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>
Message-ID: <dV7foaIzdFnZa9NuPZGmgiDXE3IM9ByDTN8zIaQwyrk=.d0b5fb90-346b-4e6b-950d-5b43938e388c@github.com>

On Mon, 30 Jan 2023 18:52:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic-X.java.template line 935:
>> 
>>> 933: 
>>> 934:         //---------------------------------------------------------------------
>>> 935:         // %e - adoption of Double.toString(double) algorithm (8300869)
>> 
>> Nit: we generally don't use the bug ids in comments like this, usually at most relying on a bug listed in the test "@bug" line.
>
> The bug id was added there because I'm not sure there's a way to add the @bug line to Basic-X.java.template`.

I see; it might suffice in this case to rely on the bug information in the SCM history, but I don't have a strong opinion.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From bpb at openjdk.org  Mon Jan 30 20:12:00 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Jan 2023 20:12:00 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java [v2]
In-Reply-To: <iIg3nd6JAdxCfbEWqoYPpJuTjE-WgTNFqVlUkKMYSvI=.27627b3b-b3f3-4eaf-99b9-78b1f4ad87a6@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
 <iIg3nd6JAdxCfbEWqoYPpJuTjE-WgTNFqVlUkKMYSvI=.27627b3b-b3f3-4eaf-99b9-78b1f4ad87a6@github.com>
Message-ID: <wSTIvCCBWP-zaVnQnVY9HwhV6I-qaJnNBvYOBfLh16Y=.4c54a4f7-1c09-4a2b-8dfb-14e6f0dc7c5c@github.com>

On Fri, 27 Jan 2023 17:53:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Restarting the port of FDLIBM to Java with the log10 method.
>> 
>> There are two port, the first a near-transliteration from C port to use as a test reference in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> and a more idiomatic Java port in 
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12242

From rgiulietti at openjdk.org  Mon Jan 30 20:12:59 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Jan 2023 20:12:59 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <dV7foaIzdFnZa9NuPZGmgiDXE3IM9ByDTN8zIaQwyrk=.d0b5fb90-346b-4e6b-950d-5b43938e388c@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
 <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
 <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>
 <dV7foaIzdFnZa9NuPZGmgiDXE3IM9ByDTN8zIaQwyrk=.d0b5fb90-346b-4e6b-950d-5b43938e388c@github.com>
Message-ID: <HLZex_yWY6xd3PxBCV8IyHevGJSMd3uxHgsQ-nHExZM=.665d70eb-14ad-4f55-8464-b659a8dd0a83@github.com>

On Mon, 30 Jan 2023 19:48:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The bug id was added there because I'm not sure there's a way to add the @bug line to Basic-X.java.template`.
>
> I see; it might suffice in this case to rely on the bug information in the SCM history, but I don't have a strong opinion.

In this specific `*.java.template` case, I think that the bug id in the comment somehow replaces the lack of the @bug line.
But I have no problems in removing it if there are stronger opinions.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From duke at openjdk.org  Mon Jan 30 20:15:36 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 30 Jan 2023 20:15:36 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v15]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <tJ6rZPkZsfN4Q9KGG4Mntjv6IMox780w-hSSukxTJOw=.330aa7b2-1add-4546-9c36-8175676235e5@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Try other way

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/2a381bde..f33fff2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=13-14

  Stats: 29 lines in 1 file changed: 18 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From darcy at openjdk.org  Mon Jan 30 20:19:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Jan 2023 20:19:28 GMT
Subject: RFR: JDK-8301205: Port fdlibm log10 to Java [v3]
In-Reply-To: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
Message-ID: <vNdme5tb-Am6ijQmDG-sFkFdj2OFvfn6RZL5fMTLtiQ=.6fcabba5-0012-4fc3-bc6c-80d2bb1b0f45@github.com>

> Restarting the port of FDLIBM to Java with the log10 method.
> 
> There are two port, the first a near-transliteration from C port to use as a test reference in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> and a more idiomatic Java port in 
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

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:

 - Merge branch 'master' into JDK-8301205
 - Add comment.
 - Reformat code some more.
 - Change to hex fp literals, misc updates.
 - Use more idiomatic style in ported FDLBIM code.
 - Merge branch 'master' into JDK-8301205
 - JDK-8301205: Port fdlibm log10 to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12242/files
  - new: https://git.openjdk.org/jdk/pull/12242/files/0f74dd5f..9ae3bf20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12242&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12242&range=01-02

  Stats: 7048 lines in 320 files changed: 1291 ins; 249 del; 5508 mod
  Patch: https://git.openjdk.org/jdk/pull/12242.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12242/head:pull/12242

PR: https://git.openjdk.org/jdk/pull/12242

From darcy at openjdk.org  Mon Jan 30 20:36:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 30 Jan 2023 20:36:06 GMT
Subject: Integrated: JDK-8301205: Port fdlibm log10 to Java
In-Reply-To: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
References: <DCUOc1hFNpdaLe2x9wjfzpjdgIlsKLO3v9ks3aM_CTA=.df3d66a4-2bec-44c3-b4b1-5583fb43b9d8@github.com>
Message-ID: <UalQJ4MS0SHIZue8hgUDh_D5U6uQ4YOsj_yR5fgWooo=.198b9d0d-7526-47fb-a049-d5af2796cd0a@github.com>

On Fri, 27 Jan 2023 06:52:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Restarting the port of FDLIBM to Java with the log10 method.
> 
> There are two port, the first a near-transliteration from C port to use as a test reference in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> and a more idiomatic Java port in 
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> First I debug the FdlibmTranslit port by running it against the C version. Once that is working, I copy the port into the java.lang.FdLibm.java and do a series of transformation to get the code closer to usual JDK style.

This pull request has now been integrated.

Changeset: 63bb2ce8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63bb2ce8debdeb7f34bda9a3845fe93cb4d741dd
Stats:     222 lines in 4 files changed: 207 ins; 0 del; 15 mod

8301205: Port fdlibm log10 to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12242

From dcubed at openjdk.org  Mon Jan 30 21:16:59 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 30 Jan 2023 21:16:59 GMT
Subject: RFR: 8301306: java/net/httpclient/* fail with -Xcomp:
 java.io.IOException: HTTP/1.1 header parser received no bytes
In-Reply-To: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
References: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
Message-ID: <6FqKaRIGviFbqzhNTDdnS17GlPWc3zhYGgNDf5QROSw=.da52e3d3-f683-4660-9cd1-7e61a750f063@github.com>

On Mon, 30 Jan 2023 07:16:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> I think `BackgroundCompilation` should not be set to false when `-Xcomp` be used, which causes the java thread to block for longer, then causing the following tests failed frequently on the AArch64 and LoongArch64 architecture.
> 
> java/net/httpclient/ByteArrayPublishers.java ?fastdebug -Xcomp?
> java/net/httpclient/ManyRequestsLegacy.java ?fastdebug -Xcomp?
> java/net/httpclient/HttpClientLocalAddrTest.java ?fastdebug -Xcomp?
> jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ?fastdebug -Xcomp?
> java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java ?release -Xcomp?
> 
> This PR delete BackgroundCompilation be setted, Above tests can be passed. Please help review it.
> 
> Thanks.

This is not the right fix for this kind of problem.

src/hotspot/share/runtime/arguments.cpp line 1440:

> 1438:   case _comp:
> 1439:     UseInterpreter           = false;
> 1440:     BackgroundCompilation    = false;

Disabling `BackgroundCompilation` when -Xcomp is specified is not the right
answer here. When `-Xcomp` is specified, `-Xbatch` needs to be turned off
and I believe that's what old L1440 is doing.

-------------

Changes requested by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12282

From mchung at openjdk.org  Mon Jan 30 22:43:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 30 Jan 2023 22:43:03 GMT
Subject: Integrated: 8301207: (jdeps) Deprecate jdeps -profile option
In-Reply-To: <o_EgH5TlANXKguonYZm8Ls1I7ts_NOJmOKxCa38b8RM=.132bcecc-e950-47ad-a007-39c8f89ffe61@github.com>
References: <o_EgH5TlANXKguonYZm8Ls1I7ts_NOJmOKxCa38b8RM=.132bcecc-e950-47ad-a007-39c8f89ffe61@github.com>
Message-ID: <PrSYrv5OD-Haz5lQqj1OTMRVwbiIj7moDwgX6mAX9PQ=.93ed1476-4bd8-494f-b225-07a9819c203f@github.com>

On Mon, 30 Jan 2023 18:06:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> jdeps -profile option shows which compact profile of the types that a class depends on instead.  By default jdeps shows the types and their modules that a class depend on.  Compact profiles becomes legacy since Java SE 9 when modules are defined.   The `-profile` option can be deprecated and removed in a future release to reduce the maintenance.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8301295

This pull request has now been integrated.

Changeset: 2d7690b2
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d7690b2e5b224bf2232c7cecf51cad8b0c078b3
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8301207: (jdeps) Deprecate jdeps -profile option

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12297

From cwimmer at openjdk.org  Mon Jan 30 23:36:03 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Mon, 30 Jan 2023 23:36:03 GMT
Subject: Integrated: JDK-8262994: Refactor String.split to help method inlining
In-Reply-To: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
References: <Qx8nXCwS2-gs7luRXNRLpkauOlFYRrEZnSI5KNPJ_Lc=.db350bf4-d4a8-470b-ab95-764b6f9fb87c@github.com>
Message-ID: <o8FPCTyS2QOrMD5_g5_nb9T95kk-DGfDVnTV1B78Cig=.6187f3d6-c472-439d-b385-b363e68d93ed@github.com>

On Tue, 27 Dec 2022 20:12:51 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

> The method `String.split` contains a fast-path when the regular expression parameter is not really a regular expression, but just a single split character.
> This fast path vs. slow path check can be constant folded when the regular expression parameter is a literal constant - a quite frequent pattern (for example, all JDK usages of `String.split` have a constant expression parameter). But method inlining in JIT and AOT compilers can usually not inline `String.split` because the method body is too large. Factoring out the actual fast-path splitting logic into a separate method solves this problem: the JIT or AOT compiler can inline `String.split`, constant-fold the fast/slow path check, and then only the invoke of either the fast path or the slow path remains.

This pull request has now been integrated.

Changeset: 622b6594
Author:    Christian Wimmer <cwimmer at openjdk.org>
Committer: Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/622b6594d1435e8773ec16d00d48e1f582065bd8
Stats:     43 lines in 1 file changed: 11 ins; 2 del; 30 mod

8262994: Refactor String.split to help method inlining

Reviewed-by: plevart

-------------

PR: https://git.openjdk.org/jdk/pull/11791

From kvn at openjdk.org  Mon Jan 30 23:44:01 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 30 Jan 2023 23:44:01 GMT
Subject: RFR: 8301306: java/net/httpclient/* fail with -Xcomp:
 java.io.IOException: HTTP/1.1 header parser received no bytes
In-Reply-To: <6FqKaRIGviFbqzhNTDdnS17GlPWc3zhYGgNDf5QROSw=.da52e3d3-f683-4660-9cd1-7e61a750f063@github.com>
References: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
 <6FqKaRIGviFbqzhNTDdnS17GlPWc3zhYGgNDf5QROSw=.da52e3d3-f683-4660-9cd1-7e61a750f063@github.com>
Message-ID: <jq7KV3IrQiKAu-4xtm_P1gRriclOuMbN3EWRSAMW1Kk=.53b809c4-e287-43c0-9703-fac25d7caf5f@github.com>

On Mon, 30 Jan 2023 21:13:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi all,
>> I think `BackgroundCompilation` should not be set to false when `-Xcomp` be used, which causes the java thread to block for longer, then causing the following tests failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> java/net/httpclient/ByteArrayPublishers.java ?fastdebug -Xcomp?
>> java/net/httpclient/ManyRequestsLegacy.java ?fastdebug -Xcomp?
>> java/net/httpclient/HttpClientLocalAddrTest.java ?fastdebug -Xcomp?
>> jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ?fastdebug -Xcomp?
>> java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java ?release -Xcomp?
>> 
>> This PR delete BackgroundCompilation be setted, Above tests can be passed. Please help review it.
>> 
>> Thanks.
>
> src/hotspot/share/runtime/arguments.cpp line 1440:
> 
>> 1438:   case _comp:
>> 1439:     UseInterpreter           = false;
>> 1440:     BackgroundCompilation    = false;
> 
> Disabling `BackgroundCompilation` when -Xcomp is specified is not the right
> answer here. When `-Xcomp` is specified, `-Xbatch` needs to be turned off
> and I believe that's what old L1440 is doing.

Dan is right, you  can't change the definition of -Xcomp.

But `-Xbatch` is `-XX:-BackgroundCompilation`. So the second Dan's statement is incorrect.

-------------

PR: https://git.openjdk.org/jdk/pull/12282

From stuart.marks at oracle.com  Tue Jan 31 02:12:59 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 30 Jan 2023 18:12:59 -0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
Message-ID: <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>

In this reply I'll focus on the null handling issues in collections.

As you've noted, there are really (at least) two distinct issues here: whether a 
collection permits nulls, and the behavior of contains(null) queries. There have 
been continual complaints about both, and the issues are somewhat distinct.

The collection implementations in the JDK are all over the place with regard to 
nulls. I believe this is because the original collections and the concurrent 
collections up through JDK 1.6 or so were mostly done by Josh Bloch and Doug Lea, 
who disagreed about null handling. They had this exchange in 2006:

Doug Lea wrote: [1]

> The main reason that nulls aren't allowed in ConcurrentMaps
> (ConcurrentHashMaps, ConcurrentSkipListMaps) is that
> ambiguities that may be just barely tolerable in non-concurrent
> maps can't be accommodated. The main one is that if
> map.get(key) returns null, you can't detect whether the
> key explicitly maps to null vs the key isn't mapped.
> In a non-concurrent map, you can check this via map.contains(key),
> but in a concurrent one, the map might have changed between calls.
> 
> Further digressing: I personally think that allowing
> nulls in Maps (also Sets) is an open invitation for programs
> to contain errors that remain undetected until
> they break at just the wrong time. (Whether to allow nulls even
> in non-concurrent Maps/Sets is one of the few design issues surrounding
> Collections that Josh Bloch and I have long disagreed about.)


Josh Bloch wrote: [2]

> I have moved towards your position over the years.  It was probably a
> mistake to allow null keys in Maps and null elements in Sets.  I'm
> still not sure about Map values and List elements.
> 
> In other words, Doug hates null more than I do, but over the years
> I've come to see it as quite troublesome.


(I haven't talked to Josh or Doug about this particular issue recently, so I suppose 
it's possible their opinions have changed in the intervening time.)

I had to decide what to do about nulls when I added the unmodifiable collections in 
JDK 9. Given that Doug "hates" nulls, and Josh finds them at least quite 
troublesome, I started from a position of disallowing null members in all the new 
collections. Most of the unmodifiable collections are still this way (but see below).

What about contains(null)? Surely it should be ok to query for a null, and return 
false, even if the collection itself can't contain null. However, a bunch of 
collections and collection views in the JDK throw NPE on contains(null), so the 
unmodifiable collections don't set a precedent here.

If you're dealing with all non-null values, and a null creeps in somehow, then 
calling contains(null) might be an error, and it would be good for the library to 
inform you of that instead of just returning false and letting the program continue 
until it fails later (fail-fast). A similar issue arises with the non-generic 
contains() method. If you have a Collection<Integer>, then shouldn't contains("abc") 
be an error? It's not, and it simply returns false, because the signature is 
contains(Object). But there have been complaints that this should have been an error 
because a Collection of Integer cannot possibly contain a String. Similar reasoning 
applies to contains(null) on a collection that can't contain null. (Yes, the error 
occurs at runtime instead of compile time, but better late than never.)

A meta-issue is: should a new thing correct a perceived design flaw in the older 
thing, or should it be consistent with the old thing? Either way, you lose.

Another factor in my original decision was that it's much easier to start with a 
restriction and relax it later than it is to go the other way. We have some 
flexibility to allow nulls and contains(null) if we want; but it's essentially a 
non-starter to disallow nulls once they've been allowed somewhere.

That's why my starting position for the design prohibited nulls everywhere.

Over time we've relaxed some restrictions around null handling in the unmodifiable 
collections. Streams permit nulls, and the List returned from Stream.toList() also 
permits nulls, and it also allows contains(null). So there's a different 
unmodifiable List implementation under there, accessible only via streams. (Note 
that the null-permitting unmodifiable lists lose the optimizations for sizes 0, 1, 
and 2, which are in part based on nulls being disallowed.)

I'm fairly sympathetic to the case for changing the unmodifiable collections to 
allow contains(null), given that the current NPE-throwing behavior has generated a 
fair amount of complaints over the years. And the situation with having two flavors 
of unmodifiable list is quite odd and is an uncomfortable point in the design space.

I should point out however that even if the unmodifiable collections were changed to 
allow contains(null), it's still kind of unclear as to whether this code is safe:

   public void addShoppingItems(Collection<String> shoppingItems) {
     if (shoppingItems.contains(null)) {  // this looks quite reasonable and safe...
       throw new IllegalArgumentException("shoppingItems should not contain nulls");
     }
     ...
   }

If you're only ever passing ArrayList, Arrays.asList(), and List.of() lists here, 
then sure, this would work great. If the source collection is of unknown provenance, 
you can still run into trouble:

1. contains(null) calls on the keySet and values collections of ConcurrentHashMap 
and Hashtable all throw NPE. So does contains(null) on a set from 
Collections.newSetFromMap(), which is built from those maps' keySets. (I suppose 
Doug Lea might be convinced to relax the CHM behavior.)

2. Speaking of concurrency, if the source collection is being modified concurrently, 
then a null could be introduced after the check (TOCTOU) so you'd need to make a 
defensive copy before checking it.

3. NavigableSet and friends delegate contains() to the comparison method, which 
might or might not accept nulls. There's no way the collection implementation can 
tell in advance.

You might consider List.copyOf() as an alternative, as that makes a null-free 
defensive copy in one shot, and avoids copying if the source is an unmodifiable 
list. If you don't care about concurrency, then

     shoppingItems.forEach(Objects::requireNonNull)

might be suitable.

If unmodifiable collections were to change to allow contains(null), this probably 
would make them somewhat less annoying, but it wouldn't necessarily solve yours or 
everyone's problems. There's simply no way at this point to make the collections' 
treatment of nulls uniform.

s'marks


[1] 
https://web.archive.org/web/20210510190135/https://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002485.html

[2] 
https://web.archive.org/web/20200930213909/http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002486.html




On 1/29/23 7:28 AM, John Hendrikx wrote:
> TLDR; why does contains(null) not just return false for collections that don't allow 
> nulls. Just because the interface allows it, does not mean it should do it as it 
> devalues the usefulness of the abstraction provided by the interface.
> 
> Background:
> 
> I'm someone that likes to check correctness of any constructor or method parameter 
> before allowing an object to be constructed or to be modified, in order to maintain 
> invariants that are provided by the class to its users.
> 
> This ranges from simple null checks, to range checks on numeric values, to complete 
> checks like "is a collection sorted" or is a list of nodes acyclic. Anything I can 
> check in the constructor that may avoid problems further down the line or that may 
> affect what I can guarantee on its own API methods.? For example, if I check in the 
> constructor that something is not null, then the associated getter will guarantee 
> that the returned value is not null.? If I check that a List doesn't contain nulls, 
> then the associated getter will reflect that as well (assuming it is immutable or 
> defensivily copied).
> 
> For collections, this is currently becoming harder and harder because more and more 
> new collections are written to be null hostile.? It is fine if a collection doesn't 
> accept nulls, but throwing NPE when I ask such a collection if it contains null 
> seems to be counter productive, and reduces the usefulness of the collection 
> interfaces.
> 
> This strict interpretation makes the collection interfaces harder to use than 
> necessary. Interfaces are only useful when their contract is well defined. The more 
> things an interface allows or leaves unspecified, the less useful it is for its users.
> 
> I know that the collection interfaces allow this, but you have to ask yourself this 
> important question: how useful is an interface that makes almost no guarantees about 
> what its methods will do? Interfaces like `List`, `Map` and `Set` are passed as 
> method parameters a lot, and to make these useful, implementations of these 
> interfaces should do their best to provide as consistent an experience as is 
> reasonably possible. The alternative is that these interfaces will slowly decline in 
> usefulness as methods will start asking for `ArrayList` instead of `List` to avoid 
> having to deal with a too lenient specification.
> 
> With the collection interfaces I get the impression that recently there has been too 
> much focus on what would be easy for the collection implementation instead of what 
> would be easy for the users of said interfaces. In my opinion, the concerns of the 
> user of interfaces almost always far outweigh the concerns of the implementors of 
> said interfaces.
> 
> In the past, immutable collections were rare, but they get are getting more and more 
> common all the time.? For example, in unit testing. Unfortunately, these immutable 
> collections differ quite a bit from their mutable counterparts.? Some parts are only 
> midly annoying (not accepting `null` as the **value** in a `Map` for example), but 
> other parts require code to be rewritten for it to be able to work as a drop-in 
> replacement for the mutable variant. A simple example is this:
> 
>  ??? public void addShoppingItems(Collection<String> shoppingItems) {
>  ??????? if (shoppingItems.contains(null)) {? // this looks quite reasonable and 
> safe...
>  ??????????? throw new IllegalArgumentException("shoppingItems should not contain 
> nulls");
>  ??????? }
> 
>  ??????? this.shoppingItems.addAll(shoppingItems);
>  ??? }
> 
> Testing this code is annoying:
> 
>  ???? x.addShoppingItems(List.of("a", null"));?? // can't construct immutable 
> collection with null
> 
>  ???? x.addShoppingItems(Arrays.asList("a", null"));? // fine, go back to what we 
> did before then...
> 
> The above problems, I suppose we can live with it; immutable collections don't want 
> `null` although I don't see any reason to not allow it as I can write a similar 
> `List.of` that returns immutable collections that do allow `null`. For JDK code this 
> is a bit disconcerting, as it is supposed to be as flexible as is reasonable without 
> having too much of an opinion about what is good or bad.
> 
> This next one however:
> 
>  ?? ? assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a", "b")));? // not 
> allowed, contains(null) in application code throws NPE
> 
> This is much more insidious; the `contains(null)` check has been a very practical 
> way to check if collections contain null, and this works for almost all collections 
> in common use, so there is no problem.? But now, more and more collections are 
> starting to just throw NPE immediately even just to **check** if a null element is 
> present. This only serves to distinguish themselves loudly from other similar 
> collections that will simply return `false`.
> 
> I think this behavior is detrimental to the java collection interfaces in general, 
> especially since there is a clear answer to the question if such a collection 
> contains null or not. In fact, why `contains` was ever allowed to throw an exception 
> aside from "UnsupportedOperationException" is a mystery to me, and throwing one when 
> one could just as easily return the correct and expected answer seems very opiniated 
> and almost malicious -- not behavior I'd expect from JDK core libraries.
> 
> Also note that there is no way to know in advance if `contains(null)` is going to be 
> throwing the NPE. If interfaces had a method `allowsNulls()` that would already be 
> an improvement.
> 
> --John
> 
> 

From darcy at openjdk.org  Tue Jan 31 03:45:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Jan 2023 03:45:27 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java
Message-ID: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>

Another day, another PR to port FDLBIM to Java, this time for the log1p method.

Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 

src/java.base/share/native/libfdlibm/s_log1p.c

and the transliteration for testing purposes in

test/jdk/java/lang/StrictMath/FdlibmTranslit.java

The more idiomatic port in

src/java.base/share/classes/java/lang/FdLibm.java

has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.

The regression tests include probing around input values the implementation uses to decided which branch to take.

-------------

Commit messages:
 - Refactor to use fp hex literals, a little more whitespace refactoring.
 - More whitespace improvements.
 - Improve whitespace usage.
 - JDK-8301392: Port fdlibm log1p to Java

Changes: https://git.openjdk.org/jdk/pull/12301/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301392
  Stats: 389 lines in 4 files changed: 377 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12301.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12301/head:pull/12301

PR: https://git.openjdk.org/jdk/pull/12301

From aturbanov at openjdk.org  Tue Jan 31 06:52:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 31 Jan 2023 06:52:00 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <ImPZstKJLYu_NQd_DVcjDNZv7WLy81tB6H2FmuJ2T1s=.4b409151-1b55-4b66-8cd2-b8f57489e815@github.com>

On Tue, 31 Jan 2023 02:52:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

src/java.base/share/classes/java/lang/FdLibm.java line 785:

> 783:         private static double ivln10    = 0x1.bcb7b1526e50ep-2;  // 4.34294481903251816668e-01
> 784: 
> 785:         private static double log10_2hi = 0x1.34413509f6p-2;     // 3.01029995663611771306e-01;

Are this constants intentionally not `final` ?

src/java.base/share/classes/java/lang/FdLibm.java line 911:

> 909:             k = 1;
> 910:             if (hx < 0x3FDA827A) {                  /* x < 0.41422  */
> 911:                 if(ax >= 0x3ff00000) {                /* x <= -1.0 */

Suggestion:

                if (ax >= 0x3ff00000) {                /* x <= -1.0 */

test/jdk/java/lang/StrictMath/Log1pTests.java line 235:

> 233: 
> 234:         // ... and just below subnormal threshold ...
> 235:         x =  Math.nextDown(Double.MIN_NORMAL);

Suggestion:

        x = Math.nextDown(Double.MIN_NORMAL);

-------------

PR: https://git.openjdk.org/jdk/pull/12301

From alanb at openjdk.org  Tue Jan 31 07:20:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 07:20:58 GMT
Subject: RFR: 8301306: java/net/httpclient/* fail with -Xcomp:
 java.io.IOException: HTTP/1.1 header parser received no bytes
In-Reply-To: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
References: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
Message-ID: <6fnUwy6HzFRayDG7nAxPrmngynYKafwiPnHXURtxHS0=.2f2ea40f-a429-450b-af79-c44065122b12@github.com>

On Mon, 30 Jan 2023 07:16:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> I think `BackgroundCompilation` should not be set to false when `-Xcomp` be used, which causes the java thread to block for longer, then causing the following tests failed frequently on the AArch64 and LoongArch64 architecture.
> 
> java/net/httpclient/ByteArrayPublishers.java ?fastdebug -Xcomp?
> java/net/httpclient/ManyRequestsLegacy.java ?fastdebug -Xcomp?
> java/net/httpclient/HttpClientLocalAddrTest.java ?fastdebug -Xcomp?
> jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ?fastdebug -Xcomp?
> java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java ?release -Xcomp?
> 
> This PR delete BackgroundCompilation be setted, Above tests can be passed. Please help review it.
> 
> Thanks.

There was some discussion about these test failures in the JBS issue and I think @sunny868 has accepted that they need to be investigated to see if they are test reliability issues or something else. As always, running tests with -Xcomp can often challenge timeouts and assumption of progress in tests.

-------------

PR: https://git.openjdk.org/jdk/pull/12282

From alanb at openjdk.org  Tue Jan 31 09:02:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 09:02:56 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <n9yyttjOa9MR3Q2sqNd4qlyiQBof4NdFFbeH5U6Ll1k=.88010c9d-59cd-47ee-8bab-e85c48453cf4@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>
 <n9yyttjOa9MR3Q2sqNd4qlyiQBof4NdFFbeH5U6Ll1k=.88010c9d-59cd-47ee-8bab-e85c48453cf4@github.com>
Message-ID: <52ZwQHgwsqpLSXlv9x2J7ognWkJ87ZIKJd-6Aj6Gxzs=.92bbbdc3-ebd5-4c78-ae50-704292a2505e@github.com>

On Mon, 30 Jan 2023 08:38:15 GMT, Amit Kumar <duke at openjdk.org> wrote:

> m=525312, n=498060, len=524288, eq=false

The test doesn't print this so I assume this is tracing that you added in your runs. If I read it correctly, the initial input is len=524288, it deflates to m=525312, then re-inflates to n=498060. So it looks like it has been truncated. Would it be possible to print out the value of inf.getRemaining()?  I'm wondering if the test needs to be changed to call inflate in a loop until there are no remaining bytes.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From alanb at openjdk.org  Tue Jan 31 09:40:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 09:40:58 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v14]
In-Reply-To: <pLyEbxFDJ9qIcYj6FpKpmFnMy4epE6NVnE8rSbPwFsA=.37865c6b-e199-4745-95f0-e7b92665b18e@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <w-5ffBjKSnasXEOw1EwWDrW9QE8h47IvbuoPydLa9bo=.e97abb27-da3c-421d-8f28-0fab36af9043@github.com>
 <pLyEbxFDJ9qIcYj6FpKpmFnMy4epE6NVnE8rSbPwFsA=.37865c6b-e199-4745-95f0-e7b92665b18e@github.com>
Message-ID: <xd5zKQClI0MjtTLr668KUcz_6mSeihWu2loe5nzLkh4=.6e2bebce-bf5c-4e2e-a20a-2a8e83dce482@github.com>

On Thu, 26 Jan 2023 19:30:50 GMT, Christoph <duke at openjdk.org> wrote:

> We readded the splitting code and the test is passing. In the test we could make it work with up to 130 modules where each module _n_ requires all modules from _0...n_

The patch looks similar to the original. As a quick test, I changed the threshold to 10 (from 90) to force the creation of helper methods and it fails as expected with:


$ java -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version
Error occurred during initialization of boot layer
java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:
    jdk/internal/module/SystemModules$default.moduleDescriptorsSub1([Ljava/lang/module/ModuleDescriptor;)V @18: aload
  Reason:
    Type top (current frame, locals[14]) is not assignable to reference type
  Current Frame:
    bci: @18
    flags: { }
    locals: { 'jdk/internal/module/Builder', '[Ljava/lang/module/ModuleDescriptor;' }
    stack: { 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', '[Ljava/lang/module/ModuleDescriptor$Requires;', '[Ljava/lang/module/ModuleDescriptor$Requires;', integer }


Do you want to continue with this issue?

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From rgiulietti at openjdk.org  Tue Jan 31 09:47:57 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 31 Jan 2023 09:47:57 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <7zjpcCrPI9mMEA5TJT1XVXb00zpb1U24FTJp6WcVypU=.00b39220-8d98-48ca-b039-13088d87c198@github.com>

On Tue, 31 Jan 2023 02:52:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

For consistency with the code for [log10](https://github.com/openjdk/jdk/pull/12242), the hex `int` literals could be separated with `_` for better readability, as in `0x3ff0_0000`.

Otherwise LGTM

-------------

PR: https://git.openjdk.org/jdk/pull/12301

From duke at openjdk.org  Tue Jan 31 10:53:38 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 31 Jan 2023 10:53:38 GMT
Subject: RFR: JDK-8300098 :
 java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with
 internal timeout when executed with TieredCompilation1/3
Message-ID: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>

The proposed fix by @DougLea ensures that the state transition into waiting is retried in the cases where a previous waiter isn't making progress and a new waiter goes into waiting.

-------------

Commit messages:
 - JDK-8300098 : java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with internal timeout when executed with TieredCompilation1/3

Changes: https://git.openjdk.org/jdk/pull/12319/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12319&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300098
  Stats: 12 lines in 1 file changed: 2 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12319.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12319/head:pull/12319

PR: https://git.openjdk.org/jdk/pull/12319

From stsypanov at openjdk.org  Tue Jan 31 11:54:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 31 Jan 2023 11:54:47 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and
 Bundles.CacheKey
Message-ID: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>

`ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

-------------

Commit messages:
 - Copyright year update
 - Modernize Bubldes.equals()

Changes: https://git.openjdk.org/jdk/pull/12328/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301492
  Stats: 13 lines in 2 files changed: 0 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12328/head:pull/12328

PR: https://git.openjdk.org/jdk/pull/12328

From stsypanov at openjdk.org  Tue Jan 31 11:54:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 31 Jan 2023 11:54:49 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <p58IJWk5lmPXjSOVJt2PQgKc94xvRgscgWfVicMsFUQ=.d1829946-b35a-4003-a90b-9147d11c72b3@github.com>

On Tue, 31 Jan 2023 11:40:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Btw, in `ResourceBundle.CacheKey.equals()` can we replace

Module module = getModule();
Module caller = getCallerModule();
return Objects.equals(module, otherEntry.getModule()) &&
       Objects.equals(caller, otherEntry.getCallerModule());

with

return moduleRef.refersTo(otherEntry.getModule()) &&
        callerRef.refersTo(otherEntry.getCallerModule());

?

-------------

PR: https://git.openjdk.org/jdk/pull/12328

From rgiulietti at openjdk.org  Tue Jan 31 13:39:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 31 Jan 2023 13:39:15 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v6]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <tKqc-gnSwJBYC5VfPKqN0tq0ptV92xk8pyG4m5OVnT4=.abac1f7f-a1b7-43e9-9bd9-e888a4e0d7b4@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/0c72b743..bfe3d155

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Tue Jan 31 13:43:01 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 31 Jan 2023 13:43:01 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <woN4p8g3qytJ3ZPsEBZ2b32O7RGZuA_ohsLKgTACbQY=.8932977c-dba0-4a6e-87f9-bd5304b7e3fc@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

This PR is waiting for a review

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From dnsimon at openjdk.org  Tue Jan 31 15:31:29 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 31 Jan 2023 15:31:29 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v38]
In-Reply-To: <YtZE5ynehR7OS2NxVjxuouIiIO4JwvEdzNiDQn-04NE=.5dd48b0f-5473-4ce3-a2cf-006ad428d997@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <YtZE5ynehR7OS2NxVjxuouIiIO4JwvEdzNiDQn-04NE=.5dd48b0f-5473-4ce3-a2cf-006ad428d997@github.com>
Message-ID: <ofnF3EJNrYL7m6hnYYIyGi62WJRLIXtNdtLUXo15vhY=.13905668-3b20-4b12-a6c3-d6b68e5e4b4f@github.com>

On Tue, 6 Dec 2022 21:14:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits:
> 
>  - Merge from JDK mainline
>  - Add comment
>  - Merge https://github.com/openjdk/jdk into JDK-8286666
>  - Feedback from reviewers
>  - Feedback from reviewers
>  - Unused variable
>  - Cleanup
>  - Cleanup
>  - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
>  - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - ... and 61 more: https://git.openjdk.org/jdk/compare/2cdc0195...46fa1389

src/hotspot/share/classfile/vmIntrinsics.hpp line 295:

> 293:    do_name(     setScopedValueCache_name,                        "setScopedValueCache")                                 \
> 294:    do_signature(setScopedValueCache_signature,                   "([Ljava/lang/Object;)V")                              \
> 295:   do_intrinsic(_findScopedValueBindings,  java_lang_Thread,       findScopedValueBindings_name, void_object_signature, F_SN) \

As far as I can tell, there is not yet an intrinsic implementation for `findScopedValueBindings`. Is this a placeholder for a pending implementation?

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From pminborg at openjdk.org  Tue Jan 31 16:09:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 31 Jan 2023 16:09:34 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in
 ZoneOffset
Message-ID: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>

`ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 

Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

-------------

Commit messages:
 - Update copyright years
 - Use AtomicReferenceArray for caching instead of CHM

Changes: https://git.openjdk.org/jdk/pull/12346/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301552
  Stats: 39 lines in 2 files changed: 22 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Tue Jan 31 16:09:36 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 31 Jan 2023 16:09:36 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <1su0_EK4Sx_blL9MQLS7147NWLaYH80QCSvM2iyV7h4=.6c053033-45ce-4234-912c-3de05ee0ef46@github.com>

On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

src/java.base/share/classes/java/time/ZoneOffset.java line 432:

> 430:         if (totalSeconds % (15 * SECONDS_PER_MINUTE) == 0) {
> 431:             int slot = cacheSlot(totalSeconds);
> 432:             ZoneOffset cached = SECONDS_CACHE.get(slot);

I miss `AtomicReferenceArray::computeIfNull` that atomically will compute an element if the value at a certain index is `null`.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From aefimov at openjdk.org  Tue Jan 31 16:27:59 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 31 Jan 2023 16:27:59 GMT
Subject: RFR: 8301367: Add exception handler method to the BaseLdapServer
Message-ID: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>

The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.

Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

-------------

Commit messages:
 - 8301367: Add exception handler method to the BaseLdapServer

Changes: https://git.openjdk.org/jdk/pull/12347/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12347&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301367
  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12347.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12347/head:pull/12347

PR: https://git.openjdk.org/jdk/pull/12347

From kvn at openjdk.org  Tue Jan 31 17:10:14 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 31 Jan 2023 17:10:14 GMT
Subject: RFR: 8301306: java/net/httpclient/* fail with -Xcomp:
 java.io.IOException: HTTP/1.1 header parser received no bytes
In-Reply-To: <6fnUwy6HzFRayDG7nAxPrmngynYKafwiPnHXURtxHS0=.2f2ea40f-a429-450b-af79-c44065122b12@github.com>
References: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
 <6fnUwy6HzFRayDG7nAxPrmngynYKafwiPnHXURtxHS0=.2f2ea40f-a429-450b-af79-c44065122b12@github.com>
Message-ID: <voYn1kAEL-uczb9Rw-p0aXytJiBq6ULbRS-134nSEAc=.841b1b6f-b1fb-446c-89ae-3a69cf00c0ec@github.com>

On Tue, 31 Jan 2023 07:17:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There was some discussion about these test failures in the JBS issue and I think @sunny868 has accepted that they need to be investigated to see if they are test reliability issues or something else. As always, running tests with -Xcomp can often challenge timeouts and assumption of progress in tests.

Yes, -Xcomp can cause long time execution since it we compile all executed methods. But it should not affect execution unless Java code depends on time itself which it should not do.

-------------

PR: https://git.openjdk.org/jdk/pull/12282

From amaembo at gmail.com  Tue Jan 31 17:29:05 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 31 Jan 2023 18:29:05 +0100
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>
Message-ID: <CAE+3fjYkjcn4uivWKa8WfEDwHa35a9Lox5o-jKk+fVKPO1SPSQ@mail.gmail.com>

Hello!

I agree that collection factories should not throw on contains(null).
This issue actually reduces their
adoption. Imagine that I always returned from some method
Collections.unmodifiableSet(new HashSet<>(Arrays.asList(non, null, values)));
It's a verbose construct that creates inefficient data structure with
tons of garbage in memory. But I cannot simply replace it
with Set.of(non, null, values) in a compatible way, as I don't know
whether clients rely on contains(null) or not.
When we migrated our codebase from Java 8 to Java 11, we eagerly
replaced dozens of uses of unmodifiableList/Set/Map to
collection factories. We even have an inspection for this. Most of
them were ok, but we also introduced new bugs, as contains(null)
is definitely called in some cases. Sometimes, this happens rarely,
and was not noticed during testing.
So we had new bugs in production and unhappy customers. Now we try not
to touch old code, unless we are totally sure that
contains(null) is never called.

I see that concurrent collections were implemented in the same way,
but the case when you want to replace
a normal collection with a concurrent one occurs rarely, and it's
likely that you still need to revisit all the uses of this collection,
to ensure that they are thread-safe, so you can fix potential problems
with contains(). On the other hand, collection factories
are very appealing to use, but this unpleasant behavior really gets in the way.

With best regards,
Tagir Valeev.

On Tue, Jan 31, 2023 at 3:14 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> In this reply I'll focus on the null handling issues in collections.
>
> As you've noted, there are really (at least) two distinct issues here: whether a
> collection permits nulls, and the behavior of contains(null) queries. There have
> been continual complaints about both, and the issues are somewhat distinct.
>
> The collection implementations in the JDK are all over the place with regard to
> nulls. I believe this is because the original collections and the concurrent
> collections up through JDK 1.6 or so were mostly done by Josh Bloch and Doug Lea,
> who disagreed about null handling. They had this exchange in 2006:
>
> Doug Lea wrote: [1]
>
> > The main reason that nulls aren't allowed in ConcurrentMaps
> > (ConcurrentHashMaps, ConcurrentSkipListMaps) is that
> > ambiguities that may be just barely tolerable in non-concurrent
> > maps can't be accommodated. The main one is that if
> > map.get(key) returns null, you can't detect whether the
> > key explicitly maps to null vs the key isn't mapped.
> > In a non-concurrent map, you can check this via map.contains(key),
> > but in a concurrent one, the map might have changed between calls.
> >
> > Further digressing: I personally think that allowing
> > nulls in Maps (also Sets) is an open invitation for programs
> > to contain errors that remain undetected until
> > they break at just the wrong time. (Whether to allow nulls even
> > in non-concurrent Maps/Sets is one of the few design issues surrounding
> > Collections that Josh Bloch and I have long disagreed about.)
>
>
> Josh Bloch wrote: [2]
>
> > I have moved towards your position over the years.  It was probably a
> > mistake to allow null keys in Maps and null elements in Sets.  I'm
> > still not sure about Map values and List elements.
> >
> > In other words, Doug hates null more than I do, but over the years
> > I've come to see it as quite troublesome.
>
>
> (I haven't talked to Josh or Doug about this particular issue recently, so I suppose
> it's possible their opinions have changed in the intervening time.)
>
> I had to decide what to do about nulls when I added the unmodifiable collections in
> JDK 9. Given that Doug "hates" nulls, and Josh finds them at least quite
> troublesome, I started from a position of disallowing null members in all the new
> collections. Most of the unmodifiable collections are still this way (but see below).
>
> What about contains(null)? Surely it should be ok to query for a null, and return
> false, even if the collection itself can't contain null. However, a bunch of
> collections and collection views in the JDK throw NPE on contains(null), so the
> unmodifiable collections don't set a precedent here.
>
> If you're dealing with all non-null values, and a null creeps in somehow, then
> calling contains(null) might be an error, and it would be good for the library to
> inform you of that instead of just returning false and letting the program continue
> until it fails later (fail-fast). A similar issue arises with the non-generic
> contains() method. If you have a Collection<Integer>, then shouldn't contains("abc")
> be an error? It's not, and it simply returns false, because the signature is
> contains(Object). But there have been complaints that this should have been an error
> because a Collection of Integer cannot possibly contain a String. Similar reasoning
> applies to contains(null) on a collection that can't contain null. (Yes, the error
> occurs at runtime instead of compile time, but better late than never.)
>
> A meta-issue is: should a new thing correct a perceived design flaw in the older
> thing, or should it be consistent with the old thing? Either way, you lose.
>
> Another factor in my original decision was that it's much easier to start with a
> restriction and relax it later than it is to go the other way. We have some
> flexibility to allow nulls and contains(null) if we want; but it's essentially a
> non-starter to disallow nulls once they've been allowed somewhere.
>
> That's why my starting position for the design prohibited nulls everywhere.
>
> Over time we've relaxed some restrictions around null handling in the unmodifiable
> collections. Streams permit nulls, and the List returned from Stream.toList() also
> permits nulls, and it also allows contains(null). So there's a different
> unmodifiable List implementation under there, accessible only via streams. (Note
> that the null-permitting unmodifiable lists lose the optimizations for sizes 0, 1,
> and 2, which are in part based on nulls being disallowed.)
>
> I'm fairly sympathetic to the case for changing the unmodifiable collections to
> allow contains(null), given that the current NPE-throwing behavior has generated a
> fair amount of complaints over the years. And the situation with having two flavors
> of unmodifiable list is quite odd and is an uncomfortable point in the design space.
>
> I should point out however that even if the unmodifiable collections were changed to
> allow contains(null), it's still kind of unclear as to whether this code is safe:
>
>    public void addShoppingItems(Collection<String> shoppingItems) {
>      if (shoppingItems.contains(null)) {  // this looks quite reasonable and safe...
>        throw new IllegalArgumentException("shoppingItems should not contain nulls");
>      }
>      ...
>    }
>
> If you're only ever passing ArrayList, Arrays.asList(), and List.of() lists here,
> then sure, this would work great. If the source collection is of unknown provenance,
> you can still run into trouble:
>
> 1. contains(null) calls on the keySet and values collections of ConcurrentHashMap
> and Hashtable all throw NPE. So does contains(null) on a set from
> Collections.newSetFromMap(), which is built from those maps' keySets. (I suppose
> Doug Lea might be convinced to relax the CHM behavior.)
>
> 2. Speaking of concurrency, if the source collection is being modified concurrently,
> then a null could be introduced after the check (TOCTOU) so you'd need to make a
> defensive copy before checking it.
>
> 3. NavigableSet and friends delegate contains() to the comparison method, which
> might or might not accept nulls. There's no way the collection implementation can
> tell in advance.
>
> You might consider List.copyOf() as an alternative, as that makes a null-free
> defensive copy in one shot, and avoids copying if the source is an unmodifiable
> list. If you don't care about concurrency, then
>
>      shoppingItems.forEach(Objects::requireNonNull)
>
> might be suitable.
>
> If unmodifiable collections were to change to allow contains(null), this probably
> would make them somewhat less annoying, but it wouldn't necessarily solve yours or
> everyone's problems. There's simply no way at this point to make the collections'
> treatment of nulls uniform.
>
> s'marks
>
>
> [1]
> https://web.archive.org/web/20210510190135/https://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002485.html
>
> [2]
> https://web.archive.org/web/20200930213909/http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002486.html
>
>
>
>
> On 1/29/23 7:28 AM, John Hendrikx wrote:
> > TLDR; why does contains(null) not just return false for collections that don't allow
> > nulls. Just because the interface allows it, does not mean it should do it as it
> > devalues the usefulness of the abstraction provided by the interface.
> >
> > Background:
> >
> > I'm someone that likes to check correctness of any constructor or method parameter
> > before allowing an object to be constructed or to be modified, in order to maintain
> > invariants that are provided by the class to its users.
> >
> > This ranges from simple null checks, to range checks on numeric values, to complete
> > checks like "is a collection sorted" or is a list of nodes acyclic. Anything I can
> > check in the constructor that may avoid problems further down the line or that may
> > affect what I can guarantee on its own API methods.  For example, if I check in the
> > constructor that something is not null, then the associated getter will guarantee
> > that the returned value is not null.  If I check that a List doesn't contain nulls,
> > then the associated getter will reflect that as well (assuming it is immutable or
> > defensivily copied).
> >
> > For collections, this is currently becoming harder and harder because more and more
> > new collections are written to be null hostile.  It is fine if a collection doesn't
> > accept nulls, but throwing NPE when I ask such a collection if it contains null
> > seems to be counter productive, and reduces the usefulness of the collection
> > interfaces.
> >
> > This strict interpretation makes the collection interfaces harder to use than
> > necessary. Interfaces are only useful when their contract is well defined. The more
> > things an interface allows or leaves unspecified, the less useful it is for its users.
> >
> > I know that the collection interfaces allow this, but you have to ask yourself this
> > important question: how useful is an interface that makes almost no guarantees about
> > what its methods will do? Interfaces like `List`, `Map` and `Set` are passed as
> > method parameters a lot, and to make these useful, implementations of these
> > interfaces should do their best to provide as consistent an experience as is
> > reasonably possible. The alternative is that these interfaces will slowly decline in
> > usefulness as methods will start asking for `ArrayList` instead of `List` to avoid
> > having to deal with a too lenient specification.
> >
> > With the collection interfaces I get the impression that recently there has been too
> > much focus on what would be easy for the collection implementation instead of what
> > would be easy for the users of said interfaces. In my opinion, the concerns of the
> > user of interfaces almost always far outweigh the concerns of the implementors of
> > said interfaces.
> >
> > In the past, immutable collections were rare, but they get are getting more and more
> > common all the time.  For example, in unit testing. Unfortunately, these immutable
> > collections differ quite a bit from their mutable counterparts.  Some parts are only
> > midly annoying (not accepting `null` as the **value** in a `Map` for example), but
> > other parts require code to be rewritten for it to be able to work as a drop-in
> > replacement for the mutable variant. A simple example is this:
> >
> >      public void addShoppingItems(Collection<String> shoppingItems) {
> >          if (shoppingItems.contains(null)) {  // this looks quite reasonable and
> > safe...
> >              throw new IllegalArgumentException("shoppingItems should not contain
> > nulls");
> >          }
> >
> >          this.shoppingItems.addAll(shoppingItems);
> >      }
> >
> > Testing this code is annoying:
> >
> >       x.addShoppingItems(List.of("a", null"));   // can't construct immutable
> > collection with null
> >
> >       x.addShoppingItems(Arrays.asList("a", null"));  // fine, go back to what we
> > did before then...
> >
> > The above problems, I suppose we can live with it; immutable collections don't want
> > `null` although I don't see any reason to not allow it as I can write a similar
> > `List.of` that returns immutable collections that do allow `null`. For JDK code this
> > is a bit disconcerting, as it is supposed to be as flexible as is reasonable without
> > having too much of an opinion about what is good or bad.
> >
> > This next one however:
> >
> >       assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a", "b")));  // not
> > allowed, contains(null) in application code throws NPE
> >
> > This is much more insidious; the `contains(null)` check has been a very practical
> > way to check if collections contain null, and this works for almost all collections
> > in common use, so there is no problem.  But now, more and more collections are
> > starting to just throw NPE immediately even just to **check** if a null element is
> > present. This only serves to distinguish themselves loudly from other similar
> > collections that will simply return `false`.
> >
> > I think this behavior is detrimental to the java collection interfaces in general,
> > especially since there is a clear answer to the question if such a collection
> > contains null or not. In fact, why `contains` was ever allowed to throw an exception
> > aside from "UnsupportedOperationException" is a mystery to me, and throwing one when
> > one could just as easily return the correct and expected answer seems very opiniated
> > and almost malicious -- not behavior I'd expect from JDK core libraries.
> >
> > Also note that there is no way to know in advance if `contains(null)` is going to be
> > throwing the NPE. If interfaces had a method `allowsNulls()` that would already be
> > an improvement.
> >
> > --John
> >
> >

From mchung at openjdk.org  Tue Jan 31 17:35:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 31 Jan 2023 17:35:22 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <8ViNuPWf2wFEzWB7ZWJTbHHxOqI16j0eBzRLZGzOYB4=.bf101b4d-df41-4979-a07d-0caa992dad94@github.com>

On Tue, 31 Jan 2023 11:40:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

return moduleRef.refersTo(otherEntry.getModule()) &&
        callerRef.refersTo(otherEntry.getCallerModule());


You need to check if module and caller module are non-null. 

`equals` returns true only if the module and callerModule of this `CacheKey` and other `CacheKey` are the same and non-null.

-------------

PR: https://git.openjdk.org/jdk/pull/12328

From pminborg at openjdk.org  Tue Jan 31 17:53:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 31 Jan 2023 17:53:49 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in b27
Message-ID: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>

This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

-------------

Commit messages:
 - Reduce contention

Changes: https://git.openjdk.org/jdk/pull/12193/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300917
  Stats: 42 lines in 1 file changed: 15 ins; 14 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12193/head:pull/12193

PR: https://git.openjdk.org/jdk/pull/12193

From pminborg at openjdk.org  Tue Jan 31 17:53:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 31 Jan 2023 17:53:49 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <mWuUGNlRQlCWFDM--5z0LvU4UxgXDYhogtwIoFFNo-c=.071e1a24-ffbb-48fd-8d7a-e6cdf94e75e6@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

The potential performance improvement in determining if native access is enabled is a small part of the overall benchmarks in the `LoopOverOfAddress` benchmarks:


Baseline
Benchmark                                         Mode  Cnt  Score   Error  Units
LoopOverOfAddress.segment_loop_addr_size          avgt   30  0.563 ? 0.005  ms/op


PR
Benchmark                                         Mode  Cnt  Score   Error  Units
LoopOverOfAddress.segment_loop_addr_size          avgt   30  0.558 ? 0.002  ms/op

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From darcy at openjdk.org  Tue Jan 31 18:00:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Jan 2023 18:00:06 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java
In-Reply-To: <ImPZstKJLYu_NQd_DVcjDNZv7WLy81tB6H2FmuJ2T1s=.4b409151-1b55-4b66-8cd2-b8f57489e815@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <ImPZstKJLYu_NQd_DVcjDNZv7WLy81tB6H2FmuJ2T1s=.4b409151-1b55-4b66-8cd2-b8f57489e815@github.com>
Message-ID: <XvF5y4gAOYJ1stQ9d1C5uterK4WhOB2EtugCtvsxnAU=.ed1f3b2b-ce62-41e8-8acd-ea43192f3e45@github.com>

On Tue, 31 Jan 2023 06:45:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
>> 
>> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
>> 
>> src/java.base/share/native/libfdlibm/s_log1p.c
>> 
>> and the transliteration for testing purposes in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> The more idiomatic port in
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
>> 
>> The regression tests include probing around input values the implementation uses to decided which branch to take.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 785:
> 
>> 783:         private static double ivln10    = 0x1.bcb7b1526e50ep-2;  // 4.34294481903251816668e-01
>> 784: 
>> 785:         private static double log10_2hi = 0x1.34413509f6p-2;     // 3.01029995663611771306e-01;
> 
> Are this constants intentionally not `final` ?

No, just an oversight; I'll correct that. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12301

From alanb at openjdk.org  Tue Jan 31 18:06:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 18:06:08 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <egMHMj2pQwZ1DzOogUYFyLy-iNkf1gOpNA9l18Iss6Q=.572e7fb5-47b3-485e-9f74-c9b871cd6d6a@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

src/java.base/share/classes/java/lang/Module.java line 318:

> 316:     }
> 317: 
> 318:     private static boolean casEnableNativeAccess(Module target) {

The change looks okay but the naming is a bit misleading, maybe trySetEnableNativeAccess would be better, as this isn't an Unsafe/VarHandler compareAndSet. Also would be possible to add a comment to the method so it's consistent with the existing methods.

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From bpb at openjdk.org  Tue Jan 31 18:15:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 31 Jan 2023 18:15:24 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <HLZex_yWY6xd3PxBCV8IyHevGJSMd3uxHgsQ-nHExZM=.665d70eb-14ad-4f55-8464-b659a8dd0a83@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
 <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
 <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>
 <dV7foaIzdFnZa9NuPZGmgiDXE3IM9ByDTN8zIaQwyrk=.d0b5fb90-346b-4e6b-950d-5b43938e388c@github.com>
 <HLZex_yWY6xd3PxBCV8IyHevGJSMd3uxHgsQ-nHExZM=.665d70eb-14ad-4f55-8464-b659a8dd0a83@github.com>
Message-ID: <B1jcuKlrxr6fXnqpGLxrNXw_YjBHbaVkEHIrxzGD5SQ=.ca706ef6-2b78-4864-bd81-31cb347ad311@github.com>

On Mon, 30 Jan 2023 20:10:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I see; it might suffice in this case to rely on the bug information in the SCM history, but I don't have a strong opinion.
>
> In this specific `*.java.template` case, I think that the bug id in the comment somehow replaces the lack of the @bug line.
> But I have no problems in removing it if there are stronger opinions.

The `@bug` tag is in `BasicTestLauncher` which is where 8300869 should likely go.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From alanb at openjdk.org  Tue Jan 31 18:22:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 18:22:00 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <E5clNnMo9JOgN-wMBMShCKxyqz5o8uyxapqRfX0sNfE=.2764642a-6132-4dc9-b425-fd586ce62af8@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

BTW: Is this PR meant by openjdk/jdk20 or openjdk/jdk?

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From rgiulietti at openjdk.org  Tue Jan 31 18:30:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 31 Jan 2023 18:30:14 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v7]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <nOpniQff5eA8HQLfs3OlhcJUvYCK29-RF41KNkbyc-I=.ad311826-3f61-46f2-b5c5-6a8015067bfc@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/bfe3d155..5e488a70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=05-06

  Stats: 19 lines in 7 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Tue Jan 31 18:30:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 31 Jan 2023 18:30:15 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v4]
In-Reply-To: <B1jcuKlrxr6fXnqpGLxrNXw_YjBHbaVkEHIrxzGD5SQ=.ca706ef6-2b78-4864-bd81-31cb347ad311@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <M_90zfRP5hVuBDOCa35EdD0A5eA5JqFY68kM6Ns1DiI=.281a2009-85ac-4a31-88e7-1f0f5c3b304e@github.com>
 <JuVYr7P3Or8Cyaj6nFbHM1tAjS3XZJckFgvg2CgRVqo=.584c0e6b-7e6b-4956-90fd-c89cecce2eb6@github.com>
 <dKTIVY0mpgLQ6Be8BQpmDJ-PL8NIvmD3RKY2n4hNBEY=.a223aa27-f31b-41c5-8a6e-94a6c3e02c13@github.com>
 <dV7foaIzdFnZa9NuPZGmgiDXE3IM9ByDTN8zIaQwyrk=.d0b5fb90-346b-4e6b-950d-5b43938e388c@github.com>
 <HLZex_yWY6xd3PxBCV8IyHevGJSMd3uxHgsQ-nHExZM=.665d70eb-14ad-4f55-8464-b659a8dd0a83@github.com>
 <B1jcuKlrxr6fXnqpGLxrNXw_YjBHbaVkEHIrxzGD5SQ=.ca706ef6-2b78-4864-bd81-31cb347ad311@github.com>
Message-ID: <HYVXa2Wd-Gu67W-Gy1noVJ9B9NCk10ewPW3PYiyGzrs=.39398969-196d-48e0-8c6a-d19441a48b6b@github.com>

On Tue, 31 Jan 2023 18:12:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In this specific `*.java.template` case, I think that the bug id in the comment somehow replaces the lack of the @bug line.
>> But I have no problems in removing it if there are stronger opinions.
>
> The `@bug` tag is in `BasicTestLauncher` which is where 8300869 should likely go.

Thanks @bplb for pointing to the right place.
Done

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From alanb at openjdk.org  Tue Jan 31 18:31:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 18:31:49 GMT
Subject: RFR: 8301043: Super-interface for PrintStream and PrintWriter [v2]
In-Reply-To: <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>
References: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>
 <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>
Message-ID: <sX4X8nZjKTGw0yl57z0je-WYaRR_f2X7Jie2-KSZh2M=.58338e02-03f5-4549-9f52-4f36eb21c1f5@github.com>

On Sun, 29 Jan 2023 07:11:26 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Add `java.io.PrintOutput` to represent print operations, and modify `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix grammar mistakes in the doc

A PR may be a bit premature as this probably needs discussion first on whether this is worth doing. Yes, there are common methods between the two but at the same time, the byte and character hierarchies have always been distinct. Have you encountered many libraries with overloads for PrintStream and PrintWriter?

-------------

PR: https://git.openjdk.org/jdk/pull/12277

From darcy at openjdk.org  Tue Jan 31 19:15:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Jan 2023 19:15:13 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v2]
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <OdpEh_Tfz3_AnrLlKxoKbrhT8aBDGfHdT1M6F_RJxww=.fbddf62a-44dc-46f5-9b8f-13b6c8883606@github.com>

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Implement review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12301/files
  - new: https://git.openjdk.org/jdk/pull/12301/files/6bdcd26d..acd3693f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12301&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12301&range=00-01

  Stats: 18 lines in 2 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/12301.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12301/head:pull/12301

PR: https://git.openjdk.org/jdk/pull/12301

From darcy at openjdk.org  Tue Jan 31 19:15:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Jan 2023 19:15:16 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v2]
In-Reply-To: <ImPZstKJLYu_NQd_DVcjDNZv7WLy81tB6H2FmuJ2T1s=.4b409151-1b55-4b66-8cd2-b8f57489e815@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <ImPZstKJLYu_NQd_DVcjDNZv7WLy81tB6H2FmuJ2T1s=.4b409151-1b55-4b66-8cd2-b8f57489e815@github.com>
Message-ID: <8EMw8wkXEtUyz8c_GejlsH1DprGfbMzOJlUldSo-oYI=.442b5ae7-e89c-4d31-bb76-fca55f10aedd@github.com>

On Tue, 31 Jan 2023 06:49:28 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 911:
> 
>> 909:             k = 1;
>> 910:             if (hx < 0x3FDA827A) {                  /* x < 0.41422  */
>> 911:                 if(ax >= 0x3ff00000) {                /* x <= -1.0 */
> 
> Suggestion:
> 
>                 if (ax >= 0x3ff00000) {                /* x <= -1.0 */

Changed; thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12301

From bhuang at openjdk.org  Tue Jan 31 19:15:35 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 19:15:35 GMT
Subject: RFR: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java manual test
 instruction
Message-ID: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>

Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)

This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.

-------------

Commit messages:
 - Update com/sun/jndi/dns/Test6991580.java manual test instruction

Changes: https://git.openjdk.org/jdk/pull/12351/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12351&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300909
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12351.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12351/head:pull/12351

PR: https://git.openjdk.org/jdk/pull/12351

From alanb at openjdk.org  Tue Jan 31 19:28:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 19:28:49 GMT
Subject: RFR: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java manual
 test instruction
In-Reply-To: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
References: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
Message-ID: <Eh88FCzy0vj8FKqENOKpioWhVrWHnMnvD7H4rx12-Fo=.8aad6b5a-a318-4e2c-9ba2-7f95b60331dc@github.com>

On Tue, 31 Jan 2023 19:08:08 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)
> 
> This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.

test/jdk/com/sun/jndi/dns/Test6991580.java line 66:

> 64:          "3. Type \"cd " + System.getProperty("test.classes") + "\".",
> 65:          "4. Type \"" + System.getProperty("java.home") + "/bin/java"
> 66:                  + " --add-modules java.desktop,jdk.naming.dns"

I don't think you'll need the --add-modules in the instructions. The java.desktop exports as an API so it will be resolved by default, same for the java.naming and that will ensure that the JNDI service provider modules are resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/12351

From bhuang at openjdk.org  Tue Jan 31 19:33:51 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 19:33:51 GMT
Subject: RFR: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java manual
 test instruction
In-Reply-To: <Eh88FCzy0vj8FKqENOKpioWhVrWHnMnvD7H4rx12-Fo=.8aad6b5a-a318-4e2c-9ba2-7f95b60331dc@github.com>
References: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
 <Eh88FCzy0vj8FKqENOKpioWhVrWHnMnvD7H4rx12-Fo=.8aad6b5a-a318-4e2c-9ba2-7f95b60331dc@github.com>
Message-ID: <dZFcgfcsbpC_pxiLnEu4Y_dECc_8ewXfFw6B-PokYYA=.3c80a628-b259-4bca-8441-f8a61bc0601e@github.com>

On Tue, 31 Jan 2023 19:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
>> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)
>> 
>> This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.
>
> test/jdk/com/sun/jndi/dns/Test6991580.java line 66:
> 
>> 64:          "3. Type \"cd " + System.getProperty("test.classes") + "\".",
>> 65:          "4. Type \"" + System.getProperty("java.home") + "/bin/java"
>> 66:                  + " --add-modules java.desktop,jdk.naming.dns"
> 
> I don't think you'll need the --add-modules in the instructions. The java.desktop exports as an API so it will be resolved by default, same for the java.naming and that will ensure that the JNDI service provider modules are resolved.

Thank you for the feedback. I will remove the --add-modules.

-------------

PR: https://git.openjdk.org/jdk/pull/12351

From bhuang at openjdk.org  Tue Jan 31 19:38:22 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 19:38:22 GMT
Subject: RFR: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java manual
 test instruction [v2]
In-Reply-To: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
References: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
Message-ID: <pZlYWwRwmRJB1sQDVgm0_s7fGDKtRLa5rjX6W4gZsKE=.31b5c44f-815b-476a-a4d7-06a369316253@github.com>

> Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)
> 
> This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Removed --add-modules.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12351/files
  - new: https://git.openjdk.org/jdk/pull/12351/files/d274657f..d271f3ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12351&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12351&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12351.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12351/head:pull/12351

PR: https://git.openjdk.org/jdk/pull/12351

From alanb at openjdk.org  Tue Jan 31 20:38:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Jan 2023 20:38:50 GMT
Subject: RFR: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java manual
 test instruction [v2]
In-Reply-To: <pZlYWwRwmRJB1sQDVgm0_s7fGDKtRLa5rjX6W4gZsKE=.31b5c44f-815b-476a-a4d7-06a369316253@github.com>
References: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
 <pZlYWwRwmRJB1sQDVgm0_s7fGDKtRLa5rjX6W4gZsKE=.31b5c44f-815b-476a-a4d7-06a369316253@github.com>
Message-ID: <7Nn6KwoP2miUpH0rrNJgGqvlRGo6rzRGEusJBMLs3gg=.84e8a86f-a78e-4499-8c95-cf44809d3be5@github.com>

On Tue, 31 Jan 2023 19:38:22 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
>> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)
>> 
>> This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed --add-modules.

Looks fine, I assume you've update the copyright header before you integrate.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12351

From zjx001202 at gmail.com  Tue Jan 31 21:12:24 2023
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 1 Feb 2023 05:12:24 +0800
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>
Message-ID: <CAJL5A3nkfU=ZNLCy8rNtHvDes8cmr97qKc8KFsN-jNjhe+HGDA@mail.gmail.com>

I understand that null is prohibited by default, but can we also provide a
set of factory methods that accept null?
They can be named like List.ofNullable/copyOfNullable.

On Tue, Jan 31, 2023 at 10:13 AM Stuart Marks <stuart.marks at oracle.com>
wrote:

> In this reply I'll focus on the null handling issues in collections.
>
> As you've noted, there are really (at least) two distinct issues here:
> whether a
> collection permits nulls, and the behavior of contains(null) queries.
> There have
> been continual complaints about both, and the issues are somewhat distinct.
>
> The collection implementations in the JDK are all over the place with
> regard to
> nulls. I believe this is because the original collections and the
> concurrent
> collections up through JDK 1.6 or so were mostly done by Josh Bloch and
> Doug Lea,
> who disagreed about null handling. They had this exchange in 2006:
>
> Doug Lea wrote: [1]
>
> > The main reason that nulls aren't allowed in ConcurrentMaps
> > (ConcurrentHashMaps, ConcurrentSkipListMaps) is that
> > ambiguities that may be just barely tolerable in non-concurrent
> > maps can't be accommodated. The main one is that if
> > map.get(key) returns null, you can't detect whether the
> > key explicitly maps to null vs the key isn't mapped.
> > In a non-concurrent map, you can check this via map.contains(key),
> > but in a concurrent one, the map might have changed between calls.
> >
> > Further digressing: I personally think that allowing
> > nulls in Maps (also Sets) is an open invitation for programs
> > to contain errors that remain undetected until
> > they break at just the wrong time. (Whether to allow nulls even
> > in non-concurrent Maps/Sets is one of the few design issues surrounding
> > Collections that Josh Bloch and I have long disagreed about.)
>
>
> Josh Bloch wrote: [2]
>
> > I have moved towards your position over the years.  It was probably a
> > mistake to allow null keys in Maps and null elements in Sets.  I'm
> > still not sure about Map values and List elements.
> >
> > In other words, Doug hates null more than I do, but over the years
> > I've come to see it as quite troublesome.
>
>
> (I haven't talked to Josh or Doug about this particular issue recently, so
> I suppose
> it's possible their opinions have changed in the intervening time.)
>
> I had to decide what to do about nulls when I added the unmodifiable
> collections in
> JDK 9. Given that Doug "hates" nulls, and Josh finds them at least quite
> troublesome, I started from a position of disallowing null members in all
> the new
> collections. Most of the unmodifiable collections are still this way (but
> see below).
>
> What about contains(null)? Surely it should be ok to query for a null, and
> return
> false, even if the collection itself can't contain null. However, a bunch
> of
> collections and collection views in the JDK throw NPE on contains(null),
> so the
> unmodifiable collections don't set a precedent here.
>
> If you're dealing with all non-null values, and a null creeps in somehow,
> then
> calling contains(null) might be an error, and it would be good for the
> library to
> inform you of that instead of just returning false and letting the program
> continue
> until it fails later (fail-fast). A similar issue arises with the
> non-generic
> contains() method. If you have a Collection<Integer>, then shouldn't
> contains("abc")
> be an error? It's not, and it simply returns false, because the signature
> is
> contains(Object). But there have been complaints that this should have
> been an error
> because a Collection of Integer cannot possibly contain a String. Similar
> reasoning
> applies to contains(null) on a collection that can't contain null. (Yes,
> the error
> occurs at runtime instead of compile time, but better late than never.)
>
> A meta-issue is: should a new thing correct a perceived design flaw in the
> older
> thing, or should it be consistent with the old thing? Either way, you lose.
>
> Another factor in my original decision was that it's much easier to start
> with a
> restriction and relax it later than it is to go the other way. We have
> some
> flexibility to allow nulls and contains(null) if we want; but it's
> essentially a
> non-starter to disallow nulls once they've been allowed somewhere.
>
> That's why my starting position for the design prohibited nulls everywhere.
>
> Over time we've relaxed some restrictions around null handling in the
> unmodifiable
> collections. Streams permit nulls, and the List returned from
> Stream.toList() also
> permits nulls, and it also allows contains(null). So there's a different
> unmodifiable List implementation under there, accessible only via streams.
> (Note
> that the null-permitting unmodifiable lists lose the optimizations for
> sizes 0, 1,
> and 2, which are in part based on nulls being disallowed.)
>
> I'm fairly sympathetic to the case for changing the unmodifiable
> collections to
> allow contains(null), given that the current NPE-throwing behavior has
> generated a
> fair amount of complaints over the years. And the situation with having
> two flavors
> of unmodifiable list is quite odd and is an uncomfortable point in the
> design space.
>
> I should point out however that even if the unmodifiable collections were
> changed to
> allow contains(null), it's still kind of unclear as to whether this code
> is safe:
>
>    public void addShoppingItems(Collection<String> shoppingItems) {
>      if (shoppingItems.contains(null)) {  // this looks quite reasonable
> and safe...
>        throw new IllegalArgumentException("shoppingItems should not
> contain nulls");
>      }
>      ...
>    }
>
> If you're only ever passing ArrayList, Arrays.asList(), and List.of()
> lists here,
> then sure, this would work great. If the source collection is of unknown
> provenance,
> you can still run into trouble:
>
> 1. contains(null) calls on the keySet and values collections of
> ConcurrentHashMap
> and Hashtable all throw NPE. So does contains(null) on a set from
> Collections.newSetFromMap(), which is built from those maps' keySets. (I
> suppose
> Doug Lea might be convinced to relax the CHM behavior.)
>
> 2. Speaking of concurrency, if the source collection is being modified
> concurrently,
> then a null could be introduced after the check (TOCTOU) so you'd need to
> make a
> defensive copy before checking it.
>
> 3. NavigableSet and friends delegate contains() to the comparison method,
> which
> might or might not accept nulls. There's no way the collection
> implementation can
> tell in advance.
>
> You might consider List.copyOf() as an alternative, as that makes a
> null-free
> defensive copy in one shot, and avoids copying if the source is an
> unmodifiable
> list. If you don't care about concurrency, then
>
>      shoppingItems.forEach(Objects::requireNonNull)
>
> might be suitable.
>
> If unmodifiable collections were to change to allow contains(null), this
> probably
> would make them somewhat less annoying, but it wouldn't necessarily solve
> yours or
> everyone's problems. There's simply no way at this point to make the
> collections'
> treatment of nulls uniform.
>
> s'marks
>
>
> [1]
>
> https://web.archive.org/web/20210510190135/https://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002485.html
>
> [2]
>
> https://web.archive.org/web/20200930213909/http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002486.html
>
>
>
>
> On 1/29/23 7:28 AM, John Hendrikx wrote:
> > TLDR; why does contains(null) not just return false for collections that
> don't allow
> > nulls. Just because the interface allows it, does not mean it should do
> it as it
> > devalues the usefulness of the abstraction provided by the interface.
> >
> > Background:
> >
> > I'm someone that likes to check correctness of any constructor or method
> parameter
> > before allowing an object to be constructed or to be modified, in order
> to maintain
> > invariants that are provided by the class to its users.
> >
> > This ranges from simple null checks, to range checks on numeric values,
> to complete
> > checks like "is a collection sorted" or is a list of nodes acyclic.
> Anything I can
> > check in the constructor that may avoid problems further down the line
> or that may
> > affect what I can guarantee on its own API methods.  For example, if I
> check in the
> > constructor that something is not null, then the associated getter will
> guarantee
> > that the returned value is not null.  If I check that a List doesn't
> contain nulls,
> > then the associated getter will reflect that as well (assuming it is
> immutable or
> > defensivily copied).
> >
> > For collections, this is currently becoming harder and harder because
> more and more
> > new collections are written to be null hostile.  It is fine if a
> collection doesn't
> > accept nulls, but throwing NPE when I ask such a collection if it
> contains null
> > seems to be counter productive, and reduces the usefulness of the
> collection
> > interfaces.
> >
> > This strict interpretation makes the collection interfaces harder to use
> than
> > necessary. Interfaces are only useful when their contract is well
> defined. The more
> > things an interface allows or leaves unspecified, the less useful it is
> for its users.
> >
> > I know that the collection interfaces allow this, but you have to ask
> yourself this
> > important question: how useful is an interface that makes almost no
> guarantees about
> > what its methods will do? Interfaces like `List`, `Map` and `Set` are
> passed as
> > method parameters a lot, and to make these useful, implementations of
> these
> > interfaces should do their best to provide as consistent an experience
> as is
> > reasonably possible. The alternative is that these interfaces will
> slowly decline in
> > usefulness as methods will start asking for `ArrayList` instead of
> `List` to avoid
> > having to deal with a too lenient specification.
> >
> > With the collection interfaces I get the impression that recently there
> has been too
> > much focus on what would be easy for the collection implementation
> instead of what
> > would be easy for the users of said interfaces. In my opinion, the
> concerns of the
> > user of interfaces almost always far outweigh the concerns of the
> implementors of
> > said interfaces.
> >
> > In the past, immutable collections were rare, but they get are getting
> more and more
> > common all the time.  For example, in unit testing. Unfortunately, these
> immutable
> > collections differ quite a bit from their mutable counterparts.  Some
> parts are only
> > midly annoying (not accepting `null` as the **value** in a `Map` for
> example), but
> > other parts require code to be rewritten for it to be able to work as a
> drop-in
> > replacement for the mutable variant. A simple example is this:
> >
> >      public void addShoppingItems(Collection<String> shoppingItems) {
> >          if (shoppingItems.contains(null)) {  // this looks quite
> reasonable and
> > safe...
> >              throw new IllegalArgumentException("shoppingItems should
> not contain
> > nulls");
> >          }
> >
> >          this.shoppingItems.addAll(shoppingItems);
> >      }
> >
> > Testing this code is annoying:
> >
> >       x.addShoppingItems(List.of("a", null"));   // can't construct
> immutable
> > collection with null
> >
> >       x.addShoppingItems(Arrays.asList("a", null"));  // fine, go back
> to what we
> > did before then...
> >
> > The above problems, I suppose we can live with it; immutable collections
> don't want
> > `null` although I don't see any reason to not allow it as I can write a
> similar
> > `List.of` that returns immutable collections that do allow `null`. For
> JDK code this
> > is a bit disconcerting, as it is supposed to be as flexible as is
> reasonable without
> > having too much of an opinion about what is good or bad.
> >
> > This next one however:
> >
> >       assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a",
> "b")));  // not
> > allowed, contains(null) in application code throws NPE
> >
> > This is much more insidious; the `contains(null)` check has been a very
> practical
> > way to check if collections contain null, and this works for almost all
> collections
> > in common use, so there is no problem.  But now, more and more
> collections are
> > starting to just throw NPE immediately even just to **check** if a null
> element is
> > present. This only serves to distinguish themselves loudly from other
> similar
> > collections that will simply return `false`.
> >
> > I think this behavior is detrimental to the java collection interfaces
> in general,
> > especially since there is a clear answer to the question if such a
> collection
> > contains null or not. In fact, why `contains` was ever allowed to throw
> an exception
> > aside from "UnsupportedOperationException" is a mystery to me, and
> throwing one when
> > one could just as easily return the correct and expected answer seems
> very opiniated
> > and almost malicious -- not behavior I'd expect from JDK core libraries.
> >
> > Also note that there is no way to know in advance if `contains(null)` is
> going to be
> > throwing the NPE. If interfaces had a method `allowsNulls()` that would
> already be
> > an improvement.
> >
> > --John
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230201/9a160cf4/attachment-0001.htm>

From mandy.chung at oracle.com  Tue Jan 31 21:21:39 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 31 Jan 2023 13:21:39 -0800
Subject: module opens directive and Lookup::defineClass
In-Reply-To: <CAPs6151RJSd71PKNVj+AhjwHOP8riyxbtBQNHY935ogb5sxoaQ@mail.gmail.com>
References: <CAPs6151RJSd71PKNVj+AhjwHOP8riyxbtBQNHY935ogb5sxoaQ@mail.gmail.com>
Message-ID: <53fe273d-7e1c-324c-4bc1-f9ddbcebc821@oracle.com>

There is no conflict with JLS 7.2.2 as I can see.

Opens `some.package` to `some.other.module` means just one package.? 
It's true that the open packages can be extended at runtime. For 
example, `some.other.module` can update this module to open the package 
to another module at runtime via `Module::addOpens` and even 
`Instrumentation::redefineModule` and `--add-opens` command-line option.

Module maintainers should always be very careful open any package and 
only open packages to trusted frameworks.

Mandy

On 1/30/23 11:32 AM, Kasper Nielsen wrote:
> Hi,
>
> I just saw the pull request for 8217920 (Lookup.defineClass injects a class
> that can access private members of any class in its own module.)
>
> The PR details how you can generate a class in a package that has been opened
> to you via a module declaration. This generated class can then create a new
> lookup object with full privileged access and pass it back to you. You can
> then use this lookup object to reflective access *any* class in the module,
> not only the packages that were opened to you.
>
> In practice, this now means that the opens package directive is a wildcard
> directive.
>
> module mymodule {   opens some.package to some.other.module; }
>
> means
>
> module mymodule {   opens *all-my-packages* to some.other.module; }
>
> Which conflicts with JLS 7.7.2. Exported and Opened Packages that says:
>
> The opens directive specifies the name of a package to be opened by the
> current module. For code in other modules, this grants access at run time,
> but not compile time, to the public and protected types in the package, and
> the public and protected members of those types. It also grants reflective
> access to all types in the package, and all their members, for code in other
> modules.
>
> I understand the need to be backward compatible. But I find this behavior
> of 'opens' surprising given that the directive takes a package name.
> Also, the paragraph does say anything about granting the right to define new
> classes in the package. It only talks about reflective access.
>
> For those that are curious. I've made a simple demo that exploits this here
> [1]. It takes a Lookup object and a class and will return a private lookup
> object to the specified class if there is at least one open clause from the
> module (of the specified class) to the caller. Irregardless if the specified
> class is in an open package.
>
> /Kasper
>
> [1] https://gist.github.com/kaspernielsen/e072a38654d63f2918540e24e9d0380e

From forax at univ-mlv.fr  Tue Jan 31 21:28:50 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 31 Jan 2023 22:28:50 +0100 (CET)
Subject: NPE throwing behavior of immutable collections
In-Reply-To: <CAJL5A3nkfU=ZNLCy8rNtHvDes8cmr97qKc8KFsN-jNjhe+HGDA@mail.gmail.com>
References: <c7da6f1c-0f36-3e92-21d7-ad826c22f07d@gmail.com>
 <7bf6c2ae-03a5-5838-e7fe-8112741497dc@oracle.com>
 <CAJL5A3nkfU=ZNLCy8rNtHvDes8cmr97qKc8KFsN-jNjhe+HGDA@mail.gmail.com>
Message-ID: <1468443717.9701025.1675200530340.JavaMail.zimbra@u-pem.fr>

> From: "Glavo" <zjx001202 at gmail.com>
> To: "Stuart Marks" <stuart.marks at oracle.com>
> Cc: "John Hendrikx" <john.hendrikx at gmail.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Tuesday, January 31, 2023 10:12:24 PM
> Subject: Re: NPE throwing behavior of immutable collections

> I understand that null is prohibited by default, but can we also provide a set
> of factory methods that accept null?
> They can be named like List.ofNullable/copyOfNullable.

It is actually spelt, Arrays.asList() and collection.stream().toList(). 

R?mi 

> On Tue, Jan 31, 2023 at 10:13 AM Stuart Marks < [ mailto:stuart.marks at oracle.com
> | stuart.marks at oracle.com ] > wrote:

>> In this reply I'll focus on the null handling issues in collections.

>> As you've noted, there are really (at least) two distinct issues here: whether a
>> collection permits nulls, and the behavior of contains(null) queries. There have
>> been continual complaints about both, and the issues are somewhat distinct.

>> The collection implementations in the JDK are all over the place with regard to
>> nulls. I believe this is because the original collections and the concurrent
>> collections up through JDK 1.6 or so were mostly done by Josh Bloch and Doug
>> Lea,
>> who disagreed about null handling. They had this exchange in 2006:

>> Doug Lea wrote: [1]

>> > The main reason that nulls aren't allowed in ConcurrentMaps
>> > (ConcurrentHashMaps, ConcurrentSkipListMaps) is that
>> > ambiguities that may be just barely tolerable in non-concurrent
>> > maps can't be accommodated. The main one is that if
>> > map.get(key) returns null, you can't detect whether the
>> > key explicitly maps to null vs the key isn't mapped.
>> > In a non-concurrent map, you can check this via map.contains(key),
>> > but in a concurrent one, the map might have changed between calls.

>> > Further digressing: I personally think that allowing
>> > nulls in Maps (also Sets) is an open invitation for programs
>> > to contain errors that remain undetected until
>> > they break at just the wrong time. (Whether to allow nulls even
>> > in non-concurrent Maps/Sets is one of the few design issues surrounding
>> > Collections that Josh Bloch and I have long disagreed about.)

>> Josh Bloch wrote: [2]

>> > I have moved towards your position over the years. It was probably a
>> > mistake to allow null keys in Maps and null elements in Sets. I'm
>> > still not sure about Map values and List elements.

>> > In other words, Doug hates null more than I do, but over the years
>> > I've come to see it as quite troublesome.

>> (I haven't talked to Josh or Doug about this particular issue recently, so I
>> suppose
>> it's possible their opinions have changed in the intervening time.)

>> I had to decide what to do about nulls when I added the unmodifiable collections
>> in
>> JDK 9. Given that Doug "hates" nulls, and Josh finds them at least quite
>> troublesome, I started from a position of disallowing null members in all the
>> new
>> collections. Most of the unmodifiable collections are still this way (but see
>> below).

>> What about contains(null)? Surely it should be ok to query for a null, and
>> return
>> false, even if the collection itself can't contain null. However, a bunch of
>> collections and collection views in the JDK throw NPE on contains(null), so the
>> unmodifiable collections don't set a precedent here.

>> If you're dealing with all non-null values, and a null creeps in somehow, then
>> calling contains(null) might be an error, and it would be good for the library
>> to
>> inform you of that instead of just returning false and letting the program
>> continue
>> until it fails later (fail-fast). A similar issue arises with the non-generic
>> contains() method. If you have a Collection<Integer>, then shouldn't
>> contains("abc")
>> be an error? It's not, and it simply returns false, because the signature is
>> contains(Object). But there have been complaints that this should have been an
>> error
>> because a Collection of Integer cannot possibly contain a String. Similar
>> reasoning
>> applies to contains(null) on a collection that can't contain null. (Yes, the
>> error
>> occurs at runtime instead of compile time, but better late than never.)

>> A meta-issue is: should a new thing correct a perceived design flaw in the older
>> thing, or should it be consistent with the old thing? Either way, you lose.

>> Another factor in my original decision was that it's much easier to start with a
>> restriction and relax it later than it is to go the other way. We have some
>> flexibility to allow nulls and contains(null) if we want; but it's essentially a
>> non-starter to disallow nulls once they've been allowed somewhere.

>> That's why my starting position for the design prohibited nulls everywhere.

>> Over time we've relaxed some restrictions around null handling in the
>> unmodifiable
>> collections. Streams permit nulls, and the List returned from Stream.toList()
>> also
>> permits nulls, and it also allows contains(null). So there's a different
>> unmodifiable List implementation under there, accessible only via streams. (Note
>> that the null-permitting unmodifiable lists lose the optimizations for sizes 0,
>> 1,
>> and 2, which are in part based on nulls being disallowed.)

>> I'm fairly sympathetic to the case for changing the unmodifiable collections to
>> allow contains(null), given that the current NPE-throwing behavior has generated
>> a
>> fair amount of complaints over the years. And the situation with having two
>> flavors
>> of unmodifiable list is quite odd and is an uncomfortable point in the design
>> space.

>> I should point out however that even if the unmodifiable collections were
>> changed to
>> allow contains(null), it's still kind of unclear as to whether this code is
>> safe:

>> public void addShoppingItems(Collection<String> shoppingItems) {
>> if (shoppingItems.contains(null)) { // this looks quite reasonable and safe...
>> throw new IllegalArgumentException("shoppingItems should not contain nulls");
>> }
>> ...
>> }

>> If you're only ever passing ArrayList, Arrays.asList(), and List.of() lists
>> here,
>> then sure, this would work great. If the source collection is of unknown
>> provenance,
>> you can still run into trouble:

>> 1. contains(null) calls on the keySet and values collections of
>> ConcurrentHashMap
>> and Hashtable all throw NPE. So does contains(null) on a set from
>> Collections.newSetFromMap(), which is built from those maps' keySets. (I suppose
>> Doug Lea might be convinced to relax the CHM behavior.)

>> 2. Speaking of concurrency, if the source collection is being modified
>> concurrently,
>> then a null could be introduced after the check (TOCTOU) so you'd need to make a
>> defensive copy before checking it.

>> 3. NavigableSet and friends delegate contains() to the comparison method, which
>> might or might not accept nulls. There's no way the collection implementation
>> can
>> tell in advance.

>> You might consider List.copyOf() as an alternative, as that makes a null-free
>> defensive copy in one shot, and avoids copying if the source is an unmodifiable
>> list. If you don't care about concurrency, then

>> shoppingItems.forEach(Objects::requireNonNull)

>> might be suitable.

>> If unmodifiable collections were to change to allow contains(null), this
>> probably
>> would make them somewhat less annoying, but it wouldn't necessarily solve yours
>> or
>> everyone's problems. There's simply no way at this point to make the
>> collections'
>> treatment of nulls uniform.

>> s'marks

>> [1]
>> [
>> https://web.archive.org/web/20210510190135/https://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002485.html
>> |
>> https://web.archive.org/web/20210510190135/https://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002485.html
>> ]

>> [2]
>> [
>> https://web.archive.org/web/20200930213909/http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002486.html
>> |
>> https://web.archive.org/web/20200930213909/http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/002486.html
>> ]

>> On 1/29/23 7:28 AM, John Hendrikx wrote:
>>> TLDR; why does contains(null) not just return false for collections that don't
>> > allow
>> > nulls. Just because the interface allows it, does not mean it should do it as it
>> > devalues the usefulness of the abstraction provided by the interface.

>> > Background:

>>> I'm someone that likes to check correctness of any constructor or method
>> > parameter
>>> before allowing an object to be constructed or to be modified, in order to
>> > maintain
>> > invariants that are provided by the class to its users.

>>> This ranges from simple null checks, to range checks on numeric values, to
>> > complete
>>> checks like "is a collection sorted" or is a list of nodes acyclic. Anything I
>> > can
>>> check in the constructor that may avoid problems further down the line or that
>> > may
>>> affect what I can guarantee on its own API methods. For example, if I check in
>> > the
>>> constructor that something is not null, then the associated getter will
>> > guarantee
>>> that the returned value is not null. If I check that a List doesn't contain
>> > nulls,
>>> then the associated getter will reflect that as well (assuming it is immutable
>> > or
>> > defensivily copied).

>>> For collections, this is currently becoming harder and harder because more and
>> > more
>>> new collections are written to be null hostile. It is fine if a collection
>> > doesn't
>> > accept nulls, but throwing NPE when I ask such a collection if it contains null
>> > seems to be counter productive, and reduces the usefulness of the collection
>> > interfaces.

>> > This strict interpretation makes the collection interfaces harder to use than
>>> necessary. Interfaces are only useful when their contract is well defined. The
>> > more
>>> things an interface allows or leaves unspecified, the less useful it is for its
>> > users.

>>> I know that the collection interfaces allow this, but you have to ask yourself
>> > this
>>> important question: how useful is an interface that makes almost no guarantees
>> > about
>> > what its methods will do? Interfaces like `List`, `Map` and `Set` are passed as
>> > method parameters a lot, and to make these useful, implementations of these
>> > interfaces should do their best to provide as consistent an experience as is
>>> reasonably possible. The alternative is that these interfaces will slowly
>> > decline in
>>> usefulness as methods will start asking for `ArrayList` instead of `List` to
>> > avoid
>> > having to deal with a too lenient specification.

>>> With the collection interfaces I get the impression that recently there has been
>> > too
>>> much focus on what would be easy for the collection implementation instead of
>> > what
>>> would be easy for the users of said interfaces. In my opinion, the concerns of
>> > the
>>> user of interfaces almost always far outweigh the concerns of the implementors
>> > of
>> > said interfaces.

>>> In the past, immutable collections were rare, but they get are getting more and
>> > more
>>> common all the time. For example, in unit testing. Unfortunately, these
>> > immutable
>>> collections differ quite a bit from their mutable counterparts. Some parts are
>> > only
>>> midly annoying (not accepting `null` as the **value** in a `Map` for example),
>> > but
>> > other parts require code to be rewritten for it to be able to work as a drop-in
>> > replacement for the mutable variant. A simple example is this:

>> > public void addShoppingItems(Collection<String> shoppingItems) {
>> > if (shoppingItems.contains(null)) { // this looks quite reasonable and
>> > safe...
>> > throw new IllegalArgumentException("shoppingItems should not contain
>> > nulls");
>> > }

>> > this.shoppingItems.addAll(shoppingItems);
>> > }

>> > Testing this code is annoying:

>> > x.addShoppingItems(List.of("a", null")); // can't construct immutable
>> > collection with null

>> > x.addShoppingItems(Arrays.asList("a", null")); // fine, go back to what we
>> > did before then...

>>> The above problems, I suppose we can live with it; immutable collections don't
>> > want
>> > `null` although I don't see any reason to not allow it as I can write a similar
>>> `List.of` that returns immutable collections that do allow `null`. For JDK code
>> > this
>>> is a bit disconcerting, as it is supposed to be as flexible as is reasonable
>> > without
>> > having too much of an opinion about what is good or bad.

>> > This next one however:

>> > assertNoExceptionThrown(() -> x.addShoppingItems(List.of("a", "b"))); // not
>> > allowed, contains(null) in application code throws NPE

>>> This is much more insidious; the `contains(null)` check has been a very
>> > practical
>>> way to check if collections contain null, and this works for almost all
>> > collections
>> > in common use, so there is no problem. But now, more and more collections are
>>> starting to just throw NPE immediately even just to **check** if a null element
>> > is
>> > present. This only serves to distinguish themselves loudly from other similar
>> > collections that will simply return `false`.

>>> I think this behavior is detrimental to the java collection interfaces in
>> > general,
>> > especially since there is a clear answer to the question if such a collection
>>> contains null or not. In fact, why `contains` was ever allowed to throw an
>> > exception
>>> aside from "UnsupportedOperationException" is a mystery to me, and throwing one
>> > when
>>> one could just as easily return the correct and expected answer seems very
>> > opiniated
>> > and almost malicious -- not behavior I'd expect from JDK core libraries.

>>> Also note that there is no way to know in advance if `contains(null)` is going
>> > to be
>>> throwing the NPE. If interfaces had a method `allowsNulls()` that would already
>> > be
>> > an improvement.

>> > --John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230131/40bd91b1/attachment-0001.htm>

From bhuang at openjdk.org  Tue Jan 31 22:15:00 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 22:15:00 GMT
Subject: Integrated: JDK-8300909: Update com/sun/jndi/dns/Test6991580.java
 manual test instruction
In-Reply-To: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
References: <hD3ds0YNOKwiruM8U3Ey8dxw9qGh-7GAYq5Zo7Ml5h4=.a814f4ba-b392-4672-bd81-1732bc5c1dc0@github.com>
Message-ID: <K9oasEs7wq4WX6bX3ss0PTvJLAzThxgSNLAsMLWNBuI=.03ea3c51-b08b-4b71-b4f9-4b7ae0eb3179@github.com>

On Tue, 31 Jan 2023 19:08:08 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> Test failed for exception in thread "main" java.lang.IllegalAccessError: class IPv6NameserverPlatformParsingTest (in unnamed module @0x72a8ab1a) cannot access class com.sun.jndi.dns.DnsContextFactory (in module jdk.naming.dns) because module jdk.naming.dns does not export com.sun.jndi.dns to unnamed module @0x72a8ab1a
> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:46)
> 
> This task is created to update test instruction to include --add-modules and --add-opens jvm parameters to java command.

This pull request has now been integrated.

Changeset: 09bfbf80
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09bfbf80639f059563fcd4432995b8c380cea298
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8300909: Update com/sun/jndi/dns/Test6991580.java manual test instruction

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12351

From darcy at openjdk.org  Tue Jan 31 22:21:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Jan 2023 22:21:51 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v7]
In-Reply-To: <nOpniQff5eA8HQLfs3OlhcJUvYCK29-RF41KNkbyc-I=.ad311826-3f61-46f2-b5c5-6a8015067bfc@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <nOpniQff5eA8HQLfs3OlhcJUvYCK29-RF41KNkbyc-I=.ad311826-3f61-46f2-b5c5-6a8015067bfc@github.com>
Message-ID: <p3INCZYlaAZF00qaPkL5OOF079XlElugdRDOe3vEXUo=.b4fc5759-7387-4521-8c15-424980d44c8c@github.com>

On Tue, 31 Jan 2023 18:30:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 28:

> 26: package jdk.internal.math;
> 27: 
> 28: public final class FormattedFPDecimal {

I suggest adding a short explanation of what this class is used for.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From duke at openjdk.org  Tue Jan 31 22:39:01 2023
From: duke at openjdk.org (duke)
Date: Tue, 31 Jan 2023 22:39:01 GMT
Subject: Withdrawn: 8291917: Windows - Improve error messages when the C
 Runtime Libraries or jvm.dll cannot be loaded
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <D2dkId5Z_fWBeULZhRCBztVyXKAHl5v0-xoWqva2umo=.fb1f9e83-2745-46c1-9a33-18b489f72f62@github.com>

On Thu, 4 Aug 2022 16:26:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
> 
> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From bhuang at openjdk.org  Tue Jan 31 22:41:40 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 22:41:40 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when home
 directory is read-only
Message-ID: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>

Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

-------------

Commit messages:
 - JDK-8299994 java/security/Policy/Root/Root.java fails when home directory is read-only

Changes: https://git.openjdk.org/jdk/pull/12354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12354&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299994
  Stats: 18 lines in 3 files changed: 15 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12354/head:pull/12354

PR: https://git.openjdk.org/jdk/pull/12354

From rhalade at openjdk.org  Tue Jan 31 22:50:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 31 Jan 2023 22:50:51 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <qcD10oysBJ_UU3vouX2poE6s5O9OkNOwg0R9qW043Rc=.a896cdc1-03e8-4a41-bb6b-33bfab8f83e3@github.com>

On Tue, 31 Jan 2023 22:35:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

test/jdk/java/security/Policy/Root/Root.java line 34:

> 32: 
> 33: /*
> 34: * Run test as root user.

Can you print set of instructions to run test as root? Also it will help if test fails when not run as root to begin with.

-------------

PR: https://git.openjdk.org/jdk/pull/12354

From bhuang at openjdk.org  Tue Jan 31 23:14:11 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 31 Jan 2023 23:14:11 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v2]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <CnOrGIC3fKTifkgEx2dT9Hk8Z9AXzXHwufNoj04eYmQ=.d37e58be-65cf-4284-8a30-589f6b08f135@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/69a7a490..60096f09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12354&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12354&range=00-01

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12354/head:pull/12354

PR: https://git.openjdk.org/jdk/pull/12354

From kasperni at gmail.com  Tue Jan 31 23:31:22 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Tue, 31 Jan 2023 23:31:22 +0000
Subject: module opens directive and Lookup::defineClass
In-Reply-To: <53fe273d-7e1c-324c-4bc1-f9ddbcebc821@oracle.com>
References: <CAPs6151RJSd71PKNVj+AhjwHOP8riyxbtBQNHY935ogb5sxoaQ@mail.gmail.com>
 <53fe273d-7e1c-324c-4bc1-f9ddbcebc821@oracle.com>
Message-ID: <CAPs6152dobodsLJ0OyaXuo+cJFO1uPcp_LL6Aario1vtFWTdKQ@mail.gmail.com>

On Tue, 31 Jan 2023 at 21:21, <mandy.chung at oracle.com> wrote:
>
> There is no conflict with JLS 7.2.2 as I can see.

Thanks for getting back to me.

Maybe there isn't a direct conflict. But I still think this is not very
intuitive.

If I have an application with two packages:
    com.acme.foreveryone
    com.acme.secret

And I have the following module descriptor:

module acme {
    opens com.acme.foreveryone to someapp
}

As a user, I would assume that someapp would not have access to classes
in 'com.acme.secret'. While in fact, someapp can just define a class in
com.acme.foreveryone. And then use the generated class to create a lookup
object that can access everything in com.acme.secret.

In practice open only works on the module level now. You cannot restrict open
to only certain packages in a module anymore. But the language gives you that
impression because it allows you to specify which packages to open in a
module descriptor.

I have no problem with that. I do think having to specify every package to
open is maybe a bit too fine-grained in practice. But I just don't see the
point in having the 'opens package to module' construct any more than. Why not
just have 'opens to module' that opens every package in a module to another
module? The same goes for --add-opens why do I need to specify the names of
the packages to open? When one open package allows you to access every other
package in the module. Much easier just to specify the module without packages.

/Kasper


/Kasper

From lance.andersen at oracle.com  Tue Jan 31 23:41:36 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Jan 2023 23:41:36 +0000
Subject: ZIP entry copy without recompression
In-Reply-To: <CA+pBWhtGWR4yyw26Or9XO3LJuHitqgJeoU_rS8Y_HguUMuN29g@mail.gmail.com>
References: <CA+pBWhtGWR4yyw26Or9XO3LJuHitqgJeoU_rS8Y_HguUMuN29g@mail.gmail.com>
Message-ID: <8E935EC2-9958-4043-863F-13F27B3D50F9@oracle.com>

I have not add a chance to look or think about this yet but wanted to know I will

On Jan 19, 2023, at 2:03 PM, Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

Hi,

A common use case for java.util.zip in build tools involves copying
entries from a ZipFile or ZipInputStream to a ZipOutputStream without
actually modifying the data.

Example use cases include minification (make a JAR with only the
reachable classes) and merging (combine several JAR files into one
uberjar).

Inflating an entry just to immediately deflate it again with no
modifications seems wasteful.

The following draft PR introduces
ZipFileInflaterInputStream.transferTo which copies compressed ZipFile
data directly to ZipOutputStream's raw data stream:

https://github.com/openjdk/jdk/pull/12099

I'm typically seeing a 15 X improvement when copying xalan.jar to a
ZipOutputStream backed by a buffered FileOutputStream, or 22 X when
backed by OutputStream.nullOutputStream().

The PR current stays completely on the happy path and is mostly there
to experiment and to show the potential performance benefits. There is
currently not much focus on validation or correctness. Copying files
to a different path is not supported, neither is copying from a
ZipInputStream.

I initially considered creating new methods for raw copies, but opted
to minimize changes to public APIs, that's why I'm overriding
transferTo.

The PR is not intended for regular review, but as a starting point for
a discussion about the usefulness of the idea and the general solution
space. If we can reach consensus on such a discussion, I'll probably
be happy to work on a more complete PR.

Cheers,
Eirik.

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230131/08114047/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230131/08114047/oracle_sig_logo-0001.gif>