From psandoz at openjdk.java.net  Wed Dec  1 00:10:29 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 1 Dec 2021 00:10:29 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
Message-ID: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>

On Wed, 24 Nov 2021 15:20:42 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> Some benchmark results, run on my 1-6-2 server:
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
>> 
>> 
>> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made forkOrInvoke() method protected to avoid strange compiler error

IIRC you are not overly concerned about the additional object creation of `RecursiveOp` instances?

If that changes the operation method could return `Object` and choose to perform the operation directly returning the `BigInteger` result or returning the particular `RecursiveOp`.


private static Object multiply(BigInteger a, BigInteger b, boolean parallel, int depth) {
    if (isParallel(parallel, depth)) {
        return new RecursiveMultiply(a, b, parallel, depth).fork();
    } else {
        // Also called by RecursiveMultiply.compute()
        return RecursiveMultiply.compute(a, b, false, depth);
    }
}


Then we could have another method on `RecursiveOp` that pattern matches e.g.:

  static BigInteger join(Object o) {
    // replace with pattern match switch when it exits preview
    if (o instanceof BigInteger b) {
        return b;
    } else if (o instanceof RecursiveOp r) {
        return r.join();
    } else {
        throw new InternalError("Cannot reach here);
    }
  }


That seems simple enough it might be worth doing anyway.

src/java.base/share/classes/java/math/BigInteger.java line 1874:

> 1872:          */
> 1873:         private static final int PARALLEL_FORK_THRESHOLD = Integer.getInteger(
> 1874:                 "java.math.BigInteger.parallelForkThreshold",

I suspect we don't need this system property, there is no such property for streams. We use `ForkJoinPool.getCommonPoolParallelism()`, which is configurable as an escape hatch.

src/java.base/share/classes/java/math/BigInteger.java line 1875:

> 1873:         private static final int PARALLEL_FORK_THRESHOLD = Integer.getInteger(
> 1874:                 "java.math.BigInteger.parallelForkThreshold",
> 1875:                 (int) Math.ceil(Math.log(Runtime.getRuntime().availableProcessors()) / Math.log(2)));

We can simplify to `32 - Integer.numberOfLeadingZeros(ForkJoinPool.getCommonPoolParallelism() - 1))`.

`ForkJoinPool.getCommonPoolParallelism()` is guaranteed to return a value `> 0`

src/java.base/share/classes/java/math/BigInteger.java line 1878:

> 1876: 
> 1877:         @Serial
> 1878:         private static final long serialVersionUID = 0L;

I don't think you need to declare these, the instances are never intended to support serialization e.g. in the stream implementation for `AbstractTask` that extends `CountedCompleter` we state:

 * <p>Serialization is not supported as there is no intention to serialize
 * tasks managed by stream ops.

src/java.base/share/classes/java/math/BigInteger.java line 1909:

> 1907:             @Override
> 1908:             public BigInteger compute() {
> 1909:                 return a.multiply(b, true, super.parallel, super.depth);

Using `super.` is a little unusual, it's not wrong :-) but not really idiomatic in the source code base.

src/java.base/share/classes/java/math/BigInteger.java line 1930:

> 1928:         }
> 1929: 
> 1930:         private static RecursiveTask<BigInteger> exec(RecursiveOp op) {

Unused.

src/java.base/share/classes/java/math/BigInteger.java line 2000:

> 1998:         da1 = a2.add(a0);
> 1999:         db1 = b2.add(b0);
> 2000:         var vm1_task = RecursiveOp.multiply(da1.subtract(a1), db1.subtract(b1), parallel, depth + 1);

I recommend incrementing the depth in the `RecursiveOp` constructor, thereby reducing the repetition.

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

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

From jgneff at openjdk.java.net  Wed Dec  1 01:13:34 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 01:13:34 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
Message-ID: <JQI9alrV07UylaqRy5EPntjy0A_xI6Xob9wsVIW1QD4=.61f927b8-3cb1-4779-a41e-af45748029e7@github.com>

On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Here is the 32-line Java program that I've been modifying to find problems and solutions:


import java.io.FileOutputStream;
import java.io.IOException;
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.temporal.ChronoUnit;
import java.util.TimeZone;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class Time {

    static void writeZipFile(String name, ZipEntry entry) throws IOException {
        var output = new ZipOutputStream(new FileOutputStream(name));
        output.putNextEntry(entry);
        output.closeEntry();
        output.close();
    }

    public static void main(String[] args) throws IOException {
        var instant = Instant.now().truncatedTo(ChronoUnit.SECONDS);
        if (args.length > 0) {
            instant = Instant.parse(args[0]);
        }
        System.out.println("Build timestamp = " + instant);

        var entry = new ZipEntry("Entry");
        var local = LocalDateTime.ofInstant(instant, ZoneOffset.UTC);

        TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
        entry.setTimeLocal(local);
        writeZipFile("Zipped_in_Nome.zip", entry);

        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
        entry.setTimeLocal(local);
        writeZipFile("Zipped_in_Rome.zip", entry);
    }
}


For example, first I pick up the timestamp of the last commit in my JavaFX fork:


$ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
$ date --date=@$SOURCE_DATE_EPOCH --iso-8601=seconds --utc
2021-11-22T05:00:22+00:00
$ git log -1 --pretty=%cI
2021-11-21T21:00:22-08:00


Then I can verify that the timestamp in the archive is unaffected by the default time zone of the JVM:


$ java Time 2021-11-21T21:00:22-08:00
Build timestamp = 2021-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22


Even when I create the ISO 8601 date and time string on a system in a different time zone than the two simulated build machines in Nome and Rome, it still works:


$ java Time 2021-11-22T08:00:22+03:00
Build timestamp = 2021-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22


But it all falls apart when we venture outside the permitted DOS date and time range:


$ java Time 1975-11-22T05:00:22+00:00
Build timestamp = 1975-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1975 Nov 22 08:00:22 local
  file last modified on (UT extra field modtime): 1975 Nov 22 16:00:22 UTC
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1975 Nov 21 20:00:22 local
  file last modified on (UT extra field modtime): 1975 Nov 22 04:00:22 UTC

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

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

From jpai at openjdk.java.net  Wed Dec  1 01:20:31 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Dec 2021 01:20:31 GMT
Subject: RFR: 8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
In-Reply-To: <7LJi8R1rJePO4rEY2Bq_CYz3PyLRbr4kxFYOHNGqkEw=.fc9d3b07-8422-46c2-bab6-6b9bdb355ed9@github.com>
References: <7LJi8R1rJePO4rEY2Bq_CYz3PyLRbr4kxFYOHNGqkEw=.fc9d3b07-8422-46c2-bab6-6b9bdb355ed9@github.com>
Message-ID: <ZEwwDxZU2AazkVg96uQPn_q08zcbp7UNC9xOR5AzJsU=.1fb562f2-4fd8-4ee8-97ef-763ff451ffaf@github.com>

On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes a typo in the javadoc of `java.util.zip.ZipEntry.setTime()` method?

Thank you everyone for the reviews.

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

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

From jpai at openjdk.java.net  Wed Dec  1 01:20:32 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Dec 2021 01:20:32 GMT
Subject: Integrated: 8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
In-Reply-To: <7LJi8R1rJePO4rEY2Bq_CYz3PyLRbr4kxFYOHNGqkEw=.fc9d3b07-8422-46c2-bab6-6b9bdb355ed9@github.com>
References: <7LJi8R1rJePO4rEY2Bq_CYz3PyLRbr4kxFYOHNGqkEw=.fc9d3b07-8422-46c2-bab6-6b9bdb355ed9@github.com>
Message-ID: <5evtB8oLsRBY7b6Hij3MRazUTBPkw8YljgoqdSTUdcw=.7cfcf27f-120c-47d1-94c9-db06506066e0@github.com>

On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes a typo in the javadoc of `java.util.zip.ZipEntry.setTime()` method?

This pull request has now been integrated.

Changeset: 0a01baaf
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a01baaf2dd31a0fe2bc8b1327fb072cc3909eeb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime

Reviewed-by: alanb, iris, lancea

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

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

From jgneff at openjdk.java.net  Wed Dec  1 01:41:32 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 01:41:32 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
Message-ID: <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>

On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I found it helpful to look at what others have done.

The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.

Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.

The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.

@andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.

[1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
[2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
[3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

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

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

From david.holmes at oracle.com  Wed Dec  1 01:58:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Dec 2021 11:58:03 +1000
Subject: RFR: 8277861: Terminally deprecate Thread.stop
In-Reply-To: <06A1B874-C608-43B0-B301-A1B8E7447AEB@cbfiddle.com>
References: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
 <0zHvTnIpcxXJeqFDklk1DujkWrdTBa2mBFylB8HJZ9U=.b448aa4a-f4e3-45a6-ac99-d7f4cbce943a@github.com>
 <06A1B874-C608-43B0-B301-A1B8E7447AEB@cbfiddle.com>
Message-ID: <b535a64b-fdea-032c-d153-5a4e6b09420a@oracle.com>

On 1/12/2021 3:13 am, Alan Snyder wrote:
> Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable.

No there really aren't. :) The perceived utility of stop() is an 
illusion. It is almost impossible to write any non-trivial code that is 
async-exception-safe and no JDK library code is written to be 
async-exception-safe including thread tear-down. So while you can say 
"stop() is the only way to disrupt this piece of code", you cannot 
ensure that it is disrupted safely. Once stop is used you need to throw 
away _all_ stateful objects that may have been in active use while 
ThreadDeath was propagated. And even during propagation you can easily 
trigger secondary exceptions.

Cheers,
David


> The examples I am thinking of involve a potentially long running computation whose result is no longer needed.
> In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful)
> and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption).
> 
> Is there some alternative that can be used in such cases?
> 
> Perhaps a version of stop() that only works if no locks are held?
> 
>    Alan
> 
> 
> 
> 
> 
>> On Nov 30, 2021, at 7:51 AM, Roger Riggs <rriggs at openjdk.java.net> wrote:
>>
>> On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>
>>> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
>>>
>>> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).
>>
>> Past time for this to go.
>>
>>

From dholmes at openjdk.java.net  Wed Dec  1 02:02:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Dec 2021 02:02:28 GMT
Subject: RFR: 8277861: Terminally deprecate Thread.stop
In-Reply-To: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
References: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
Message-ID: <DyESVGAtXeBpvWMl-7uSJ5Dy00n9QEq2DvKnut4RuK0=.e1ac1753-b545-4fa2-87af-b77952546413@github.com>

On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
> 
> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).

Approved with extreme prejudice. :)

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

Marked as reviewed by dholmes (Reviewer).

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

From javalists at cbfiddle.com  Wed Dec  1 02:25:37 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 30 Nov 2021 18:25:37 -0800
Subject: RFR: 8277861: Terminally deprecate Thread.stop
In-Reply-To: <b535a64b-fdea-032c-d153-5a4e6b09420a@oracle.com>
References: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
 <0zHvTnIpcxXJeqFDklk1DujkWrdTBa2mBFylB8HJZ9U=.b448aa4a-f4e3-45a6-ac99-d7f4cbce943a@github.com>
 <06A1B874-C608-43B0-B301-A1B8E7447AEB@cbfiddle.com>
 <b535a64b-fdea-032c-d153-5a4e6b09420a@oracle.com>
Message-ID: <E39F1A31-7C47-477B-96AE-A844AA711AFC@cbfiddle.com>

>> It is almost impossible to write any non-trivial code that is async-exception-safe and no JDK library code is written to be async-exception-safe including thread tear-down. So while you can say "stop() is the only way to disrupt this piece of code", you cannot ensure that it is disrupted safely. Once stop is used you need to throw away _all_ stateful objects that may have been in active use while ThreadDeath was propagated. And even during propagation you can easily trigger secondary exceptions.

It seems that it should be possible to stop a thread spawned to execute code in a native library that works on data in native memory..
If what you say about thread tear-down is true, then I guess I would need to spawn the thread from native code as well.



> On Nov 30, 2021, at 5:58 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 1/12/2021 3:13 am, Alan Snyder wrote:
>> Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable.
> 
> No there really aren't. :) The perceived utility of stop() is an illusion. It is almost impossible to write any non-trivial code that is async-exception-safe and no JDK library code is written to be async-exception-safe including thread tear-down. So while you can say "stop() is the only way to disrupt this piece of code", you cannot ensure that it is disrupted safely. Once stop is used you need to throw away _all_ stateful objects that may have been in active use while ThreadDeath was propagated. And even during propagation you can easily trigger secondary exceptions.
> 
> Cheers,
> David
> 
> 
>> The examples I am thinking of involve a potentially long running computation whose result is no longer needed.
>> In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful)
>> and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption).
>> Is there some alternative that can be used in such cases?
>> Perhaps a version of stop() that only works if no locks are held?
>>   Alan
>>> On Nov 30, 2021, at 7:51 AM, Roger Riggs <rriggs at openjdk.java.net> wrote:
>>> 
>>> On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>> 
>>>> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
>>>> 
>>>> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).
>>> 
>>> Past time for this to go.
>>> 
>>> 
> 


From dholmes at openjdk.java.net  Wed Dec  1 02:32:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Dec 2021 02:32:26 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

Hi @shipilev ,
We need to have someone look at the impact of this on our CI. I don't think we run the tier4 group as defined in our tier 4 so we may not see those execution time savings that offset the extra cost to tier3.

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

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

From duke at openjdk.java.net  Wed Dec  1 03:10:30 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 1 Dec 2021 03:10:30 GMT
Subject: Withdrawn: 8217496: Matcher.group() can return null after usePattern
In-Reply-To: <5VUg9AMdKK73UL-f9S6MFD17Hsmhi5IxQi4bib6gF3g=.8066f78b-fb15-4d6a-a3d0-f5e863fe3e6a@github.com>
References: <5VUg9AMdKK73UL-f9S6MFD17Hsmhi5IxQi4bib6gF3g=.8066f78b-fb15-4d6a-a3d0-f5e863fe3e6a@github.com>
Message-ID: <NaICpErmtuHiGFgFX5pVUnRs2aDxPwC4rGrFI5yXhDk=.a9bd0778-c57e-45fe-be44-977c36d366a0@github.com>

On Tue, 5 Oct 2021 19:11:57 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Specification update to clarify Matcher behavior to include a null return value.

This pull request has been closed without being integrated.

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

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

From rreddy at openjdk.java.net  Wed Dec  1 05:35:11 2021
From: rreddy at openjdk.java.net (Ravi Reddy)
Date: Wed, 1 Dec 2021 05:35:11 GMT
Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v14]
In-Reply-To: <ch1txT0NfYMXzgAtFw8zJtTS7QbGnFQLGzpCpAiufCM=.9d0b51e3-01b1-4573-9c37-7c2f61b1865a@github.com>
References: <ch1txT0NfYMXzgAtFw8zJtTS7QbGnFQLGzpCpAiufCM=.9d0b51e3-01b1-4573-9c37-7c2f61b1865a@github.com>
Message-ID: <VmF_G3dAkaRXnKytUPBWBW4DDZR0sWOnoekl2n5ZxXU=.c03f8180-1f5c-4236-a8f8-8b8a4b88fb35@github.com>

> Hi all,
> 
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation).
> 
> Thanks,
> Ravi

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

  Change in test case name from GZipLoopTest.java to CloseDeflaterTest , moved testcase to util/zip/

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5522/files
  - new: https://git.openjdk.java.net/jdk/pull/5522/files/47697f96..6541de46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5522&range=12-13

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

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

From plevart at openjdk.java.net  Wed Dec  1 07:12:38 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 1 Dec 2021 07:12:38 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v3]
In-Reply-To: <WqcvXuKvjkHPY1UUt8uUzLAcs_deqTOn6eZsbkcNCgE=.517a79a8-3f04-4231-9875-f85719cafda3@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <WqcvXuKvjkHPY1UUt8uUzLAcs_deqTOn6eZsbkcNCgE=.517a79a8-3f04-4231-9875-f85719cafda3@github.com>
Message-ID: <N0nItfOqVJnsThuhb4E5U-TL_6PwNxCo9Vx_aOaz0wU=.67bc9063-46c3-4a7f-b85e-293b6260390f@github.com>

On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
>  - Use ClassValue to solve JDK-8277072
>  - Use ForceGC instead of System.gc()
>  - Convert test to testng
>  - Fix indentation of new testcase
>  - 8277072: ObjectStreamClass caches keep ClassLoaders alive

I think most "hard work" (the tests) is still yours. I just removed a chunk of legacy code and replaced it with one-liners :-). I'm glad that this actually works! Please, continue...

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

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

From shade at openjdk.java.net  Wed Dec  1 08:23:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Dec 2021 08:23:32 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>
Message-ID: <renUvK0_bHgboDYoxpd3MnTAXsGtJpxzP3nx5gFfS48=.9ed89001-62a8-4751-9d48-8e184ad3aef2@github.com>

On Wed, 1 Dec 2021 02:29:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi @shipilev , We need to have someone look at the impact of this on our CI. I don't think we run the tier4 group as defined in our tier 4 so we may not see those execution time savings that offset the extra cost to tier3.

OK, I can wait for those who have more insight in Oracle testing pipelines check their workflows with this change. I have no insight in Oracle infra, so somebody else have to do it. Now that Igor left, who should we be talking to?

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

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

From shade at openjdk.java.net  Wed Dec  1 08:37:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Dec 2021 08:37:24 GMT
Subject: RFR: JDK-8278014: [vectorapi] Remove test run script [v2]
In-Reply-To: <SD2ZZLloTK8rqO1swDX0AldpINc4wwuHDCLI39ybNp0=.08bbeb65-072e-4b45-bc0a-fb992e72f0a2@github.com>
References: <mxbx4EMsokTWsI9kXcNGm21hw0h8TBRe1gts_pRprik=.fe7b3311-c0b8-4bce-8b08-e4a600975d9c@github.com>
 <SD2ZZLloTK8rqO1swDX0AldpINc4wwuHDCLI39ybNp0=.08bbeb65-072e-4b45-bc0a-fb992e72f0a2@github.com>
Message-ID: <Yqf1WF30khtvJKHbdYTrKnyhFstsESzY-GsewSuVNbk=.8d131583-21a6-4574-a02e-cf9b04af5253@github.com>

On Tue, 30 Nov 2021 23:35:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Remove Vector API scripts for building and running tests. `jtreg` should be used instead.
>> 
>> Also updated the test generation script to remove options that assume mercurial as the code repository.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copywrite year.

Marked as reviewed by shade (Reviewer).

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

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

From alanb at openjdk.java.net  Wed Dec  1 08:48:31 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Dec 2021 08:48:31 GMT
Subject: Integrated: 8277861: Terminally deprecate Thread.stop
In-Reply-To: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
References: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
Message-ID: <Hs9_5urUVIKTwogOZkXF51Wk3paT3cX5Ruz7GOdoYZ4=.fdcc522b-3dff-4dd5-8683-9310486c900f@github.com>

On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
> 
> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).

This pull request has now been integrated.

Changeset: fde0b95e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fde0b95ede68c188479852c46df7e28dc4b79594
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8277861: Terminally deprecate Thread.stop

Reviewed-by: rriggs, mchung, uschindler, dholmes

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

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

From plevart at openjdk.java.net  Wed Dec  1 10:53:37 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 1 Dec 2021 10:53:37 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v3]
In-Reply-To: <WqcvXuKvjkHPY1UUt8uUzLAcs_deqTOn6eZsbkcNCgE=.517a79a8-3f04-4231-9875-f85719cafda3@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <WqcvXuKvjkHPY1UUt8uUzLAcs_deqTOn6eZsbkcNCgE=.517a79a8-3f04-4231-9875-f85719cafda3@github.com>
Message-ID: <kLxsCCrG2DUqmhU5X_PFljrkibPTDL658iOGZuLNvZk=.7a9f5717-d1b1-404d-bc4a-d7bf13f31699@github.com>

On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
>  - Use ClassValue to solve JDK-8277072
>  - Use ForceGC instead of System.gc()
>  - Convert test to testng
>  - Fix indentation of new testcase
>  - 8277072: ObjectStreamClass caches keep ClassLoaders alive

...I think that you could remove now obsolete java.io.ObjectStreamClass.EntryFuture nested class. It's not used any more.

It would be nice to follow-up this patch with patches that make use of ClassValue also for:
- java.io.ObjectInputStream.Caches#subclassAudits
- java.io.ObjectOutputStream.Caches#subclassAudits

...this way the common static machinery like:
- java.io.ObjectStreamClass#processQueue
- java.io.ObjectStreamClass.WeakClassKey
...could get removed as it is not used in ObjectStreamClass any more.

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

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

From aleonard at openjdk.java.net  Wed Dec  1 11:06:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 11:06:12 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/283e435a..c84bc5ad

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

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

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

From aleonard at openjdk.java.net  Wed Dec  1 11:06:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 11:06:13 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
 <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>
Message-ID: <9Q9BgKB7M_k_ldtqDALrT6LP6G7OPxkthTvHpbC2jJE=.94897652-9e7a-4706-96be-47b883272e93@github.com>

On Wed, 1 Dec 2021 01:37:55 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> I found it helpful to look at what others have done.
> 
> The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.
> 
> Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.
> 
> The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.
> 
> @andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.
> 
> [1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
> [2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
> [3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John for you test program, i've been using your previous version which is similar.
So please can you review the latest commit, it basically follows the same method of your test program using a ZonedDateTime instant from the input --date converted to a LocalDateTime of the same Instant in UTC, and then passed to e.setTimeLocal(ldt)
It also only allows --date in the local date range of 1980->2099

Here's a manual test from 2 timezones of this latest commit:

~/workspace/repbuild$ sudo timedatectl set-timezone GMT
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar1.jar Time.*
~/workspace/repbuild$ sudo timedatectl set-timezone EST
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar2.jar Time.*
~/workspace/repbuild$ zipinfo -v myjar1.jar | grep -e Archive -e modified
Archive:  myjar1.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
~/workspace/repbuild$ zipinfo -v myjar2.jar | grep -e Archive -e modified
Archive:  myjar2.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00


I have also added reproducible jar tests across timezones.
thanks

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

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

From jpai at openjdk.java.net  Wed Dec  1 11:58:33 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Dec 2021 11:58:33 GMT
Subject: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property
 while launching jpackage tests to help diagonize recent intermittent
 failures
In-Reply-To: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
References: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
Message-ID: <gTyJtRR2iFSHn0FM9VebDDwjHXd_ZaFlJUSo2kqJR2U=.386ebee5-d2f2-4e15-b3d3-b81286fb5b9a@github.com>

On Wed, 24 Nov 2021 08:54:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which adds `jlink.debug=true` system property while launching `jpackage` tests?
> 
> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't take into account the part where the `jpackage` tool gets launched as a `ToolProvider` from some of these tests. This resulted in a large number of tests failing (across different OS) in `tier2` with errors like:
> 
> 
> Error: Invalid Option: [-J-Djlink.debug=true]
> 
> 
> In this current PR, the changed code now takes into account the possibility of `jpackage` being launched as a `ToolProvider` and in such cases doesn't add this option. To achieve this, the adding of this argument is delayed till when the actual execution is about to happen and thus it's now done in the `adjustArgumentsBeforeExecution()` method of the jpackage test framework.
> 
> With this change, I have now run the `jdk:tier2` locally on a macos instance and the tests have all passed:
> 
> 
> Test results: passed: 3,821; failed: 3
> Report written to jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
> Results written to jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/jdk:tier2'
> Test report is stored in build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier2                               3824  3821     3     0 <<
> ==============================
> 
> The 3 failing tests are unrelated to this change and belong to the `java/nio/channels/DatagramChannel/` test package.
> Furthermore, I've looked into the generated logs of the following tests to verify that the `-J-Djlink.debug=true` does get passed in relevant tests and doesn't in those that failed previously in `tier2`:
> 
> test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
> test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
> test/jdk/tools/jpackage/share/ArgumentsTest.java
> 
> A sample from one of the logs where this system property is expected to be passed along:
> 
>> TRACE: exec: Execute [jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage --input ./test/input --dest ./test/output --name "Name With Space" --type pkg --main-jar hello.jar --main-class Hello -J-Djlink.debug=true --verbose](15); inherit I/O...
> 
> 
> I would still like to request someone with access to CI or other OSes (like Windows and Linux) to help test `tier2` against this PR.

Any help reviewing this please?

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

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

From rkennke at openjdk.java.net  Wed Dec  1 12:18:05 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 12:18:05 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v4]
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <GxF0lIhMoXZBbIw1MrqD8pmkNsR5V7RgZq5RsG2hPF8=.be5d7458-9fe7-4fc1-8980-5ec717b5ccc8@github.com>

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

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

  Remove unused EntryFuture inner class from ObjectSteamClass

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6375/files
  - new: https://git.openjdk.java.net/jdk/pull/6375/files/2ed745b3..b7d53adc

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

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

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

From rkennke at openjdk.java.net  Wed Dec  1 12:21:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 12:21:28 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v3]
In-Reply-To: <kLxsCCrG2DUqmhU5X_PFljrkibPTDL658iOGZuLNvZk=.7a9f5717-d1b1-404d-bc4a-d7bf13f31699@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <WqcvXuKvjkHPY1UUt8uUzLAcs_deqTOn6eZsbkcNCgE=.517a79a8-3f04-4231-9875-f85719cafda3@github.com>
 <kLxsCCrG2DUqmhU5X_PFljrkibPTDL658iOGZuLNvZk=.7a9f5717-d1b1-404d-bc4a-d7bf13f31699@github.com>
Message-ID: <eyNs9-DgPVSdtWTS5xvsnDqjAANejIOinBtLb73Tuhs=.0a8c0cf3-0bb6-4306-b858-ac95dc7e7678@github.com>

On Wed, 1 Dec 2021 10:49:54 GMT, Peter Levart <plevart at openjdk.org> wrote:

> ...I think that you could remove now obsolete java.io.ObjectStreamClass.EntryFuture nested class. It's not used any more.

Done.

> It would be nice to follow-up this patch with patches that make use of ClassValue also for:
> 
>     * java.io.ObjectInputStream.Caches#subclassAudits
> 
>     * java.io.ObjectOutputStream.Caches#subclassAudits
> 
> 
> ...this way the common static machinery like:
> 
>     * java.io.ObjectStreamClass#processQueue
> 
>     * java.io.ObjectStreamClass.WeakClassKey
>       ...could get removed as it is not used in ObjectStreamClass any more.

I filed: https://bugs.openjdk.java.net/browse/JDK-8278065

Thanks!

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

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

From sundar at openjdk.java.net  Wed Dec  1 12:24:27 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 1 Dec 2021 12:24:27 GMT
Subject: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property
 while launching jpackage tests to help diagonize recent intermittent
 failures
In-Reply-To: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
References: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
Message-ID: <VJBxeyxGBHb3mWTL-NqC9DdiTvK-RNup-vPAhJEydkk=.337cf2d6-b9de-480b-ac4b-93b24fe862bb@github.com>

On Wed, 24 Nov 2021 08:54:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which adds `jlink.debug=true` system property while launching `jpackage` tests?
> 
> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't take into account the part where the `jpackage` tool gets launched as a `ToolProvider` from some of these tests. This resulted in a large number of tests failing (across different OS) in `tier2` with errors like:
> 
> 
> Error: Invalid Option: [-J-Djlink.debug=true]
> 
> 
> In this current PR, the changed code now takes into account the possibility of `jpackage` being launched as a `ToolProvider` and in such cases doesn't add this option. To achieve this, the adding of this argument is delayed till when the actual execution is about to happen and thus it's now done in the `adjustArgumentsBeforeExecution()` method of the jpackage test framework.
> 
> With this change, I have now run the `jdk:tier2` locally on a macos instance and the tests have all passed:
> 
> 
> Test results: passed: 3,821; failed: 3
> Report written to jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
> Results written to jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/jdk:tier2'
> Test report is stored in build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier2                               3824  3821     3     0 <<
> ==============================
> 
> The 3 failing tests are unrelated to this change and belong to the `java/nio/channels/DatagramChannel/` test package.
> Furthermore, I've looked into the generated logs of the following tests to verify that the `-J-Djlink.debug=true` does get passed in relevant tests and doesn't in those that failed previously in `tier2`:
> 
> test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
> test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
> test/jdk/tools/jpackage/share/ArgumentsTest.java
> 
> A sample from one of the logs where this system property is expected to be passed along:
> 
>> TRACE: exec: Execute [jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage --input ./test/input --dest ./test/output --name "Name With Space" --type pkg --main-jar hello.jar --main-class Hello -J-Djlink.debug=true --verbose](15); inherit I/O...
> 
> 
> I would still like to request someone with access to CI or other OSes (like Windows and Linux) to help test `tier2` against this PR.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From prappo at openjdk.java.net  Wed Dec  1 13:40:21 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 1 Dec 2021 13:40:21 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <r-dd6didFJ8p6RLL4EPWmS6JKC5L4HcdJMBUdPZKufY=.585d5650-23cf-4899-9ef8-70ab869c085b@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Given that this PR affects files that aren't rooted under java/util/stream, I would either rename the PR or exclude the unrelated files. If this PR is going to sit there for some more time, I would prefer the latter. This is because the PR has already conflicted with a few other issues related to malformed javadoc tags (e.g. JDK-8276683 and JDK-8276684).

So either rename and integrate soon, or exclude the unrelated files.

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

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

From mcimadamore at openjdk.java.net  Wed Dec  1 13:57:44 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 1 Dec 2021 13:57:44 GMT
Subject: RFR: 8278071: typos in MemorySegment::set,
 MemorySegment::setAtIndex javadoc
Message-ID: <QnBoXI95w3DFve4cfunKFqoVUaVACmYwReCltxOS7bM=.74f5728b-2f0a-454f-9721-93a66529d4e6@github.com>

There are some truncated statements in MemorySegment::get/MemorySegment::getAtIndex javadoc, more specifically in the `@throws` for `IndexOutOfBoundsException`.

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

Commit messages:
 - Fix typos in MemorySegment dereference setters

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

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

From aleonard at openjdk.java.net  Wed Dec  1 14:02:29 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 14:02:29 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
In-Reply-To: <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
Message-ID: <fZu6gZ7vmx-cJ6IgnaRjolIABdA_In6Ufyudz84846o=.20bd6dd5-5757-4525-bd7a-06107ffb6518@github.com>

On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see above comment, thanks
> 
> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.

@AlanBateman @LanceAndersen @jgneff The new update based on our discussions is now ready for review please. I have also updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8277755 which is review ready as well.
thank you
Andrew

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

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

From ihse at openjdk.java.net  Wed Dec  1 14:15:31 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 1 Dec 2021 14:15:31 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
In-Reply-To: <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@github.com>
Message-ID: <HudycLmJzUlaRInUw2Q1fkOsTbnOHEEnpJdg8Q1FB3w=.e84b5509-ed2a-4ba5-bec4-abdd9b96e0cb@github.com>

On Wed, 1 Dec 2021 11:06:12 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 65:

> 63: 
> 64:     private final ZipOutputStream zos;
> 65:     private final LocalDateTime   date;

Suggestion:

    private final LocalDateTime date;


No need for extra spaces.

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

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

From scolebourne at openjdk.java.net  Wed Dec  1 14:22:28 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 1 Dec 2021 14:22:28 GMT
Subject: RFR: 8177819: DateTimeFormatterBuilder zone parsing should
 recognise DST [v4]
In-Reply-To: <m3UtyMyftc4fZddcVZ99ZQBLxr-DTsZxLCLt1_Y5xw8=.f65c4e7e-80c1-4d0f-b97c-0fc535055272@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <m3UtyMyftc4fZddcVZ99ZQBLxr-DTsZxLCLt1_Y5xw8=.f65c4e7e-80c1-4d0f-b97c-0fc535055272@github.com>
Message-ID: <IkJ_HMoGedpIUWxIILttHSXC6HPnTEOgxhS5UeJ32AE=.c476fe81-4b79-4dbf-a18c-67322e80206b@github.com>

On Mon, 29 Nov 2021 17:41:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording. Removed `LENIENT` parser. Added tests for CI.

Marked as reviewed by scolebourne (Author).

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

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

From jlaskey at openjdk.java.net  Wed Dec  1 14:26:23 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 1 Dec 2021 14:26:23 GMT
Subject: RFR: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions
In-Reply-To: <v2GiIjIld5UXlDgj1jFF-9h8Sis_MM_mk6MioBOJsAw=.bd94c270-9218-4280-bcbc-eeb54a2b3451@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
 <v2GiIjIld5UXlDgj1jFF-9h8Sis_MM_mk6MioBOJsAw=.bd94c270-9218-4280-bcbc-eeb54a2b3451@github.com>
Message-ID: <5PrZl2LTnD7hpQ6ykhpKO__cqSL9FhcRKYGvpRpPZdI=.43621676-bc7e-400f-9d7e-d31ad35a2762@github.com>

On Tue, 30 Nov 2021 22:23:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Should there be a regression test here?

I can ask the submitter to provide a new test based on his testing (new JBS issue.) The complexity of the test is beyond in house expertise.

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

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

From rkennke at openjdk.java.net  Wed Dec  1 14:53:36 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 14:53:36 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
Message-ID: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>

As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.

Testing:
 - [ ] tier1
 - [ ] tier2
 - [ ] tier3

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

Depends on: https://git.openjdk.java.net/jdk/pull/6375

Commit messages:
 - 8278065: Refactor subclassAudits to use ClassValue

Changes: https://git.openjdk.java.net/jdk/pull/6637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278065
  Stats: 105 lines in 3 files changed: 2 ins; 87 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637

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

From rriggs at openjdk.java.net  Wed Dec  1 14:54:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Dec 2021 14:54:43 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
Message-ID: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>

Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
Changes include:
 - SuppressWarnings("deprecation") and SuppressWarnings("removal")
 - Adding type parameters to Raw types
 - Adding a hashCode method where equals was already present

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

Commit messages:
 - 8278028: [test-library] Warnings cleanup of the test library

Changes: https://git.openjdk.java.net/jdk/pull/6638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278028
  Stats: 23 lines in 14 files changed: 10 ins; 1 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

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

From coffeys at openjdk.java.net  Wed Dec  1 15:23:27 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 1 Dec 2021 15:23:27 GMT
Subject: RFR: 8193682: Infinite loop in ZipOutputStream.close() [v14]
In-Reply-To: <VmF_G3dAkaRXnKytUPBWBW4DDZR0sWOnoekl2n5ZxXU=.c03f8180-1f5c-4236-a8f8-8b8a4b88fb35@github.com>
References: <ch1txT0NfYMXzgAtFw8zJtTS7QbGnFQLGzpCpAiufCM=.9d0b51e3-01b1-4573-9c37-7c2f61b1865a@github.com>
 <VmF_G3dAkaRXnKytUPBWBW4DDZR0sWOnoekl2n5ZxXU=.c03f8180-1f5c-4236-a8f8-8b8a4b88fb35@github.com>
Message-ID: <Z7iyZAwz_PCt7f_zpIRndmMzWFG64Rpqxzsb6j2MCJ8=.e3b6b7a5-e4d6-475f-a0ce-d5521a9acbd8@github.com>

On Wed, 1 Dec 2021 05:35:11 GMT, Ravi Reddy <rreddy at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation).
>> 
>> Thanks,
>> Ravi
>
> Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change in test case name from GZipLoopTest.java to CloseDeflaterTest , moved testcase to util/zip/

Marked as reviewed by coffeys (Reviewer).

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

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

From rreddy at openjdk.java.net  Wed Dec  1 15:38:36 2021
From: rreddy at openjdk.java.net (Ravi Reddy)
Date: Wed, 1 Dec 2021 15:38:36 GMT
Subject: Integrated: 8193682: Infinite loop in ZipOutputStream.close()
In-Reply-To: <ch1txT0NfYMXzgAtFw8zJtTS7QbGnFQLGzpCpAiufCM=.9d0b51e3-01b1-4573-9c37-7c2f61b1865a@github.com>
References: <ch1txT0NfYMXzgAtFw8zJtTS7QbGnFQLGzpCpAiufCM=.9d0b51e3-01b1-4573-9c37-7c2f61b1865a@github.com>
Message-ID: <0YE7QAVDi1zBLmdNoE6WZCXun5HsXf6fJRQ7QLVt-78=.dc2280f7-2097-4856-bd9d-0a06f140ea87@github.com>

On Wed, 15 Sep 2021 07:40:35 GMT, Ravi Reddy <rreddy at openjdk.org> wrote:

> Hi all,
> 
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close operations on GZip we are not setting the deflator to a finished state which is leading to an infinite loop when we try writing on the same GZip instance( since we use while(!def.finished()) inside the write operation).
> 
> Thanks,
> Ravi

This pull request has now been integrated.

Changeset: 1e9ed54d
Author:    Ravi Reddy <rreddy at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e9ed54d362b8c57be5fbbac2de5afbd0f05435f
Stats:     258 lines in 4 files changed: 191 ins; 29 del; 38 mod

8193682: Infinite loop in ZipOutputStream.close()

Reviewed-by: lancea, coffeys

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

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

From psandoz at openjdk.java.net  Wed Dec  1 16:16:34 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 1 Dec 2021 16:16:34 GMT
Subject: Integrated: JDK-8278014: [vectorapi] Remove test run script
In-Reply-To: <mxbx4EMsokTWsI9kXcNGm21hw0h8TBRe1gts_pRprik=.fe7b3311-c0b8-4bce-8b08-e4a600975d9c@github.com>
References: <mxbx4EMsokTWsI9kXcNGm21hw0h8TBRe1gts_pRprik=.fe7b3311-c0b8-4bce-8b08-e4a600975d9c@github.com>
Message-ID: <LRGYhh52LPWourIKzwf0i4z8AiDWDkhIKZg4kyOJhMY=.dab6ae09-ddeb-4e8b-a4a1-6106e2cd9ed4@github.com>

On Tue, 30 Nov 2021 19:22:53 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Remove Vector API scripts for building and running tests. `jtreg` should be used instead.
> 
> Also updated the test generation script to remove options that assume mercurial as the code repository.

This pull request has now been integrated.

Changeset: 9b3e6720
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b3e67205913daa1960373a4ab33422137082696
Stats:     161 lines in 5 files changed: 0 ins; 156 del; 5 mod

8278014: [vectorapi] Remove test run script

Reviewed-by: sviswanathan, jiefu, shade

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

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

From dfuchs at openjdk.java.net  Wed Dec  1 16:56:28 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 1 Dec 2021 16:56:28 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <mZaHAvVGBjhen4fclGvAVNwBfOOFO19MX3YeOLCo8lU=.5fd51468-1b35-40bf-98c2-25afd0f21801@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Changes look reasonable to me but since I am not familiar with all those files it might be best to get at least one additional reviewer.

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

Marked as reviewed by dfuchs (Reviewer).

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

From weijun at openjdk.java.net  Wed Dec  1 17:11:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 1 Dec 2021 17:11:43 GMT
Subject: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa
Message-ID: <GbvST0PI0Rj6lpXJ_mq9r4egd9bIaCMWsNHkiNIgRLM=.938936fb-6030-454a-a9a6-0cc0cba37120@github.com>

Update Public Suffix List data to the latest version at https://github.com/publicsuffix/list.

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

Commit messages:
 - 8255266: 2021-11-27 public suffix list update v 3c213aa

Changes: https://git.openjdk.java.net/jdk/pull/6643/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6643&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255266
  Stats: 1254 lines in 5 files changed: 887 ins; 215 del; 152 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6643/head:pull/6643

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

From naoto at openjdk.java.net  Wed Dec  1 17:17:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Dec 2021 17:17:32 GMT
Subject: Integrated: 8177819: DateTimeFormatterBuilder zone parsing should
 recognise DST
In-Reply-To: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
Message-ID: <cfc2Curc1rV4e8k3zseGnWHHUqxZc0r3wyY5vU4C1f4=.8590b45d-234d-4136-a7ce-55d28b43fb26@github.com>

On Tue, 23 Nov 2021 17:00:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: a363b7b9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a363b7b9217cbb9a7580a87b812da8d5a4215326
Stats:     204 lines in 5 files changed: 74 ins; 83 del; 47 mod

8177819: DateTimeFormatterBuilder zone parsing should recognise DST
8277049: ZonedDateTime parse in Fall DST transition fails to retain the correct zonename.

Reviewed-by: joehw, scolebourne

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

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

From darcy at openjdk.java.net  Wed Dec  1 17:28:27 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Dec 2021 17:28:27 GMT
Subject: RFR: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions
In-Reply-To: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
Message-ID: <ayW4posZH15w-zHn7Xp_nLZ_GyB2PlyBVIxa8vHlMSQ=.890524ae-ec69-479d-b182-78c1c4ccf14a@github.com>

On Thu, 11 Nov 2021 13:59:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The modified ziggurat algorithm is not correctly implemented in `java.base/jdk/internal/util/random/RandomSupport.java`. 
> 
> Create a histogram of a million samples using 2000 uniform bins with the following range: 
> Exponential range from 0 to 12. Gaussian range from -8 to 8. 
> 
> This does not pass a Chi-square test. If you look at the histogram it is obviously not showing the shape of the PDF for these distributions. Look closely at the range around zero (e.g. +/- 0.5).

Marked as reviewed by darcy (Reviewer).

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

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

From darcy at openjdk.java.net  Wed Dec  1 17:28:27 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Dec 2021 17:28:27 GMT
Subject: RFR: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions
In-Reply-To: <5PrZl2LTnD7hpQ6ykhpKO__cqSL9FhcRKYGvpRpPZdI=.43621676-bc7e-400f-9d7e-d31ad35a2762@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
 <v2GiIjIld5UXlDgj1jFF-9h8Sis_MM_mk6MioBOJsAw=.bd94c270-9218-4280-bcbc-eeb54a2b3451@github.com>
 <5PrZl2LTnD7hpQ6ykhpKO__cqSL9FhcRKYGvpRpPZdI=.43621676-bc7e-400f-9d7e-d31ad35a2762@github.com>
Message-ID: <HeGWWvhfwZL97dkR8yt6PH0hJogVVNXbhE1OVHYIL3g=.42e49e65-9582-4001-99db-0c3146c3333e@github.com>

On Wed, 1 Dec 2021 14:21:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> > Should there be a regression test here?
> 
> I can ask the submitter to provide a new test based on his testing (new JBS issue.) The complexity of the test is beyond in house expertise.

Okay.

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

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

From jlaskey at openjdk.java.net  Wed Dec  1 17:38:54 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 1 Dec 2021 17:38:54 GMT
Subject: RFR: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions [v2]
In-Reply-To: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
Message-ID: <DqDoZdl4vtlDn4fb7N_xivTF_dD6hxADW_AjA76o958=.7bb49720-29f1-4a43-9883-3d4df48df8dd@github.com>

> The modified ziggurat algorithm is not correctly implemented in `java.base/jdk/internal/util/random/RandomSupport.java`. 
> 
> Create a histogram of a million samples using 2000 uniform bins with the following range: 
> Exponential range from 0 to 12. Gaussian range from -8 to 8. 
> 
> This does not pass a Chi-square test. If you look at the histogram it is obviously not showing the shape of the PDF for these distributions. Look closely at the range around zero (e.g. +/- 0.5).

Jim Laskey 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 8273056
 - 8273056 - java.util.random does not correctly sample exponential or Gaussian distributions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6353/files
  - new: https://git.openjdk.java.net/jdk/pull/6353/files/b10c4793..b6679479

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

  Stats: 69228 lines in 1218 files changed: 46725 ins; 12712 del; 9791 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6353.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6353/head:pull/6353

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

From bpb at openjdk.java.net  Wed Dec  1 17:51:30 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Dec 2021 17:51:30 GMT
Subject: RFR: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions [v2]
In-Reply-To: <DqDoZdl4vtlDn4fb7N_xivTF_dD6hxADW_AjA76o958=.7bb49720-29f1-4a43-9883-3d4df48df8dd@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
 <DqDoZdl4vtlDn4fb7N_xivTF_dD6hxADW_AjA76o958=.7bb49720-29f1-4a43-9883-3d4df48df8dd@github.com>
Message-ID: <vgpmbqOCKhIGZ3he4qjofGRI7fMv2hCeBIhWYrQtRTA=.c91d4933-d9ce-4156-97da-01d6be462e16@github.com>

On Wed, 1 Dec 2021 17:38:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The modified ziggurat algorithm is not correctly implemented in `java.base/jdk/internal/util/random/RandomSupport.java`. 
>> 
>> Create a histogram of a million samples using 2000 uniform bins with the following range: 
>> Exponential range from 0 to 12. Gaussian range from -8 to 8. 
>> 
>> This does not pass a Chi-square test. If you look at the histogram it is obviously not showing the shape of the PDF for these distributions. Look closely at the range around zero (e.g. +/- 0.5).
>
> Jim Laskey 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 8273056
>  - 8273056 - java.util.random does not correctly sample exponential or Gaussian distributions

Marked as reviewed by bpb (Reviewer).

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

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

From aleonard at openjdk.java.net  Wed Dec  1 18:02:05 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 18:02:05 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/c84bc5ad..2f3a7fc2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=12-13

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

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

From bchristi at openjdk.java.net  Wed Dec  1 18:21:04 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 18:21:04 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v2]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <m-ud7vTqLEF_8-DW2uxNLYZL7U0orlenSQXjZ4wmUgw=.7872b89e-a5f2-48dd-b17f-8b263fb07024@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From rriggs at openjdk.java.net  Wed Dec  1 18:23:28 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Dec 2021 18:23:28 GMT
Subject: RFR: 8277322: Document that setting an invalid property
 jdk.serialFilter disables deserialization
In-Reply-To: <8XD8crGyZQwUraBd6zeaOzDq-HwXf1K0pn04dgrZEzI=.0aca26c8-8c05-4f4a-93aa-8fb70e93f1cf@github.com>
References: <u4mvtG6LKYqnbh8FYKETa4MYJUGSK-4syEIn-3qo8b8=.ec0cae66-aac7-4cbb-9f67-f1cf47f868c3@github.com>
 <SRonlS94H3bdIvSE6152SqPvFJUgN9sukbEhx2g9mn4=.5a0d1498-8105-4d8a-b17e-a37b223523dc@github.com>
 <tIel5-lFv129a8P4y0IZYgPsD68qu1dF7INR-IMspPM=.cbc4b5dd-a44f-4450-b447-65697039da86@github.com>
 <QqtBVfyAN11IFKhfn1Fbr_vpbqY5qYYXuc3Iq2_AMYM=.d55bea0a-0edc-4ae6-a84b-5c28a4d5a998@github.com>
 <f72McUT7fL9dYCxik7JtJiO2i9yIZwGDDIvQV93cDK4=.4f7ea8ff-93c4-48ad-a8d6-507f77b573c0@github.com>
 <8XD8crGyZQwUraBd6zeaOzDq-HwXf1K0pn04dgrZEzI=.0aca26c8-8c05-4f4a-93aa-8fb70e93f1cf@github.com>
Message-ID: <-wCi0moyXUrcYY-vgRShJxnE1FV9ag9qyc7sDIdJo-A=.bee6169c-e4d6-4c26-9ebd-538c6a94b926@github.com>

On Tue, 30 Nov 2021 20:43:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is about the second line of defense; what happens when the developer deliberately ignores the first error.
>> If the command line parameters are invalid it might be an option to call `System.exit(1)` but there
>> is no precedent for that and it seems undesirable.
>> 
>> Any and all deserialization is only possible after the command line or security properties, if any, are successfully applied.
>> In the examples above, the constructors for `ObjectInputStream` do not succeed if either the serial filter or filter factory are not valid.  The builtin filter factory applies the default filter regardless of the setting of an `ObjectInputFilter` set on the stream.  The only way to completely control the filter combinations is to provide
>> a valid filter factory on the command line; but that is not the case raising the issue here.
>> 
>> The initialization of both could be re-specified and re-implemented to allow the initialization of `Config` to
>> complete successfully but defer throwing an exception (or Error) until either filter or filter factory
>> was requested from `Config.getSerialFilter` or `Config.getSerialFilterFactory`.
>> Both of them are called from the `ObjectInputStream` constructors. 
>> At present, it is incompletely specified and implemented to throw `IllegalStateException` for `getSerialFilterFactory`.
>> 
>> The `NCDFE` is a more reliable backstop against misuse from any source, including reflection, than the alternative.
>
> The use of `ExceptionInInitializerError` can be completely replaced for  invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` with:
> 
> - If either property is supplied and is invalid; deserialization is disabled by:
> - `OIF.Config.getSerialFilter()` and `OIF.Config.setSerialFilter(...)` throw IllegalStateException with the exception message thrown from `Config.createFilter(pattern)`
> - `OIF.Config.getSerialFilterFactory()` and `OIF.Config.setSerialFilterFactory(...)` throw IllegalStateException with the exception message from the attempt to construct the filter factory.
> - Both `new ObjectInputStream(...)` constructors call both `OIF.Config.getSerialFilter()` and `OIF.Config.getSerialFilterFactory()` and so will throw the appropriate `IllegalStateException` for invalid values of the properties.
> - The static initialization of `OIF.Config` does not throw any exceptions (so no `ExceptionInInitializerError`) but hold the state so that the method above can throw `IllegalStateException` with the informative message.
> - The `IllegalStateException`s will be thrown just slightly later than previously, now after the `Config` class is initialized instead of during initialization.
> - The javadoc of the `Config` class will replace the descriptions of the previous error with descriptions of `ISE` and each of the methods mentioned above will have an added `IllegalStateException` documented referring to the property values.
> 
> Its not strictly compatible with the previous behavior but occurs only in the case of badly formed parameters on the command line.

With the change in scope of the solution, a new PR has been created: https://github.com/openjdk/jdk/pull/6645
Please review that instead.

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

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

From jgneff at openjdk.java.net  Wed Dec  1 18:24:28 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 18:24:28 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
Message-ID: <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>

On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>   
>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

I'm testing it now. So far, it's working great!

I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:


  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
  file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC


One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):


  file last modified on (DOS date/time):          1980 Jan 1 00:00:00

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

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

From rriggs at openjdk.java.net  Wed Dec  1 18:27:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Dec 2021 18:27:51 GMT
Subject: RFR: 8278087: Redesign exceptions thrown for invalid jdk.serialFilter
 and jdk.serialFilterFactory.
Message-ID: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>

The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
incompletely specified. The behavior for invalid values of the properties is different and
use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
uninitialized. 

The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
either by system properties supplied on the command line or security properties are logged.
The `Config` class marks either or both the filter and filter factory values as unusable
and remembers the exception message.

Subsequent calls to the methods that get or set the filter or filter factory or create 
an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
The nature of the invalid property is reported as an `IllegalStateException` on first use.

This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization

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

Commit messages:
 - 8278087: Redesign exceptions thrown for invalid jdk.serialFilter and jdk.serialFilterFactory.

Changes: https://git.openjdk.java.net/jdk/pull/6645/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6645&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278087
  Stats: 218 lines in 4 files changed: 137 ins; 15 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6645/head:pull/6645

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

From aleonard at openjdk.java.net  Wed Dec  1 18:36:36 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 18:36:36 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable
 determinsitic cacerts generation
Message-ID: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>

Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Commit messages:
 - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
 - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation

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

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

From iris at openjdk.java.net  Wed Dec  1 18:43:22 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 1 Dec 2021 18:43:22 GMT
Subject: RFR: 8278071: typos in MemorySegment::set,
 MemorySegment::setAtIndex javadoc
In-Reply-To: <QnBoXI95w3DFve4cfunKFqoVUaVACmYwReCltxOS7bM=.74f5728b-2f0a-454f-9721-93a66529d4e6@github.com>
References: <QnBoXI95w3DFve4cfunKFqoVUaVACmYwReCltxOS7bM=.74f5728b-2f0a-454f-9721-93a66529d4e6@github.com>
Message-ID: <g5wDRRFsKRMkrHctx2ZkXWL0dm0o6my_6iWKxY_JeUk=.ec47be98-4d04-457d-8ef8-cadbee33d92d@github.com>

On Wed, 1 Dec 2021 13:49:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There are some truncated statements in MemorySegment::get/MemorySegment::getAtIndex javadoc, more specifically in the `@throws` for `IndexOutOfBoundsException`.

Trivial fix for an apparent cut-and-paste error.

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

Marked as reviewed by iris (Reviewer).

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

From erikj at openjdk.java.net  Wed Dec  1 18:51:27 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 1 Dec 2021 18:51:27 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable determinsitic cacerts generation
In-Reply-To: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
Message-ID: <bqVvSG4f4MrMMi3PI9g26VY7WLhR-8SjTKKjz4dQ4o4=.8094ae02-baf4-4a23-8c2c-b52cf2b5f1e5@github.com>

On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/autoconf/jdk-options.m4 line 176:

> 174:       [specify alternative cacerts source folder containing certificates])])
> 175:   AC_MSG_CHECKING([for cacerts source])
> 176:   if test "x$with_cacerts_src" == x; then

Before this if block, please assign an empty value to CACERTS_SRC. Otherwise, if the user happens to have that variable set in the environment, that value will get recorded by configure, which is usually not something we want.

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

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

From bchristi at openjdk.java.net  Wed Dec  1 19:23:59 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 19:23:59 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From herrick at openjdk.java.net  Wed Dec  1 19:46:50 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 19:46:50 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional launcher
Message-ID: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>

Before signing, unsign all executables and libraries (not just those in runtime).
Also, run individual file sign and unsign commands in quiet mode.
Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).

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

Commit messages:
 - JDK-8276837: [macos]: Errorwhen signing the additional launcher

Changes: https://git.openjdk.java.net/jdk/pull/6636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6636&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276837
  Stats: 64 lines in 3 files changed: 33 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6636/head:pull/6636

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

From asemenyuk at openjdk.java.net  Wed Dec  1 20:03:22 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 1 Dec 2021 20:03:22 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
References: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
Message-ID: <VT8sJTyjYihNjColjC3PswnVB7FdzpPvHa3JD_X7F48=.f7da8116-7eee-4cd4-a10a-ff4fcc3daa2b@github.com>

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Before signing, unsign all executables and libraries (not just those in runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 95:

> 93:         SigningBase.verifyCodesign(launcherPath, true);
> 94:         SigningBase.verifyCodesign(testALPath, true);
> 95:     }

Would it make sense to extend the existing test with additional launcher checks instead of creating another one? Packaging of a full JDK with signing probably takes a while

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

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

From herrick at openjdk.java.net  Wed Dec  1 20:09:29 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 20:09:29 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <VT8sJTyjYihNjColjC3PswnVB7FdzpPvHa3JD_X7F48=.f7da8116-7eee-4cd4-a10a-ff4fcc3daa2b@github.com>
References: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
 <VT8sJTyjYihNjColjC3PswnVB7FdzpPvHa3JD_X7F48=.f7da8116-7eee-4cd4-a10a-ff4fcc3daa2b@github.com>
Message-ID: <ZXpPFSI_QrkKc-U4UORX9ccocsu8vLpN_WiNKrIY7A8=.457bf942-fc1b-4220-9bbb-149a116f6451@github.com>

On Wed, 1 Dec 2021 19:59:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Before signing, unsign all executables and libraries (not just those in runtime).
>> Also, run individual file sign and unsign commands in quiet mode.
>> Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).
>
> test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 95:
> 
>> 93:         SigningBase.verifyCodesign(launcherPath, true);
>> 94:         SigningBase.verifyCodesign(testALPath, true);
>> 95:     }
> 
> Would it make sense to extend the existing test with additional launcher checks instead of creating another one? Packaging of a full JDK with signing probably takes a while

yes - that would be simpler - will do.

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

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

From iklam at openjdk.java.net  Wed Dec  1 21:02:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 1 Dec 2021 21:02:48 GMT
Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime
Message-ID: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com>

**Background:**

In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this:


public enum Day {  SUNDAY, MONDAY ... } 


to


public class Day extends java.lang.Enum {
    public static final SUNDAY = new Day("SUNDAY");
    public static final MONDAY = new Day("MONDAY"); ...
}


With CDS archived heap objects, `Day::<clinit>` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)

**Fix:**

During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::<clinit>`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time.

This is safe as we know that `X::<clinit>` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized.

**Verification:**

To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt

**Testing:**

Passed Oracle CI tiers 1-4. WIll run tier 5 as well.

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

Commit messages:
 - 8275731: CDS archived enums objects are recreated at runtime

Changes: https://git.openjdk.java.net/jdk/pull/6653/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275731
  Stats: 829 lines in 16 files changed: 787 ins; 2 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653

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

From rriggs at openjdk.java.net  Wed Dec  1 21:12:32 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Dec 2021 21:12:32 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v4]
In-Reply-To: <GxF0lIhMoXZBbIw1MrqD8pmkNsR5V7RgZq5RsG2hPF8=.be5d7458-9fe7-4fc1-8980-5ec717b5ccc8@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <GxF0lIhMoXZBbIw1MrqD8pmkNsR5V7RgZq5RsG2hPF8=.be5d7458-9fe7-4fc1-8980-5ec717b5ccc8@github.com>
Message-ID: <oBtYO8OJwEpf_59DHI7fE2QXEb2BTtOr28IF4DJgLoU=.935ecf28-7c66-4156-9b41-91fa7395822f@github.com>

On Wed, 1 Dec 2021 12:18:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused EntryFuture inner class from ObjectSteamClass

Without the use of SoftReference, memory pressure won't release any of the cached info.
That seems to swing the other way from overly aggressively freeing memory with the WeakReference (and needing to recompute) as the change originally proposed.  
Its hard to tell in what environments it might be observed.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:

> 2131:             if (oldReflector != null) {
> 2132:                 reflector = oldReflector;
> 2133:             }

Map.computeIfAbsent(key, () -> new FieldReflector(matchFields, localDesc));
might be more compact.

test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 52:

> 50:         Class<?> loadClass = myOwnClassLoader.loadClass("ObjectStreamClass_MemoryLeakExample");
> 51:         Constructor con = loadClass.getConstructor();
> 52:         con.setAccessible(true);

Isn't the constructor already public?

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

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

From herrick at openjdk.java.net  Wed Dec  1 21:16:48 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 21:16:48 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher [v2]
In-Reply-To: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
References: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
Message-ID: <TKSPdSH9goJy1VooNHDLIYA4nbNw9U5DT7LrD3NA_GM=.a6a6fec0-042c-45cb-982c-ab26f3ebea2b@github.com>

> Before signing, unsign all executables and libraries (not just those in runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).

Andy Herrick has updated the pull request incrementally with 85 additional commits since the last revision:

 - JDK-8276837: [macos]: Error when signing the additional launcher
 - 8277797: Remove undefined/unused SharedRuntime::trampoline_size()
   
   Reviewed-by: dholmes, stuefe
 - 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used interchangeably
   
   Reviewed-by: mli, tschatzl
 - 8277878: Fix compiler tests after JDK-8275908
   
   Reviewed-by: thartmann, chagedorn
 - 8277904: G1: Remove G1CardSetArray::max_entries
   
   Reviewed-by: tschatzl
 - 8277896: Remove unused BOTConstants member methods
   
   Reviewed-by: kbarrett
 - 8277450: Record number of references into collection set during gc
   
   Reviewed-by: kbarrett, iwalulya
 - 8277928: Fix compilation on macosx-aarch64 after 8276108
   
   Reviewed-by: shade, dholmes
 - 8275241: Unused ArrayList is created in RequestEngine.addHooks
   
   Reviewed-by: egahlin
 - 8276108: Wrong instruction generation in aarch64 backend
   
   Co-authored-by: Nick Gasson <ngasson at openjdk.org>
   Reviewed-by: aph, neliasso
 - ... and 75 more: https://git.openjdk.java.net/jdk/compare/34692c5d...2a3e19ff

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6636/files
  - new: https://git.openjdk.java.net/jdk/pull/6636/files/34692c5d..2a3e19ff

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

  Stats: 23719 lines in 463 files changed: 13755 ins; 6525 del; 3439 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6636/head:pull/6636

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

From herrick at openjdk.java.net  Wed Dec  1 21:21:41 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 21:21:41 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
References: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
Message-ID: <F0-wagu0MoawJjtKS8dH1Ejjya3II69tt1WRmKNTHpc=.949cf119-b6b6-48cc-9636-82362890f977@github.com>

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Before signing, unsign all executables and libraries (not just those in runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).

last push was meant to be only one file - but got lots of unrelated changes.
will close this one and open new PR.

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

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

From herrick at openjdk.java.net  Wed Dec  1 21:21:41 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 21:21:41 GMT
Subject: Withdrawn: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
References: <6M8dVtrgUiAbZq7ttfML-XOJnHCKdixzvhFUuxSrJRg=.9a310065-b8f8-429b-a541-c901b60ec04e@github.com>
Message-ID: <RABrK97xwPLr-O8hHI76nefXMyWvDqEbva2_zmTDQOQ=.1968c9ac-c981-4e62-8eec-762ac0e47d3b@github.com>

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Before signing, unsign all executables and libraries (not just those in runtime).
> Also, run individual file sign and unsign commands in quiet mode.
> Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and additional launcher (original reported problem).

This pull request has been closed without being integrated.

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

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

From ioi.lam at oracle.com  Wed Dec  1 21:39:00 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 1 Dec 2021 13:39:00 -0800
Subject: JDK-8275509: (jlink) SystemModulesPlugin generates a
 jdk.internal.module.SystemModules$all.class which isn't reproducible
In-Reply-To: <4435263e-bea2-d303-b677-1e95d26e0a14@gmail.com>
References: <cee5a3a1-0715-7d93-1564-fa9324b50ad4@gmail.com>
 <4a4901a8-ca90-c9f3-0b2f-a37e521bfe65@oracle.com>
 <77faaab4-831c-de4f-2f64-f7305cb8f9fb@gmail.com>
 <60708e84-4888-9584-50e0-df3ae5d8b0b5@oracle.com>
 <72b9f8de-c4f9-9509-bf1e-ec6148f40860@gmail.com>
 <89cad5a5-08f0-3bde-5279-7fcb0550d4db@oracle.com>
 <122a3aee-42bc-b471-5ba8-eb3bebc5e7bb@oracle.com>
 <71aeec43-ae77-e1f8-d4e4-c5e2d31289e7@gmail.com>
 <9ea84f87-b1ce-b1d5-a54b-e7ca547529a6@oracle.com>
 <4efe18eb-2fc0-9a27-87f0-3752d5edd65c@gmail.com>
 <f2fe6c3f-7e98-9fde-d939-14c3c1a3c4da@gmail.com>
 <df3373ce-d0ec-485d-0981-d018a17779e0@oracle.com>
 <4435263e-bea2-d303-b677-1e95d26e0a14@gmail.com>
Message-ID: <0bbb6b87-db0f-e0ff-1442-45dbd419bbe1@oracle.com>



On 11/7/21 9:44 PM, Jaikiran Pai wrote:
> Hello Ioi,
>
> On 02/11/21 12:13 am, Ioi Lam wrote:
>> Hi Jaikiran,
>>
>> Thanks for writing the test case to explore the problems in this area.
>>
>> Please see my comments below:
>> ...
>>
>> Generally speaking, CDS has two levels of archiving:
>>
>> [1] archiving class metadata -- classes in the 
>> $JAVA_HOME/lib/classlist are considered to be frequently loaded 
>> classes. They are parsed from classfiles and stored into the CDS 
>> archive. At run time, instead of parsing the classes from classfiles, 
>> the VM directly use the pre-parsed version of these classes (as 
>> InstanceKlass* in C++).
>>
>> At runtime, all such pre-parsed classes are initially in the "loaded" 
>> state. This means their static constructors will be executed when 
>> these classes are referenced for the first time. So as far as Java 
>> semantic is concerned, there's no difference between a pre-parsed 
>> class vs a class loaded from classfile.
>>
>> E.g, the examples of loggers in static initializers will be executed 
>> at runtime.
>>
>> [2] archiving heap objects
>>
>> As shown in your test, we cannot arbitrarily archive the static 
>> fields that were initialized during -Xshare:dump, because they may 
>> have environment dependency.
>>
>> The strategy used by CDS is to archive only a few static fields in a 
>> small number of carefully hand-picked system classes. You can see the 
>> list in
>>
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/977154400be786c500f36ba14188bff79db57075/src/hotspot/share/cds/heapShared.cpp*L97__;Iw!!ACWV5N9M2RV99hQ!eWsSVUa8qjZ0BWlbOonNdDtE7dcU3w4c9Su5hb24IXirxZFdPoS6wVBMi-78hA$ 
>>
>>
> Thank you for that link. That helped. So essentially even though the 
> list of classes used for archiving class metadata isn't very tightly 
> controlled, the list of objects which are archived in the heap is much 
> more selective.
>
> The reason why my PoC ended up reproducing this issue is because it 
> just so happened that I selected a class (ModuleDescriptor) which 
> (indirectly) is hand-picked in that list of classes that can end up in 
> the archived heap.
>
>> These static fields are stored into the CDS archive. At run time, 
>> these fields are essentially copied into the Java heap, and then 
>> picked up by code like this:
>>
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/977154400be786c500f36ba14188bff79db57075/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java*L163__;Iw!!ACWV5N9M2RV99hQ!eWsSVUa8qjZ0BWlbOonNdDtE7dcU3w4c9Su5hb24IXirxZFdPoS6wVABkO6Q0w$ 
>>
>>
>> ??? public static ModuleLayer boot() {
>> ??????? Counters.start();
>>
>> ??????? ModuleLayer bootLayer;
>> ??????? ArchivedBootLayer archivedBootLayer = ArchivedBootLayer.get();
>> ??????? if (archivedBootLayer != null) {
>> ??????????? assert canUseArchivedBootLayer();
>> ??????????? bootLayer = archivedBootLayer.bootLayer();
>> ??????????? BootLoader.getUnnamedModule(); // trigger <clinit> of 
>> BootLoader.
>> CDS.defineArchivedModules(ClassLoaders.platformClassLoader(), 
>> ClassLoaders.appClassLoader());
>>
>> ??????????? // assume boot layer has at least one module providing a 
>> service
>> ??????????? // that is mapped to the application class loader.
>> ??????????? JLA.bindToLoader(bootLayer, ClassLoaders.appClassLoader());
>> ??????? } else {
>> ??????????? bootLayer = boot2();
>> ??????? }
>>
>> In the case of the module graph, we remove things that depend on the 
>> environment (such as CLASSPATH)
>>
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/977154400be786c500f36ba14188bff79db57075/src/hotspot/share/cds/heapShared.cpp*L190__;Iw!!ACWV5N9M2RV99hQ!eWsSVUa8qjZ0BWlbOonNdDtE7dcU3w4c9Su5hb24IXirxZFdPoS6wVAx46l0Bg$ 
>>
>>
>> The remaining parts of the archived module graph only depend on the 
>> following system properties:
>>
>> ??? private static boolean canUseArchivedBootLayer() {
>> ??????? return getProperty("jdk.module.upgrade.path") == null &&
>> ?????????????? getProperty("jdk.module.path") == null &&
>> ?????????????? getProperty("jdk.module.patch.0") == null &&?????? // 
>> --patch-module
>> ?????????????? getProperty("jdk.module.main") == null &&????????? // 
>> --module
>> ?????????????? getProperty("jdk.module.addmods.0") == null &&??? // 
>> --add-modules
>> ?????????????? getProperty("jdk.module.limitmods") == null &&???? // 
>> --limit-modules
>> ?????????????? getProperty("jdk.module.addreads.0") == null &&??? // 
>> --add-reads
>> ?????????????? getProperty("jdk.module.addexports.0") == null &&? // 
>> --add-exports
>> ?????????????? getProperty("jdk.module.addopens.0") == null; // 
>> --add-opens
>> ??? }
>>
>> As a result, we will invalidate the archived module graph if these 
>> properties differ between dump time and run time. The Java code above 
>> only asserts that the check has already been done. The actual check 
>> is done in here:
>>
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/977154400be786c500f36ba14188bff79db57075/src/hotspot/share/runtime/arguments.cpp*L1339__;Iw!!ACWV5N9M2RV99hQ!eWsSVUa8qjZ0BWlbOonNdDtE7dcU3w4c9Su5hb24IXirxZFdPoS6wVAwq_becQ$ 
>>
>
> Understood.
>
>>
>>> Am I misunderstanding the severity of this issue or is this serious 
>>> enough that -Xshare:off should be default (or heap archiving 
>>> disabled somehow by default till this is fixed) to prevent issues 
>>> like these which can at the minimal be hard to debug bugs and on the 
>>> extreme end perhaps leak things from the build server where the JDK 
>>> was built? I guess it all boils down to which exact classes get 
>>> replaced/mapped/copied over from the heap archive? Is there a 
>>> definitive list that can be derived in the current JDK?
>>>
>>
>> I believe the currently implementation is still safe to use (barring 
>> the problems with enums). For sanity, I'll try to write a static 
>> analysis tool to check that the archived module graph doesn't contain 
>> any reference to fields that may be reinitialized at runtime.
>
> I think if such a static analysis tool can be developed, then it would 
> certainly be useful/reassuring that we don't accidentally end up with 
> unexpected data in the archived heap. I'm not a Reviewer but I can 
> imagine it being difficult to catch these changes that have valid Java 
> semantics but at the same time can cause issues due to archiving the 
> heap. So if this static tool can be automated maybe as a jtreg test 
> case then any such changes could automatically be caught before those 
> changes end up in a release.
>
> Thank you again for the detailed response along with pointers to the 
> code. That helped understand this heap archiving process to a large 
> extent. 

Hi Jaikiran,

I finally finished the static analysis tool and the fix for the archived 
Enums. Please see https://github.com/openjdk/jdk/pull/6653

The tool requires quite a bit of human interaction (see the ADD_EXCL 
lines in cdsHeapVerifier.cpp).

The output of the tool is clean right now. The test case 
ArchivedEnumTest.java monitors the tool's output. If anything is flagged 
in the future (due to changes inside the Java code), it will result in a 
test failure so hopefully someone will take a look, and either fix the 
bug, or fix the ADD_EXCL lines :-(

If you have any suggestion for improvement, please let me know.

Thanks
- Ioi




From aleonard at openjdk.java.net  Wed Dec  1 21:53:25 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 21:53:25 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
Message-ID: <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>

On Wed, 1 Dec 2021 18:20:11 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> I'm testing it now. So far, it's working great!
> 
> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
> 
> ```
>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
> ```
> 
> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
> 
> ```
>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
> ```

Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?

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

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

From herrick at openjdk.java.net  Wed Dec  1 22:40:38 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 1 Dec 2021 22:40:38 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional launcher
Message-ID: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>

- We need to unsign all executables and libraries in the app-image before signing. (not just those in the runtime).
 - Clean up excessive output by executing the individual file sign and unsigning commands in quiet mode.
 - Add conditions in SigningAppImageTest to test signing of additional launchers.

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

Commit messages:
 - JDK-8276837: [macos]: Error when signing the additional launcher
 - JDK-8276837: [macos]: Errorwhen signing the additional launcher

Changes: https://git.openjdk.java.net/jdk/pull/6654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276837
  Stats: 52 lines in 3 files changed: 21 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6654/head:pull/6654

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

From serb at openjdk.java.net  Thu Dec  2 00:12:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Dec 2021 00:12:30 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable determinsitic cacerts generation
In-Reply-To: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
Message-ID: <OYXY3EfnLesP0j3ctkTaMLftQoKHmzeCYBxO3J8Z6Iw=.0414edba-4953-4d77-901b-de1cccb696d1@github.com>

On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I have a question related to the custom cacerts which can be added to the OpenJDK bundle. How do you pass the tests like test/jdk/sun/security/lib/cacerts/VerifyCACerts.java using that custom jdk bundle? Probably we can add an additional configuration to that test so it will check the custom cacerts passed to the build as well?

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

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

From lancea at openjdk.java.net  Thu Dec  2 00:44:44 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Dec 2021 00:44:44 GMT
Subject: RFR: 8277422: tools/jar/JarEntryTime.java fails with modified time
 mismatch
Message-ID: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>

Hi all,

Please review this patch to address a failure at DST->STD offset transition.  The fix mirrors what was done for JDK-8190748


Best,
Lance

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

Commit messages:
 - Patch for JDK-8277422

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

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

From jgneff at openjdk.java.net  Thu Dec  2 01:09:33 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 2 Dec 2021 01:09:33 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
Message-ID: <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>

On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>   
>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

Mainly just two minor comments: (1) there's a better date and time parser, and (2) the current lower bound is a couple seconds off. I'll reply to your question about (2) separately.

The `DateTimeFormatter.ISO_ZONED_DATE_TIME` zoned date and time parser works better than the `ISO_DATE_TIME` local date and time parser when creating a `ZonedDateTime` instance. It catches the following error slightely earlier and provides a better error message.

Here's the current error using the local date and time parser:


$ jmod create --date 2011-12-03T10:15:30 ...
Error: --date 2011-12-03T10:15:30 is not a valid ISO 8601 date and time:
    Text '2011-12-03T10:15:30' could not be parsed:
    Unable to obtain ZonedDateTime from TemporalAccessor:
    {},ISO resolved to 2011-12-03T10:15:30 of type java.time.format.Parsed


Here's the same error using the zoned date and time parser:


$ jmod create --date 2011-12-03T10:15:30 ...
Error: --date 2011-12-03T10:15:30 is not a valid ISO 8601 date and time:
    Text '2021-11-29T09:36:06' could not be parsed at index 19

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 199:

> 197:                 void process(Main jartool, String opt, String arg) throws BadArgs {
> 198:                     try {
> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)

The `ISO_ZONED_DATE_TIME` parser works better here.

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 201:

> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
> 200:                                            .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
> 201:                         if (jartool.date.getYear() < 1980 || jartool.date.getYear() > 2099) {

This `if` test actually compares down to the nanosecond, if present, but the wrong nanosecond. How about something like the following?


    ... ZonedDateTime TIME_MIN = ZonedDateTime.parse("1980-01-01T00:00:02Z");
    ... ZonedDateTime TIME_MAX = ZonedDateTime.parse("2099-12-31T23:59:59Z");
    ...
        var zoned = ZonedDateTime.parse(date, DateTimeFormatter.ISO_ZONED_DATE_TIME);
        if (zoned.isBefore(TIME_MIN) || zoned.isAfter(TIME_MAX)) {
            ....

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 88:

> 86:         date {0} is not a valid ISO 8601 date and time
> 87: error.date.out.of.range=\
> 88:         date {0} is not within the valid year range 1980->2099 

Maybe just define `date {0} is not within the valid range` and put the exact interval in the *man* pages and documentation?

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1164:

> 1162:         public LocalDateTime convert(String value) {
> 1163:             try {
> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)

The `ISO_ZONED_DATE_TIME` parser works better here.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1166:

> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
> 1165:                                          .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
> 1166:                 if (date.getYear() < 1980 || date.getYear() > 2099) {

See previous comment for this line in the `jar` tool.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:

> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
> 111: err.date.out.of.range=--date {0} is out of the valid year range 1980->2099

As before, perhaps refer to the exact range in the documentation? It's really an instant on the time line that is being compared and not the actual year digits that were provided in the command-line option.

test/jdk/tools/jar/JarEntryTime.java line 180:

> 178:                                 "2022-03-15T00:00:00+06:00",
> 179:                                 "2038-11-26T06:06:06+00:00",
> 180:                                 "2098-02-18T00:00:00-08:00"};

It would be great to test just inside the exact boundaries of the permitted interval here.

test/jdk/tools/jar/JarEntryTime.java line 251:

> 249:         // Negative Tests --date out of range source date
> 250:         String[] badSourceDates = {"1976-06-24T01:02:03+00:00",
> 251:                                    "2100-02-18T00:00:00-11:00"};

It would be great to test just outside the exact boundaries of the permitted interval here.

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

Changes requested by jgneff (no project role).

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

From asemenyuk at openjdk.java.net  Thu Dec  2 01:20:23 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 2 Dec 2021 01:20:23 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
References: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
Message-ID: <B9k-3u1tDrop2Vx0FQD9Cv2CWpicUiqY61Jr96G0mnM=.8d7c36ca-f841-4b86-b007-f0eba80dc2f7@github.com>

On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> - We need to unsign all executables and libraries in the app-image before signing. (not just those in the runtime).
>  - Clean up excessive output by executing the individual file sign and unsigning commands in quiet mode.
>  - Add conditions in SigningAppImageTest to test signing of additional launchers.

Marked as reviewed by asemenyuk (Reviewer).

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

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

From smarks at openjdk.java.net  Thu Dec  2 01:26:30 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 2 Dec 2021 01:26:30 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nJKHDn0E59sPCmNw72xg_Pm22IB4JtQmufM09mM7Dek=.9e48eca8-07c1-40b2-ad90-4c8df399b59e@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by smarks (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/SummaryTab.java line 116:

> 114:     StringBuilder buf;
> 115: 
> 116:     @SuppressWarnings("deprecation")

Item for future cleanup: refactor the call to `getObjectPendingFinalizationCount()` at line 219 (!) into a local variable declaration, and then move the warnings suppression to that declaration. This reduces the scope of warnings suppression.

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

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

From almatvee at openjdk.java.net  Thu Dec  2 01:29:27 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 2 Dec 2021 01:29:27 GMT
Subject: RFR: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
References: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
Message-ID: <DUXvmq6Mz10r-6D0DlUHeoXYu3EokwFQgUbKJkCqiug=.e78b680f-8653-4543-b8fe-6ad8d3337960@github.com>

On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> - We need to unsign all executables and libraries in the app-image before signing. (not just those in the runtime).
>  - Clean up excessive output by executing the individual file sign and unsigning commands in quiet mode.
>  - Add conditions in SigningAppImageTest to test signing of additional launchers.

Marked as reviewed by almatvee (Reviewer).

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

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

From jpai at openjdk.java.net  Thu Dec  2 01:33:31 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 2 Dec 2021 01:33:31 GMT
Subject: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property
 while launching jpackage tests to help diagonize recent intermittent
 failures
In-Reply-To: <VJBxeyxGBHb3mWTL-NqC9DdiTvK-RNup-vPAhJEydkk=.337cf2d6-b9de-480b-ac4b-93b24fe862bb@github.com>
References: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
 <VJBxeyxGBHb3mWTL-NqC9DdiTvK-RNup-vPAhJEydkk=.337cf2d6-b9de-480b-ac4b-93b24fe862bb@github.com>
Message-ID: <JJdO7e9ArGVqKc5UkIGA6wEp3il7d3fXftlPMc6ex7Y=.da3b51aa-525d-4660-b4c4-38ce4e7bb840@github.com>

On Wed, 1 Dec 2021 12:21:00 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Can I please get a review of this change which adds `jlink.debug=true` system property while launching `jpackage` tests?
>> 
>> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't take into account the part where the `jpackage` tool gets launched as a `ToolProvider` from some of these tests. This resulted in a large number of tests failing (across different OS) in `tier2` with errors like:
>> 
>> 
>> Error: Invalid Option: [-J-Djlink.debug=true]
>> 
>> 
>> In this current PR, the changed code now takes into account the possibility of `jpackage` being launched as a `ToolProvider` and in such cases doesn't add this option. To achieve this, the adding of this argument is delayed till when the actual execution is about to happen and thus it's now done in the `adjustArgumentsBeforeExecution()` method of the jpackage test framework.
>> 
>> With this change, I have now run the `jdk:tier2` locally on a macos instance and the tests have all passed:
>> 
>> 
>> Test results: passed: 3,821; failed: 3
>> Report written to jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
>> Results written to jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
>> Error: Some tests failed or other problems occurred.
>> Finished running test 'jtreg:test/jdk:tier2'
>> Test report is stored in build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/jdk:tier2                               3824  3821     3     0 <<
>> ==============================
>> 
>> The 3 failing tests are unrelated to this change and belong to the `java/nio/channels/DatagramChannel/` test package.
>> Furthermore, I've looked into the generated logs of the following tests to verify that the `-J-Djlink.debug=true` does get passed in relevant tests and doesn't in those that failed previously in `tier2`:
>> 
>> test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
>> test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
>> test/jdk/tools/jpackage/share/ArgumentsTest.java
>> 
>> A sample from one of the logs where this system property is expected to be passed along:
>> 
>>> TRACE: exec: Execute [jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage --input ./test/input --dest ./test/output --name "Name With Space" --type pkg --main-jar hello.jar --main-class Hello -J-Djlink.debug=true --verbose](15); inherit I/O...
>> 
>> 
>> I would still like to request someone with access to CI or other OSes (like Windows and Linux) to help test `tier2` against this PR.
>
> LGTM

Thank you for the review @sundararajana

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

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

From jpai at openjdk.java.net  Thu Dec  2 01:33:31 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 2 Dec 2021 01:33:31 GMT
Subject: Integrated: 8277647: [REDO] JDK-8277507 Add jlink.debug system
 property while launching jpackage tests to help diagonize recent intermittent
 failures
In-Reply-To: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
References: <WvU8MjVndGiaCRjPlxFsfHj4l6GmDylXio8KOMNTqks=.15df2a7e-7184-45cd-9233-a4dd7d1a8f98@github.com>
Message-ID: <d-FL6k4w6UDIxTG9WoHEQy_cZBTRkk7UrOK7D7NeUAg=.e14d0c46-10bc-48aa-b253-b4e1ee81461a@github.com>

On Wed, 24 Nov 2021 08:54:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which adds `jlink.debug=true` system property while launching `jpackage` tests?
> 
> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't take into account the part where the `jpackage` tool gets launched as a `ToolProvider` from some of these tests. This resulted in a large number of tests failing (across different OS) in `tier2` with errors like:
> 
> 
> Error: Invalid Option: [-J-Djlink.debug=true]
> 
> 
> In this current PR, the changed code now takes into account the possibility of `jpackage` being launched as a `ToolProvider` and in such cases doesn't add this option. To achieve this, the adding of this argument is delayed till when the actual execution is about to happen and thus it's now done in the `adjustArgumentsBeforeExecution()` method of the jpackage test framework.
> 
> With this change, I have now run the `jdk:tier2` locally on a macos instance and the tests have all passed:
> 
> 
> Test results: passed: 3,821; failed: 3
> Report written to jdk/build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2/html/report.html
> Results written to jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_jdk_tier2
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/jdk:tier2'
> Test report is stored in build/macosx-x86_64-server-release/test-results/jtreg_test_jdk_tier2
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier2                               3824  3821     3     0 <<
> ==============================
> 
> The 3 failing tests are unrelated to this change and belong to the `java/nio/channels/DatagramChannel/` test package.
> Furthermore, I've looked into the generated logs of the following tests to verify that the `-J-Djlink.debug=true` does get passed in relevant tests and doesn't in those that failed previously in `tier2`:
> 
> test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java
> test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java
> test/jdk/tools/jpackage/share/ArgumentsTest.java
> 
> A sample from one of the logs where this system property is expected to be passed along:
> 
>> TRACE: exec: Execute [jdk/build/macosx-x86_64-server-release/images/jdk/bin/jpackage --input ./test/input --dest ./test/output --name "Name With Space" --type pkg --main-jar hello.jar --main-class Hello -J-Djlink.debug=true --verbose](15); inherit I/O...
> 
> 
> I would still like to request someone with access to CI or other OSes (like Windows and Linux) to help test `tier2` against this PR.

This pull request has now been integrated.

Changeset: 09522db5
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09522db5aa9503131381bbb4fe3f2eae829645ce
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

Reviewed-by: sundar

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

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

From smarks at openjdk.java.net  Thu Dec  2 01:49:31 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 2 Dec 2021 01:49:31 GMT
Subject: RFR: 8277861: Terminally deprecate Thread.stop
In-Reply-To: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
References: <cnX3uLEn08GF9le75RnuHmCoKZszICpZmKynCE50fBM=.6783b15e-46e1-4aa1-8bd5-9d5be1155871@github.com>
Message-ID: <A8TErPKnvwKZtRirAFlMmBuPLWPxXvp6YwzdIFazaOw=.56f4f478-c50e-4e92-98ec-d7895f57a4d0@github.com>

On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
> 
> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).

Endorsed.

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

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

From jgneff at openjdk.java.net  Thu Dec  2 01:56:25 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 2 Dec 2021 01:56:25 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
Message-ID: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>

On Wed, 1 Dec 2021 21:50:46 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?

I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).

Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.

So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].

[1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

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

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

From mseledtsov at openjdk.java.net  Thu Dec  2 02:03:27 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 2 Dec 2021 02:03:27 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <EfW261FYfCYMxCELpp02DNVPI3L0j4nDU26hHdlfZ48=.908f021b-065f-4dab-903e-f617023b571c@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

Marked as reviewed by mseledtsov (Committer).

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

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

From mseledtsov at openjdk.java.net  Thu Dec  2 02:03:27 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 2 Dec 2021 02:03:27 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>
Message-ID: <dVuImodw3BZPkHK5FcP-TOS7mG-h98yqYTogYQ4ZBRQ=.d1eff215-832f-4949-8019-6ae3d45d4be7@github.com>

On Wed, 1 Dec 2021 02:29:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
>> 
>> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
>> 
>> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
>> 
>> Sample run before:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk:tier3                                174   174     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
>> 
>> real	2m38.242s
>> user	80m7.216s
>> sys	2m13.846s
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> real	18m13.933s
>> user	546m50.556s
>> sys	25m7.086s
>> 
>> 
>> Sample run after:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk:tier3                               1296  1296     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
>> 
>> real	7m49.017s
>> user	287m30.943s
>> sys	13m20.060s
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> 
>> real	12m19.973s
>> user	351m48.561s
>> sys	14m51.566s
>
> Hi @shipilev ,
> We need to have someone look at the impact of this on our CI. I don't think we run the tier4 group as defined in our tier 4 so we may not see those execution time savings that offset the extra cost to tier3.

Thanks @dholmes-ora for making sure to examine the impact on the CI. I took a look, and this change should not have considerable adverse impact on Oracle CI. 

Aleksey, the change looks good to me.

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

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

From dholmes at openjdk.java.net  Thu Dec  2 02:12:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Dec 2021 02:12:29 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <dVuImodw3BZPkHK5FcP-TOS7mG-h98yqYTogYQ4ZBRQ=.d1eff215-832f-4949-8019-6ae3d45d4be7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <n3fdOQm6wTm_Ksr1gsDZ7aqgikqqgOf4YjOB5ZDW_mI=.d6ff4264-1f31-44b9-846a-5de22efe60ea@github.com>
 <dVuImodw3BZPkHK5FcP-TOS7mG-h98yqYTogYQ4ZBRQ=.d1eff215-832f-4949-8019-6ae3d45d4be7@github.com>
Message-ID: <w1dutvGsK5awcC5yaVXp1a2H_-g1DpAY-mLnlnWsL4o=.2fc88586-58e2-4bdf-847b-251d8a319327@github.com>

On Thu, 2 Dec 2021 02:00:11 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Hi @shipilev ,
>> We need to have someone look at the impact of this on our CI. I don't think we run the tier4 group as defined in our tier 4 so we may not see those execution time savings that offset the extra cost to tier3.
>
> Thanks @dholmes-ora for making sure to examine the impact on the CI. I took a look, and this change should not have considerable adverse impact on Oracle CI. 
> 
> Aleksey, the change looks good to me.

Thanks @mseledts for examining - much appreciated.

Thanks for your patience @shipilev .

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

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

From duke at openjdk.java.net  Thu Dec  2 02:36:47 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 02:36:47 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream [v2]
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Tim Prinzing 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 JDK-8276674
 - Fixed @code and @link in some javadoc for JDK-8276674

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

Changes: https://git.openjdk.java.net/jdk/pull/6443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6443&range=01
  Stats: 13 lines in 8 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443

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

From joehw at openjdk.java.net  Thu Dec  2 02:48:30 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 2 Dec 2021 02:48:30 GMT
Subject: RFR: 8277422: tools/jar/JarEntryTime.java fails with modified time
 mismatch
In-Reply-To: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
References: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
Message-ID: <-dWGbjK868Vqs1KgwJ5bE2HB0Nb3d7r1zuVgE57rpRo=.df47bb18-0465-48a4-80e0-43ada53a3712@github.com>

On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch to address a failure at DST->STD offset transition.  The fix mirrors what was done for JDK-8190748
> 
> 
> Best,
> Lance

Marked as reviewed by joehw (Reviewer).

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

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

From joehw at openjdk.java.net  Thu Dec  2 02:53:35 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 2 Dec 2021 02:53:35 GMT
Subject: Integrated: 8276141: XPathFactory set/getProperty method
In-Reply-To: <F6wABaJVcGYt6-HOgg3vgcM2SX4X05vnxk32_KmEjSY=.affab610-a2e1-45b4-8f29-7e2b4f04f212@github.com>
References: <F6wABaJVcGYt6-HOgg3vgcM2SX4X05vnxk32_KmEjSY=.affab610-a2e1-45b4-8f29-7e2b4f04f212@github.com>
Message-ID: <BpFMaTls_WRtvhTRn-InHW3Gwr2mFAyDN4sQoofFqlw=.d1e62ce0-1c15-4787-9035-8c0db7ec0631@github.com>

On Tue, 2 Nov 2021 17:31:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add setProperty/getProperty methods to the XPath API so that properties can be supported in the future.

This pull request has now been integrated.

Changeset: b226ab99
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b226ab99c872e791d3ed9fca015cf92847904c34
Stats:     258 lines in 5 files changed: 247 ins; 3 del; 8 mod

8276141: XPathFactory set/getProperty method

Reviewed-by: rriggs, naoto, lancea, iris, alanb

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

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

From mik3hall at gmail.com  Thu Dec  2 03:31:10 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Dec 2021 21:31:10 -0600
Subject: RFR: JDK-8277375: jdeps errors on a class path with a file path
 with no permission
In-Reply-To: <KAKR0LZSOFO3-hQAQg7HD03W_ABbCHdjqAkqaJvtvrY=.d9af690d-1517-4563-8333-1602a896112a@github.com>
References: <cqyqX2F9U81DpuypcfUUwl2zzgGN3-68Gipt0X3uaI4=.f0a739e1-c73c-4986-a46b-fd5ed6627dfe@github.com>
 <69BE88AC-60F9-4002-8E64-B0E092A00546@gmail.com>
 <KAKR0LZSOFO3-hQAQg7HD03W_ABbCHdjqAkqaJvtvrY=.d9af690d-1517-4563-8333-1602a896112a@github.com>
Message-ID: <8F4905C7-BBB8-40F3-916F-54E145AF720A@gmail.com>



> On Nov 29, 2021, at 1:14 PM, Mandy Chung <mchung at openjdk.java.net> wrote:
> 
> On Wed, 24 Nov 2021 12:32:32 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> Would there be any need to scan class path at all? That would mean a module would have a class path dependency wouldn't it?
> 
> One reason of scanning the class path is to detect any split packages and emit warnings.   
> 
>> Yes, I shouldn't of included -cp at all but shouldn't keeps ignore it?
> 
> In general, a module should not depend on any class on the classpath.   However, it's possible that there is any missing dependency i.e. can't be found from its required modules.   One could use `-cp` to add additional libraries for a quick analysis.
> 
> I got your point though.   Scanning class path is not strictly necessary to analyze dependencies and it can be done lazily.   Finding all packages in the unnamed module is just the current implementation.  I'll consider and look into making it lazy.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6531

Sorry,
Didn?t see this.

Thanks for the reply. 

From joehw at openjdk.java.net  Thu Dec  2 06:56:33 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 2 Dec 2021 06:56:33 GMT
Subject: Integrated: 8276657: XSLT compiler tries to define a class with empty
 name
In-Reply-To: <uhp3nR57Qz-AXjjp4M4VFUHx-OAVPYndyo8v6gsm8no=.72eb768d-a6a1-4e35-9ca9-2cf0031b5f61@github.com>
References: <uhp3nR57Qz-AXjjp4M4VFUHx-OAVPYndyo8v6gsm8no=.72eb768d-a6a1-4e35-9ca9-2cf0031b5f61@github.com>
Message-ID: <Ram5BTcSeOmhSgHURqI--gDwH2Pvk49FNV4yUs5DEO0=.1e98987f-ae9d-432b-8f1c-5c6de57dfb62@github.com>

On Tue, 30 Nov 2021 18:53:26 GMT, Joe Wang <joehw at openjdk.org> wrote:

> The result of Util.baseName(systemId) can be empty, causing the compiler to set an empty classname. Add a check to make sure it will not set the empty classname.
> 
> Alternatively, it may report an error, but that would be disruptive. As the transform can proceed without the provided classname (by using the default), adding a check is better than reporting an error.
> 
> I've verified the patch with the proposed fix for JDK-8276241. Harold has also confirmed it fixes the tests in his builds.

This pull request has now been integrated.

Changeset: a093cddd
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a093cdddaf5ab88eb84a147e523db5c3e1be54be
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8276657: XSLT compiler tries to define a class with empty name

Reviewed-by: naoto

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

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

From shade at openjdk.java.net  Thu Dec  2 08:25:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Dec 2021 08:25:26 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <L8DulHyGxNzW-luUfBT7UXaeK2afihaY5BbUAOadsuM=.77eb1741-15b4-4c77-a6da-90a2daf48cd1@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

All right then. Thanks for followups! 

@egahlin, this affects JFR tests a bit: subsumes `jfr_tier_3` into `tier3`, basically. Are you good with this?

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

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

From aleonard at openjdk.java.net  Thu Dec  2 09:52:30 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 09:52:30 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <a6ZdfjhqfsJ-TYBbiXphB04AiiDREJVVwLbLMJjOGWw=.0a82c014-e911-4852-ba70-fb14d85990ae@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John, for a great review. The ZONED parser I believe achieves the same end goal, but I hadn't realized the error messages would be different, as you say it's more clear, i'll change to that.

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

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

From mcimadamore at openjdk.java.net  Thu Dec  2 10:45:29 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 10:45:29 GMT
Subject: Integrated: 8278071: typos in MemorySegment::set,
 MemorySegment::setAtIndex javadoc
In-Reply-To: <QnBoXI95w3DFve4cfunKFqoVUaVACmYwReCltxOS7bM=.74f5728b-2f0a-454f-9721-93a66529d4e6@github.com>
References: <QnBoXI95w3DFve4cfunKFqoVUaVACmYwReCltxOS7bM=.74f5728b-2f0a-454f-9721-93a66529d4e6@github.com>
Message-ID: <8stLd0iEYbqFO9c_RiChJnpXcmaDyOESJe_fQPDvjQg=.d4721722-d409-498c-bd0b-f6387fd52e5c@github.com>

On Wed, 1 Dec 2021 13:49:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There are some truncated statements in MemorySegment::get/MemorySegment::getAtIndex javadoc, more specifically in the `@throws` for `IndexOutOfBoundsException`.

This pull request has now been integrated.

Changeset: 16cfbc4f
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16cfbc4f4c0e979160cc8fb946453fa8afa5d1cc
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8278071: typos in MemorySegment::set, MemorySegment::setAtIndex javadoc

Reviewed-by: iris

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

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

From aleonard at openjdk.java.net  Thu Dec  2 10:59:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 10:59:20 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation
In-Reply-To: <OYXY3EfnLesP0j3ctkTaMLftQoKHmzeCYBxO3J8Z6Iw=.0414edba-4953-4d77-901b-de1cccb696d1@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <OYXY3EfnLesP0j3ctkTaMLftQoKHmzeCYBxO3J8Z6Iw=.0414edba-4953-4d77-901b-de1cccb696d1@github.com>
Message-ID: <YUGA1y62YYO6pW3TmVVA6u2FVCGBeSI0fm68BKcFhxs=.4ff07036-f6eb-4c88-8b77-2c16da437308@github.com>

On Thu, 2 Dec 2021 00:09:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have a question related to the custom cacerts which can be added to the OpenJDK bundle. How do you pass the tests like test/jdk/sun/security/lib/cacerts/VerifyCACerts.java using that custom jdk bundle? Probably we can add an additional configuration to that test so it will check the custom cacerts passed to the build as well?

@mrserb 
So VerifyCACerts is specific to the make/data/cacerts certificates, the README specifically states there that when those are updated VerifyCACerts needs updating. It checks things like fingerprints etc..

If a developer or other provider decide to provide their own cacerts file, then it is up to them to have verified and trust those certificates. They won't run the VerifyCACerts which is specific to the openjdk certs.
This is the case at Adoptium for example, which uses the Mozilla trusted CA certs.

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

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

From egahlin at openjdk.java.net  Thu Dec  2 11:09:23 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 2 Dec 2021 11:09:23 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <L8DulHyGxNzW-luUfBT7UXaeK2afihaY5BbUAOadsuM=.77eb1741-15b4-4c77-a6da-90a2daf48cd1@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <L8DulHyGxNzW-luUfBT7UXaeK2afihaY5BbUAOadsuM=.77eb1741-15b4-4c77-a6da-90a2daf48cd1@github.com>
Message-ID: <u9F2rwaE1ttRvNHqPAY2Q6Jc8bOV-CCwy5Tnw-wYOhc=.e6a3f23a-5a94-437c-9735-bf570216612d@github.com>

On Thu, 2 Dec 2021 08:21:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> All right then. Thanks for followups!
> 
> @egahlin, @mgronlun: this affects JFR tests a bit, subsumes `jfr_tier_3` into `tier3`, basically. Are you good with this?

Seems reasonable.

I'm reluctant to become (R)eviewer on this, since this is basically the first time I have looked at the TEST.groups file. There must be somebody who knows this better than me and that can become a second reviewer.

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

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

From mcimadamore at openjdk.java.net  Thu Dec  2 11:27:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 11:27:12 GMT
Subject: RFR: 8277924: Small tweaks to foreign function and memory API [v5]
In-Reply-To: <Xvvjbr2vqHuBUWusZMiDQaEgz_7uH1aQfw5R7zkJKxo=.a7d4af6c-9e87-4446-946d-27e97a9a9362@github.com>
References: <Xvvjbr2vqHuBUWusZMiDQaEgz_7uH1aQfw5R7zkJKxo=.a7d4af6c-9e87-4446-946d-27e97a9a9362@github.com>
Message-ID: <XgIRBPqzlM__hB7n__cIgQpqtiqLtLNB4YDnrXq7rus=.ec1e6d87-83af-41ec-a4fb-abc8e669ca5b@github.com>

> Following integration of the second incubator of the foreign function and memory API [1], we detected few divergences between the contents of the jdk repo and the panama repo:
> 
> * the name of some of the `FunctionDescriptor` wither methods is different (e.g. `withAppendedLayoutArguments` vs. `appendLayoutArguments`), as it has been simplified and improved following a change that was not incorporated in [1].
> 
> * TestUpcall does not execute all the test combinations, because of an issue in the jtreg header (also fixed in the panama repo)
> 
> * Addressing some feedback, we would like to bring back alignment to JAVA_INT layout constants (and related constants). 
> 
> Javadoc: http://cr.openjdk.java.net/~mcimadamore/8277924/v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff: http://cr.openjdk.java.net/~mcimadamore/8277924/v1/spec_diff/overview-summary.html
> 
> [1] - #5907

Maurizio Cimadamore 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:

 - Revert test change
 - Merge branch 'master' into value_layout_align
 - Simplify FunctionDescriptor::insertArgumentLayouts
 - Drop changes to alignment of layout constants
 - Simplify logic to access package-private method in ValueLayout
 - Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Further tweak to javadoc of layout constants
 - Wrong alignment constraints in ValueLayout constants javadoc
 - Tweak javadoc
 - Fix jtreg header on TestUpcall
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/26afe572...f3f78190

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6589/files
  - new: https://git.openjdk.java.net/jdk/pull/6589/files/c305199c..f3f78190

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

  Stats: 7127 lines in 257 files changed: 4342 ins; 1547 del; 1238 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6589/head:pull/6589

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

From mcimadamore at openjdk.java.net  Thu Dec  2 11:27:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 11:27:12 GMT
Subject: Integrated: 8277924: Small tweaks to foreign function and memory API
In-Reply-To: <Xvvjbr2vqHuBUWusZMiDQaEgz_7uH1aQfw5R7zkJKxo=.a7d4af6c-9e87-4446-946d-27e97a9a9362@github.com>
References: <Xvvjbr2vqHuBUWusZMiDQaEgz_7uH1aQfw5R7zkJKxo=.a7d4af6c-9e87-4446-946d-27e97a9a9362@github.com>
Message-ID: <fZbMlOLVFAIojXBEerDCxUrBQzpKqXVmvK4gyBz9g0c=.cd07d7eb-e5b1-49dd-88a4-78946c1b8ae0@github.com>

On Mon, 29 Nov 2021 11:22:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Following integration of the second incubator of the foreign function and memory API [1], we detected few divergences between the contents of the jdk repo and the panama repo:
> 
> * the name of some of the `FunctionDescriptor` wither methods is different (e.g. `withAppendedLayoutArguments` vs. `appendLayoutArguments`), as it has been simplified and improved following a change that was not incorporated in [1].
> 
> * TestUpcall does not execute all the test combinations, because of an issue in the jtreg header (also fixed in the panama repo)
> 
> * Addressing some feedback, we would like to bring back alignment to JAVA_INT layout constants (and related constants). 
> 
> Javadoc: http://cr.openjdk.java.net/~mcimadamore/8277924/v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff: http://cr.openjdk.java.net/~mcimadamore/8277924/v1/spec_diff/overview-summary.html
> 
> [1] - #5907

This pull request has now been integrated.

Changeset: ea905bd3
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea905bd3dad5fc1baad66e714bdd01fa679d2d46
Stats:     84 lines in 7 files changed: 46 ins; 5 del; 33 mod

8277924: Small tweaks to foreign function and memory API

Reviewed-by: jvernee, psandoz

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

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

From aleonard at openjdk.java.net  Thu Dec  2 12:00:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:00:43 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v15]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <dN4BOng01bsio75VfS9Odqr7S7YQCNeFE9nzR-HRWNk=.e1b2ddb3-84ab-461d-8988-131caba5e87c@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/e002bfec...8e60bb77

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=14
  Stats: 330 lines in 8 files changed: 306 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From aleonard at openjdk.java.net  Thu Dec  2 12:00:47 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:00:47 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>
Message-ID: <1TVeAXO1-tjT6C9SqhRYMfZeJ2eo-k0hGEL8pgy6qNM=.70576808-e0f1-41b2-9bd5-daa218f6b4c8@github.com>

On Thu, 2 Dec 2021 00:09:15 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>>   
>>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>
> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 199:
> 
>> 197:                 void process(Main jartool, String opt, String arg) throws BadArgs {
>> 198:                     try {
>> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
> 
> The `ISO_ZONED_DATE_TIME` parser works better here.

done

> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 201:
> 
>> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
>> 200:                                            .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
>> 201:                         if (jartool.date.getYear() < 1980 || jartool.date.getYear() > 2099) {
> 
> This `if` test can end up with consequences down to the millisecond of the instant provided, if present. (Try `1980-01-01T00:00:00.001Z` vs. `1980-01-01T00:00:00Z` and check for extended headers.) How about something like the following?
> 
> 
>     ... ZonedDateTime TIME_MIN = ZonedDateTime.parse("1980-01-01T00:00:02Z");
>     ... ZonedDateTime TIME_MAX = ZonedDateTime.parse("2099-12-31T23:59:59Z");
>     ...
>         var zoned = ZonedDateTime.parse(date, DateTimeFormatter.ISO_ZONED_DATE_TIME);
>         if (zoned.isBefore(TIME_MIN) || zoned.isAfter(TIME_MAX)) {
>             ....

done

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 88:
> 
>> 86:         date {0} is not a valid ISO 8601 date and time
>> 87: error.date.out.of.range=\
>> 88:         date {0} is not within the valid year range 1980->2099 
> 
> Maybe just define `date {0} is not within the valid range` and put the exact interval in the *man* pages and documentation?

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1164:
> 
>> 1162:         public LocalDateTime convert(String value) {
>> 1163:             try {
>> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
> 
> The `ISO_ZONED_DATE_TIME` parser works better here.

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1166:
> 
>> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
>> 1165:                                          .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
>> 1166:                 if (date.getYear() < 1980 || date.getYear() > 2099) {
> 
> See previous comment for this line in the `jar` tool.

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:
> 
>> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
>> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
>> 111: err.date.out.of.range=--date {0} is out of the valid year range 1980->2099
> 
> As before, perhaps refer to the exact range in the documentation? It's really an instant on the time line that is being compared and not the actual year digits that were provided in the command-line option.

done

> test/jdk/tools/jar/JarEntryTime.java line 180:
> 
>> 178:                                 "2022-03-15T00:00:00+06:00",
>> 179:                                 "2038-11-26T06:06:06+00:00",
>> 180:                                 "2098-02-18T00:00:00-08:00"};
> 
> It would be great to test just inside the exact boundaries of the permitted interval here. That is, test `1980-01-01T00:00:02+00:00` and `2099-12-31T23:59:59+00:00`.

done

> test/jdk/tools/jar/JarEntryTime.java line 251:
> 
>> 249:         // Negative Tests --date out of range source date
>> 250:         String[] badSourceDates = {"1976-06-24T01:02:03+00:00",
>> 251:                                    "2100-02-18T00:00:00-11:00"};
> 
> It would be great to test just outside the exact boundaries of the permitted interval here. That is, test `1980-01-01T00:00:01+00:00` and `2100-01-01T00:00:00+00:00`.

done

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

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

From aleonard at openjdk.java.net  Thu Dec  2 12:13:03 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:13:03 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
Message-ID: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>

> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard 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:

 - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
 - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6647/files
  - new: https://git.openjdk.java.net/jdk/pull/6647/files/1084c4e1..16c5ca6b

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

  Stats: 1879 lines in 62 files changed: 1045 ins; 297 del; 537 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6647.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6647/head:pull/6647

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

From aleonard at openjdk.java.net  Thu Dec  2 12:13:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:13:07 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <bqVvSG4f4MrMMi3PI9g26VY7WLhR-8SjTKKjz4dQ4o4=.8094ae02-baf4-4a23-8c2c-b52cf2b5f1e5@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <bqVvSG4f4MrMMi3PI9g26VY7WLhR-8SjTKKjz4dQ4o4=.8094ae02-baf4-4a23-8c2c-b52cf2b5f1e5@github.com>
Message-ID: <aD7W3eJCxZX9Aw-gDwzu9SInEBT1L8Pg7E7oOK4bZrA=.3ac99b12-0e74-40e8-8ef3-1ac27f602ad3@github.com>

On Wed, 1 Dec 2021 18:47:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Andrew Leonard 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:
>> 
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/autoconf/jdk-options.m4 line 176:
> 
>> 174:       [specify alternative cacerts source folder containing certificates])])
>> 175:   AC_MSG_CHECKING([for cacerts source])
>> 176:   if test "x$with_cacerts_src" == x; then
> 
> Before this if block, please assign an empty value to CACERTS_SRC. Otherwise, if the user happens to have that variable set in the environment, that value will get recorded by configure, which is usually not something we want.

done

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

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

From david.holmes at oracle.com  Thu Dec  2 12:13:33 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Dec 2021 22:13:33 +1000
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <L8DulHyGxNzW-luUfBT7UXaeK2afihaY5BbUAOadsuM=.77eb1741-15b4-4c77-a6da-90a2daf48cd1@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <L8DulHyGxNzW-luUfBT7UXaeK2afihaY5BbUAOadsuM=.77eb1741-15b4-4c77-a6da-90a2daf48cd1@github.com>
Message-ID: <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>

On 2/12/2021 6:25 pm, Aleksey Shipilev wrote:
> On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 
> All right then. Thanks for followups!

Hi Aleksey,

I've solicited feedback from core-libs folk as this affects them the 
most. At present we, Oracle, run the jdk_svc tests as part of hotspot 
testing, but this change will suddenly cause jdk testing to include 
them. That is probably not an issue for testing within the CI framework 
but developers running jdk_tier3 locally, often, may have an unpleasant 
surprise at running over a thousand additional tests that probably have 
zero relevance to what they are trying to test. Local machines may take 
considerably longer than the 8+ minutes that you listed.

David

> @egahlin, this affects JFR tests a bit: subsumes `jfr_tier_3` into `tier3`, basically. Are you good with this?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6619
> 

From mcimadamore at openjdk.java.net  Thu Dec  2 12:35:37 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 12:35:37 GMT
Subject: RFR: 8278145: Javadoc for MemorySegment::set/MemorySegment::setAtIndex
 is missing throws tag
Message-ID: <d-sB9aLt81a8kEIcpCLcJ-mR4cScasUFme3synlPI14=.62f5fd29-03bd-4f93-827d-35e02f8a46f4@github.com>

This patch adds missing `@throws` tags to the javadoc of `MemorySegment::set` and `MemorySegment::setAtIndex`.
These methods can fail with `UnsupportedOperationException` if the segment is read-only.

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

Commit messages:
 - Add missing @throws tags

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

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

From sundar at openjdk.java.net  Thu Dec  2 12:35:38 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 2 Dec 2021 12:35:38 GMT
Subject: RFR: 8278145: Javadoc for
 MemorySegment::set/MemorySegment::setAtIndex is missing throws tag
In-Reply-To: <d-sB9aLt81a8kEIcpCLcJ-mR4cScasUFme3synlPI14=.62f5fd29-03bd-4f93-827d-35e02f8a46f4@github.com>
References: <d-sB9aLt81a8kEIcpCLcJ-mR4cScasUFme3synlPI14=.62f5fd29-03bd-4f93-827d-35e02f8a46f4@github.com>
Message-ID: <yOuamGwFFplVLVyAXm9jgvq7SwOlfKSRe3L0qVePxVA=.812e0aef-7265-4f55-93bc-4a29651d2272@github.com>

On Thu, 2 Dec 2021 12:26:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds missing `@throws` tags to the javadoc of `MemorySegment::set` and `MemorySegment::setAtIndex`.
> These methods can fail with `UnsupportedOperationException` if the segment is read-only.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From shade at openjdk.java.net  Thu Dec  2 12:48:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Dec 2021 12:48:27 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
Message-ID: <oBDw0BXuwBV-KVWqNkEVMCayGTM1EqLVxb_zgEB_tZQ=.3364f3fb-488c-4522-bfe4-03f5a2f896b9@github.com>

On Thu, 2 Dec 2021 12:15:51 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I've solicited feedback from core-libs folk as this affects them the most. At present we, Oracle, run the jdk_svc tests as part of hotspot testing, but this change will suddenly cause jdk testing to include them. That is probably not an issue for testing within the CI framework but developers running jdk_tier3 locally, often, may have an unpleasant surprise at running over a thousand additional tests that probably have zero relevance to what they are trying to test.

Thanks, no problem, this is not urgent. 

I think tiered testing is by definition tests things broadly, beyond the scope of feature-centric test groups. I think not breaking JDK management APIs and JFR (that I believe includes JDK events too) would is the useful check for a high jdk:tier3.

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

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

From jlaskey at openjdk.java.net  Thu Dec  2 13:03:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 2 Dec 2021 13:03:30 GMT
Subject: Integrated: JDK-8273056 java.util.random does not correctly sample
 exponential or Gaussian distributions
In-Reply-To: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
References: <6Xp17w7C1-61WLSkvuKgjjvLf4Asn6dSQm16cNb7Kxk=.9f6dc02e-5687-42eb-bed6-59cc9366a09b@github.com>
Message-ID: <MHJQt4ZR1cB8M17mn4Gb5V5K8hkOG1WRRKjA2WxEnOQ=.02a93769-7af4-470b-9bda-07d6ceae7bc5@github.com>

On Thu, 11 Nov 2021 13:59:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The modified ziggurat algorithm is not correctly implemented in `java.base/jdk/internal/util/random/RandomSupport.java`. 
> 
> Create a histogram of a million samples using 2000 uniform bins with the following range: 
> Exponential range from 0 to 12. Gaussian range from -8 to 8. 
> 
> This does not pass a Chi-square test. If you look at the histogram it is obviously not showing the shape of the PDF for these distributions. Look closely at the range around zero (e.g. +/- 0.5).

This pull request has now been integrated.

Changeset: 3d98ec1b
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d98ec1b7bc77237177ecfc069c0e9a7e75829bc
Stats:     15 lines in 1 file changed: 6 ins; 4 del; 5 mod

8273056: java.util.random does not correctly sample exponential or Gaussian distributions

Co-authored-by: Guy Steele <gls at openjdk.org>
Reviewed-by: bpb, darcy

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

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

From erikj at openjdk.java.net  Thu Dec  2 13:58:25 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Dec 2021 13:58:25 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
Message-ID: <wQDeXK-J_0L0-sntqp0-psHxPEYsd94h-m0bsBWeXEI=.427c1bc6-80d1-4e19-b57c-b2ebd064ab70@github.com>

On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard 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:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Looks good!

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

Marked as reviewed by erikj (Reviewer).

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

From herrick at openjdk.java.net  Thu Dec  2 14:12:32 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 2 Dec 2021 14:12:32 GMT
Subject: Integrated: JDK-8276837: [macos]: Error when signing the additional
 launcher
In-Reply-To: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
References: <OKNgzBR-7wFd4usfR-VLl3chR4kBOntcieaRJbJgek8=.9dbfbe20-37fb-407a-8ee5-109bcad124f2@github.com>
Message-ID: <_8LK6l9VItP2S1gZcE_ogXDN3tENpYpbuoi8wm--2T4=.f42687c7-f9b4-4267-9609-2e1b5e5284be@github.com>

On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> - We need to unsign all executables and libraries in the app-image before signing. (not just those in the runtime).
>  - Clean up excessive output by executing the individual file sign and unsigning commands in quiet mode.
>  - Add conditions in SigningAppImageTest to test signing of additional launchers.

This pull request has now been integrated.

Changeset: 76968979
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7696897932a35708b1632517127c1a3a59919878
Stats:     52 lines in 3 files changed: 21 ins; 5 del; 26 mod

8276837: [macos]: Error when signing the additional launcher

Reviewed-by: asemenyuk, almatvee

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

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

From rkennke at openjdk.java.net  Thu Dec  2 14:30:07 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 14:30:07 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v5]
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <YAcQY7z0cxr3inOyKJ0VSHdI-nzAuL6Ec4Zv1iv0Fjg=.039a79c1-9d18-4028-8fb3-67f7e00a5ac0@github.com>

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

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

  Implement ClassCache: reclaim entries under memory pressure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6375/files
  - new: https://git.openjdk.java.net/jdk/pull/6375/files/b7d53adc..570fac15

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

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

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

From rkennke at openjdk.java.net  Thu Dec  2 14:30:13 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 14:30:13 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v4]
In-Reply-To: <oBtYO8OJwEpf_59DHI7fE2QXEb2BTtOr28IF4DJgLoU=.935ecf28-7c66-4156-9b41-91fa7395822f@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <GxF0lIhMoXZBbIw1MrqD8pmkNsR5V7RgZq5RsG2hPF8=.be5d7458-9fe7-4fc1-8980-5ec717b5ccc8@github.com>
 <oBtYO8OJwEpf_59DHI7fE2QXEb2BTtOr28IF4DJgLoU=.935ecf28-7c66-4156-9b41-91fa7395822f@github.com>
Message-ID: <pPyS_IrUtaqFmxpTStvkcpBXWCjPPV6RYULvSIYhKkY=.77d251b7-9b20-4b4b-8054-a4a8cec3d57b@github.com>

On Wed, 1 Dec 2021 21:09:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Without the use of SoftReference, memory pressure won't release any of the cached info. That seems to swing the other way from overly aggressively freeing memory with the WeakReference (and needing to recompute) as the change originally proposed. Its hard to tell in what environments it might be observed.

Right. The problem with the original code was that the softreference would keep the class from getting unloaded, except when under pressure. Now that the cached value is tied to the object lifetime using ClassValue, we can relatively easily use SoftReference to also make it sensitive to memory pressure. I factored this code out into its own class to avoid making a mess, and to be able to reuse it in subclassAudits (see #6637).

> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:
> 
>> 2131:             if (oldReflector != null) {
>> 2132:                 reflector = oldReflector;
>> 2133:             }
> 
> Map.computeIfAbsent(key, () -> new FieldReflector(matchFields, localDesc));
> might be more compact.

That would be nicer, indeed. Problem is that matchFields throws an InvalidClassException, and that would have to get passed through the lambda.
Also, that problem is pre-existing and not related to the change.

> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 52:
> 
>> 50:         Class<?> loadClass = myOwnClassLoader.loadClass("ObjectStreamClass_MemoryLeakExample");
>> 51:         Constructor con = loadClass.getConstructor();
>> 52:         con.setAccessible(true);
> 
> Isn't the constructor already public?

> 
Yes, but:

test TestOSCClassLoaderLeak.run(): failure
java.lang.IllegalAccessException: class TestOSCClassLoaderLeak cannot access a member of class ObjectStreamClass_MemoryLeakExample with modifiers "public"

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

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

From mullan at openjdk.java.net  Thu Dec  2 14:32:29 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 2 Dec 2021 14:32:29 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
Message-ID: <yBhOsMgb0GurkrqBKqbZWVKtIxbCTLnAuDORDYxG1fk=.85934716-a3e1-4458-b499-d094130623cc@github.com>

On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard 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:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I don?t have any major concerns with this change, as long as the default cacerts are still the ones that are in the JDK. As an aside, using Mozilla's root certificates might be fine for TLS certificates, but if you need to support code signing certificates you may run into issues with missing CAs as Mozilla's Root program does not support that use case. Also, by overriding the roots included in the JDK, you are taking on the responsibility (which is significant, in my opinion) of ensuring that those roots are trusted and have not been compromised, revoked, have weak keys, etc.

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

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

From aleonard at openjdk.java.net  Thu Dec  2 15:15:29 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 15:15:29 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <yBhOsMgb0GurkrqBKqbZWVKtIxbCTLnAuDORDYxG1fk=.85934716-a3e1-4458-b499-d094130623cc@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <yBhOsMgb0GurkrqBKqbZWVKtIxbCTLnAuDORDYxG1fk=.85934716-a3e1-4458-b499-d094130623cc@github.com>
Message-ID: <9birWuJ4GIzSwQHZSrNlLO2fvrHy7bAxvEBqq4t80vc=.c7f7884e-c33e-45ff-b8d6-e3ee84efdb74@github.com>

On Thu, 2 Dec 2021 14:29:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I don?t have any major concerns with this change, as long as the default cacerts are still the ones that are in the JDK. As an aside, using Mozilla's root certificates might be fine for TLS certificates, but if you need to support code signing certificates you may run into issues with missing CAs as Mozilla's Root program does not support that use case. Also, by overriding the roots included in the JDK, you are taking on the responsibility (which is significant, in my opinion) of ensuring that those roots are trusted and have not been compromised, revoked, have weak keys, etc.

@seanjmullan Thanks Sean, I'll pass your comment on, cheers Andrew

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

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

From aleonard at openjdk.java.net  Thu Dec  2 15:35:40 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 15:35:40 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v16]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/8d9cb2ef...290a4903

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=15
  Stats: 330 lines in 8 files changed: 306 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From aleonard at openjdk.java.net  Thu Dec  2 15:40:33 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 15:40:33 GMT
Subject: Integrated: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation
In-Reply-To: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
Message-ID: <l7LO2kncQsFnt_jPv7RuAuX1S3nrEp1CDatQaXZCNgg=.e8c94ccf-6fd8-497a-9167-2ac38e48c68d@github.com>

On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: dc2abc9f
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc2abc9f05c2b7c52aeb242082359c48963f9854
Stats:     22 lines in 3 files changed: 22 ins; 0 del; 0 mod

8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation

Reviewed-by: erikj

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

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

From rriggs at openjdk.java.net  Thu Dec  2 16:19:33 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 16:19:33 GMT
Subject: RFR: 8277322: Document that setting an invalid property
 jdk.serialFilter disables deserialization
In-Reply-To: <u4mvtG6LKYqnbh8FYKETa4MYJUGSK-4syEIn-3qo8b8=.ec0cae66-aac7-4cbb-9f67-f1cf47f868c3@github.com>
References: <u4mvtG6LKYqnbh8FYKETa4MYJUGSK-4syEIn-3qo8b8=.ec0cae66-aac7-4cbb-9f67-f1cf47f868c3@github.com>
Message-ID: <pbh6Hxls2rNfOXAQ5nSFBbsT_W8exKPRV6CWdp0a794=.28fe00c6-067d-4073-8de2-5b51fef69697@github.com>

On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The effects of an invalid `jdk.serialFilter` property are not completely documented. If the value of the system property jdk.serialFilter is invalid, deserialization should not be possible and it should be clear in the specification. 
> 
> Specify an implementation specific exception is thrown in the case where deserialization is invoked after reporting the invalid jdk.serialFilter.

Superceded by https://github.com/openjdk/jdk/pull/6645.

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

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

From rriggs at openjdk.java.net  Thu Dec  2 16:19:33 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 16:19:33 GMT
Subject: Withdrawn: 8277322: Document that setting an invalid property
 jdk.serialFilter disables deserialization
In-Reply-To: <u4mvtG6LKYqnbh8FYKETa4MYJUGSK-4syEIn-3qo8b8=.ec0cae66-aac7-4cbb-9f67-f1cf47f868c3@github.com>
References: <u4mvtG6LKYqnbh8FYKETa4MYJUGSK-4syEIn-3qo8b8=.ec0cae66-aac7-4cbb-9f67-f1cf47f868c3@github.com>
Message-ID: <IuuoOCoIVZJnmVMfGU5NlGjMfPCukI8d1fC12UbpSJs=.3e391eb4-95f7-4983-8f42-fed4725bbe32@github.com>

On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The effects of an invalid `jdk.serialFilter` property are not completely documented. If the value of the system property jdk.serialFilter is invalid, deserialization should not be possible and it should be clear in the specification. 
> 
> Specify an implementation specific exception is thrown in the case where deserialization is invoked after reporting the invalid jdk.serialFilter.

This pull request has been closed without being integrated.

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

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

From rkennke at openjdk.java.net  Thu Dec  2 16:22:02 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 16:22:02 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v6]
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <2FChUUIV-in_3gH0WBc5KrPAyuRi8aPgRvSL8aDpBck=.87eb44e5-9f0a-4ecb-81f9-550dd96154b5@github.com>

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

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

  Remove unnecessary import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6375/files
  - new: https://git.openjdk.java.net/jdk/pull/6375/files/570fac15..57428e0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6375&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6375&range=04-05

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

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

From rriggs at openjdk.java.net  Thu Dec  2 16:22:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 16:22:06 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v5]
In-Reply-To: <YAcQY7z0cxr3inOyKJ0VSHdI-nzAuL6Ec4Zv1iv0Fjg=.039a79c1-9d18-4028-8fb3-67f7e00a5ac0@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <YAcQY7z0cxr3inOyKJ0VSHdI-nzAuL6Ec4Zv1iv0Fjg=.039a79c1-9d18-4028-8fb3-67f7e00a5ac0@github.com>
Message-ID: <jKWIMEmRO_GkAgf5nbRmzEbLyD0-YEXX5JBPlfq5wss=.8629ff36-fc7c-4357-8e16-c432d4ca690f@github.com>

On Thu, 2 Dec 2021 14:30:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement ClassCache: reclaim entries under memory pressure

ObjectStreamClass may have an unnecesary import of `SoftReference`.

Otherwise, looks good to me.

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

Marked as reviewed by rriggs (Reviewer).

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

From msheppar at openjdk.java.net  Thu Dec  2 16:25:24 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Thu, 2 Dec 2021 16:25:24 GMT
Subject: RFR: 8277422: tools/jar/JarEntryTime.java fails with modified time
 mismatch
In-Reply-To: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
References: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
Message-ID: <Vd2OGvVtFNorccsIQaYGBk_dsaJOqv6GfcTxf2t37pQ=.60f7ca33-c50c-4302-9c3e-ff34425ff94a@github.com>

On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch to address a failure at DST->STD offset transition.  The fix mirrors what was done for JDK-8190748
> 
> 
> Best,
> Lance

Marked as reviewed by msheppar (Reviewer).

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

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

From naoto at openjdk.java.net  Thu Dec  2 16:31:22 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Dec 2021 16:31:22 GMT
Subject: RFR: 8277422: tools/jar/JarEntryTime.java fails with modified time
 mismatch
In-Reply-To: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
References: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
Message-ID: <5GZxrmc7jEfFgy1y0sJyT9oOF7PejLqNjHi7JmvAsdA=.7d4eb589-d696-4416-adc8-fb4366081e22@github.com>

On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch to address a failure at DST->STD offset transition.  The fix mirrors what was done for JDK-8190748
> 
> 
> Best,
> Lance

Looks good, Lance. I'd add `noreg-self` label to the JIRA issue.

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

Marked as reviewed by naoto (Reviewer).

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

From lancea at openjdk.java.net  Thu Dec  2 16:37:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Dec 2021 16:37:31 GMT
Subject: Integrated: 8277422: tools/jar/JarEntryTime.java fails with modified
 time mismatch
In-Reply-To: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
References: <LsrouVqBEgyzDSB1LUlisTIHbyML0nj-rOBSuPwVjvs=.24ab4686-2ffe-47f6-99f4-5a34a7948e2f@github.com>
Message-ID: <cd18teBM4Mq80lBSudg1XXB58G1NvkYKY-rml03D_Iw=.b712b1ae-0455-4952-a2d1-bb638ea124b3@github.com>

On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this patch to address a failure at DST->STD offset transition.  The fix mirrors what was done for JDK-8190748
> 
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: ad1ff27b
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ad1ff27b730773a141d73744e5f5a899bdfbea78
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8277422: tools/jar/JarEntryTime.java fails with modified time mismatch

Reviewed-by: joehw, msheppar, naoto

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

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

From ihse at openjdk.java.net  Thu Dec  2 17:39:29 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 17:39:29 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
Message-ID: <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>

On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard 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:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/modules/java.base/Gendata.gmk line 76:

> 74: ifneq ($(CACERTS_SRC), )
> 75:   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
> 76: endif

Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro.

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

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

From ihse at openjdk.java.net  Thu Dec  2 17:39:31 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 17:39:31 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
Message-ID: <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>

On Thu, 2 Dec 2021 17:33:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Andrew Leonard 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:
>> 
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> make/modules/java.base/Gendata.gmk line 76:
> 
>> 74: ifneq ($(CACERTS_SRC), )
>> 75:   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>> 76: endif
> 
> Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro.

I would have expected to see something like:

ifneq ($(CACERTS_SRC), )
  GENDATA_CACERTS_SRC := $(CACERTS_SRC)
else
  GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/
endif

at line 63.

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

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

From aleonard at openjdk.java.net  Thu Dec  2 17:50:15 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 17:50:15 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
Message-ID: <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>

On Thu, 2 Dec 2021 17:35:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/Gendata.gmk line 76:
>> 
>>> 74: ifneq ($(CACERTS_SRC), )
>>> 75:   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>>> 76: endif
>> 
>> Does this even work?! You are reassigning the variable after it has been used. The := assignment means that it not a macro.
>
> I would have expected to see something like:
> 
> ifneq ($(CACERTS_SRC), )
>   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
> else
>   GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/
> endif
> 
> at line 63.

you make a valid point, but i've tested this numerous times, but let me check again

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

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

From aleonard at openjdk.java.net  Thu Dec  2 17:50:15 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 17:50:15 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
Message-ID: <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>

On Thu, 2 Dec 2021 17:46:35 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> I would have expected to see something like:
>> 
>> ifneq ($(CACERTS_SRC), )
>>   GENDATA_CACERTS_SRC := $(CACERTS_SRC)
>> else
>>   GENDATA_CACERTS_SRC := $(TOPDIR)/make/data/cacerts/
>> endif
>> 
>> at line 63.
>
> you make a valid point, but i've tested this numerous times, but let me check again

my assumption was the recipe gets resolved later

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

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

From darcy at openjdk.java.net  Thu Dec  2 18:00:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:00:47 GMT
Subject: RFR: JDK-8257856: Make ClassFileVersionsTest.java robust to JDK
 version updates
Message-ID: <BPmYj-eq3nt4faNgDZwJe981NWww4Ox89JmPpkWEY5I=.1aba3acd-6903-4ed8-b949-bee3dda455da@github.com>

Change the test in question to generate its data programmatically to avoid updates with each JDK release. (Assuming this gets pushed before the start of JDK 19, I'll revert the customary changes to the test in set of start-of-19 updates.)

Running the test, it does probe the same set of values:

STDOUT:
test ClassFileVersionsTest.testSupported(53, 0, []): success
test ClassFileVersionsTest.testSupported(53, 0, [STATIC]): success
test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testSupported(54, 0, []): success
test ClassFileVersionsTest.testSupported(55, 0, []): success
test ClassFileVersionsTest.testSupported(56, 0, []): success
test ClassFileVersionsTest.testSupported(57, 0, []): success
test ClassFileVersionsTest.testSupported(58, 0, []): success
test ClassFileVersionsTest.testSupported(59, 0, []): success
test ClassFileVersionsTest.testSupported(60, 0, []): success
test ClassFileVersionsTest.testSupported(61, 0, []): success
test ClassFileVersionsTest.testSupported(62, 0, []): success

test ClassFileVersionsTest.testUnsupported(50, 0, []): success
test ClassFileVersionsTest.testUnsupported(51, 0, []): success
test ClassFileVersionsTest.testUnsupported(52, 0, []): success
test ClassFileVersionsTest.testUnsupported(54, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(55, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(56, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(57, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(58, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(59, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(60, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(61, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(62, 0, [STATIC]): success
test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE]): success
test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE, STATIC]): success
test ClassFileVersionsTest.testUnsupported(63, 0, []): success

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

Commit messages:
 - Appease jcheck.
 - JDK-8257856: Make ClassFileVersionsTest.java robust to JDK version updates

Changes: https://git.openjdk.java.net/jdk/pull/6657/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6657&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257856
  Stats: 69 lines in 1 file changed: 10 ins; 19 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6657/head:pull/6657

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

From aleonard at openjdk.java.net  Thu Dec  2 18:07:16 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 18:07:16 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
Message-ID: <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>

On Thu, 2 Dec 2021 17:48:04 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> you make a valid point, but i've tested this numerous times, but let me check again
>
> my assumption was the recipe gets resolved later

this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html

This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 

but i'm going to double check I was checking the resultant cacerts correctly in my tests

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

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

From alanb at openjdk.java.net  Thu Dec  2 18:15:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Dec 2021 18:15:15 GMT
Subject: RFR: JDK-8257856: Make ClassFileVersionsTest.java robust to JDK
 version updates
In-Reply-To: <BPmYj-eq3nt4faNgDZwJe981NWww4Ox89JmPpkWEY5I=.1aba3acd-6903-4ed8-b949-bee3dda455da@github.com>
References: <BPmYj-eq3nt4faNgDZwJe981NWww4Ox89JmPpkWEY5I=.1aba3acd-6903-4ed8-b949-bee3dda455da@github.com>
Message-ID: <s7gtsrqXH1GSkVLxn4TigbEQ-om7TCX6vrlJlmWU72o=.de98980c-1024-4630-a56c-ac583f1453db@github.com>

On Thu, 2 Dec 2021 02:23:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change the test in question to generate its data programmatically to avoid updates with each JDK release. (Assuming this gets pushed before the start of JDK 19, I'll revert the customary changes to the test in set of start-of-19 updates.)
> 
> Running the test, it does probe the same set of values:
> 
> STDOUT:
> test ClassFileVersionsTest.testSupported(53, 0, []): success
> test ClassFileVersionsTest.testSupported(53, 0, [STATIC]): success
> test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testSupported(54, 0, []): success
> test ClassFileVersionsTest.testSupported(55, 0, []): success
> test ClassFileVersionsTest.testSupported(56, 0, []): success
> test ClassFileVersionsTest.testSupported(57, 0, []): success
> test ClassFileVersionsTest.testSupported(58, 0, []): success
> test ClassFileVersionsTest.testSupported(59, 0, []): success
> test ClassFileVersionsTest.testSupported(60, 0, []): success
> test ClassFileVersionsTest.testSupported(61, 0, []): success
> test ClassFileVersionsTest.testSupported(62, 0, []): success
> 
> test ClassFileVersionsTest.testUnsupported(50, 0, []): success
> test ClassFileVersionsTest.testUnsupported(51, 0, []): success
> test ClassFileVersionsTest.testUnsupported(52, 0, []): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(63, 0, []): success

Thanks for doing this, saves work at each release.

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

Marked as reviewed by alanb (Reviewer).

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

From darcy at openjdk.java.net  Thu Dec  2 18:21:20 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:21:20 GMT
Subject: Integrated: JDK-8257856: Make ClassFileVersionsTest.java robust to JDK
 version updates
In-Reply-To: <BPmYj-eq3nt4faNgDZwJe981NWww4Ox89JmPpkWEY5I=.1aba3acd-6903-4ed8-b949-bee3dda455da@github.com>
References: <BPmYj-eq3nt4faNgDZwJe981NWww4Ox89JmPpkWEY5I=.1aba3acd-6903-4ed8-b949-bee3dda455da@github.com>
Message-ID: <oX4RXHHMNkA3KG01RJ-N7RGBzVQHD7yg8hT0-jheA34=.f3a8a5d8-59ba-444b-9bac-5412b3ba7af6@github.com>

On Thu, 2 Dec 2021 02:23:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change the test in question to generate its data programmatically to avoid updates with each JDK release. (Assuming this gets pushed before the start of JDK 19, I'll revert the customary changes to the test in set of start-of-19 updates.)
> 
> Running the test, it does probe the same set of values:
> 
> STDOUT:
> test ClassFileVersionsTest.testSupported(53, 0, []): success
> test ClassFileVersionsTest.testSupported(53, 0, [STATIC]): success
> test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testSupported(53, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testSupported(54, 0, []): success
> test ClassFileVersionsTest.testSupported(55, 0, []): success
> test ClassFileVersionsTest.testSupported(56, 0, []): success
> test ClassFileVersionsTest.testSupported(57, 0, []): success
> test ClassFileVersionsTest.testSupported(58, 0, []): success
> test ClassFileVersionsTest.testSupported(59, 0, []): success
> test ClassFileVersionsTest.testSupported(60, 0, []): success
> test ClassFileVersionsTest.testSupported(61, 0, []): success
> test ClassFileVersionsTest.testSupported(62, 0, []): success
> 
> test ClassFileVersionsTest.testUnsupported(50, 0, []): success
> test ClassFileVersionsTest.testUnsupported(51, 0, []): success
> test ClassFileVersionsTest.testUnsupported(52, 0, []): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(54, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(55, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(56, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(57, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(58, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(59, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(60, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(61, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [STATIC]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE]): success
> test ClassFileVersionsTest.testUnsupported(62, 0, [TRANSITIVE, STATIC]): success
> test ClassFileVersionsTest.testUnsupported(63, 0, []): success

This pull request has now been integrated.

Changeset: 8b042d14
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8b042d14b78c66b50495d0d8b559ca3f6744d806
Stats:     69 lines in 1 file changed: 10 ins; 19 del; 40 mod

8257856: Make ClassFileVersionsTest.java robust to JDK version updates

Reviewed-by: alanb

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

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

From darcy at openjdk.java.net  Thu Dec  2 18:29:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:29:41 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v7]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <VyhYwb8d_zFqpeKiat7Gi4ooytJrD6Lb-NdvUkHFcrA=.d22c2f8c-8eda-409c-ab3b-35d7ba34c3ad@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8b042d14...b1b4ae2b

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=06
  Stats: 3280 lines in 67 files changed: 3237 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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

From erikj at openjdk.java.net  Thu Dec  2 18:49:18 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Dec 2021 18:49:18 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
Message-ID: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>

On Thu, 2 Dec 2021 18:03:50 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> my assumption was the recipe gets resolved later
>
> this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
> 
> This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 
> 
> but i'm going to double check I was checking the resultant cacerts correctly in my tests

Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.

I very much agree with Magnus that this conditional belongs around line 63.

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

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

From rkennke at openjdk.java.net  Thu Dec  2 19:06:16 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 19:06:16 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v5]
In-Reply-To: <jKWIMEmRO_GkAgf5nbRmzEbLyD0-YEXX5JBPlfq5wss=.8629ff36-fc7c-4357-8e16-c432d4ca690f@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <YAcQY7z0cxr3inOyKJ0VSHdI-nzAuL6Ec4Zv1iv0Fjg=.039a79c1-9d18-4028-8fb3-67f7e00a5ac0@github.com>
 <jKWIMEmRO_GkAgf5nbRmzEbLyD0-YEXX5JBPlfq5wss=.8629ff36-fc7c-4357-8e16-c432d4ca690f@github.com>
Message-ID: <02w_ES9-Itl5doDgEdUOmhY85WUZv9elXl8ddnzJWbI=.4c8ddc50-cf19-41d8-84b4-6a76d4f27eb3@github.com>

On Thu, 2 Dec 2021 16:14:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement ClassCache: reclaim entries under memory pressure
>
> ObjectStreamClass may have an unnecesary import of `SoftReference`.
> 
> Otherwise, looks good to me.

Thanks, @RogerRiggs!
@plevart does that also look reasonable to you?

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

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

From rriggs at openjdk.java.net  Thu Dec  2 19:07:16 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 19:07:16 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
Message-ID: <EEdwtz6ugFMmdsaZYHvTJSOQwiynfCyo3sF-qBzaEZ0=.623aeae7-a59f-4983-bb56-bb98e2f181be@github.com>

On Sat, 20 Nov 2021 10:08:41 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.java.net/browse/JDK-8003417?
> 
> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
> 
> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
> 
> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.

fyi, with this change the JCK did not flag a failure.

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

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

From aleonard at openjdk.java.net  Thu Dec  2 19:15:22 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 19:15:22 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
 <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
Message-ID: <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>

On Thu, 2 Dec 2021 18:46:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> this was my understanding: https://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html
>> 
>> This occurs after make has finished reading all the makefiles and the target is determined to be out of date; so, the recipes for targets which are not rebuilt are never expanded. 
>> 
>> but i'm going to double check I was checking the resultant cacerts correctly in my tests
>
> Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.
> 
> I very much agree with Magnus that this conditional belongs around line 63.

yes, thanks, feeling rather stupid here! i'll raise an issue to fix

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

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

From duke at openjdk.java.net  Thu Dec  2 19:43:19 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 2 Dec 2021 19:43:19 GMT
Subject: Integrated: 8275342: Change nested classes in java.prefs to static
 nested classes
In-Reply-To: <fyVVsmdKouBNQFOB5DtsePDQE4jZ79jUW3PqcVVEZRc=.b73324db-dab3-4053-a7a4-f332ebe1a5cf@github.com>
References: <fyVVsmdKouBNQFOB5DtsePDQE4jZ79jUW3PqcVVEZRc=.b73324db-dab3-4053-a7a4-f332ebe1a5cf@github.com>
Message-ID: <NSwpV4lUxfcEtqD6c4WGZeiQedPNCInKIGOhsbLJOt8=.0a028206-6671-4801-a154-f76a7a13def0@github.com>

On Fri, 15 Oct 2021 18:51:44 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which can be avoided.

This pull request has now been integrated.

Changeset: 30087cc1
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/30087cc1b829e4c2cd77b7c28d077426888160e3
Stats:     20 lines in 3 files changed: 1 ins; 11 del; 8 mod

8275342: Change nested classes in java.prefs to static nested classes

Reviewed-by: dfuchs, rriggs

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

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

From rriggs at openjdk.java.net  Thu Dec  2 19:44:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 19:44:18 GMT
Subject: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs [v4]
In-Reply-To: <f92OiUI_WdAymgX0yBdIM27Vw72PIcz7ArriTxD5GDM=.91ada34a-f561-417e-9299-d79dc5c97fcb@github.com>
References: <DXqYTIapXIiSRwOWNL6b-ZvDhxjlH4swj6880guHOG4=.b578edd5-fd66-4399-bc81-ff86f17371cd@github.com>
 <f92OiUI_WdAymgX0yBdIM27Vw72PIcz7ArriTxD5GDM=.91ada34a-f561-417e-9299-d79dc5c97fcb@github.com>
Message-ID: <0lk9udTfcOdv0mQjKy2bOgVSpulklXMu3SzbN7yH6Tw=.af5a10ad-7f73-4e86-af08-97281e0f8516@github.com>

On Wed, 10 Nov 2021 11:59:16 GMT, Hendrik Schreiber <hschreiber at openjdk.org> wrote:

>> Trivial improvement.
>> 
>> Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`.
>> Repeat (again) in the code example that the `State` `Runnable `should be implemented as static class and not reference the instance to be cleaned, to make the point even more clear to those people who never read the javadoc *prose*.
>> 
>> I have signed the OCA a while back as [hschreiber](https://openjdk.java.net/census#hschreiber).
>
> Hendrik Schreiber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added extra info to Cleaner comment.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.java.net  Thu Dec  2 19:52:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 19:52:18 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
In-Reply-To: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
Message-ID: <1nnsvpLLQktmQS-49pMILz5nsqtkMTzEUt8Ex_to9e0=.b8b1a67d-c7fd-443d-b021-3e8a39999cdf@github.com>

On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From mchung at openjdk.java.net  Thu Dec  2 19:52:18 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 2 Dec 2021 19:52:18 GMT
Subject: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs [v4]
In-Reply-To: <f92OiUI_WdAymgX0yBdIM27Vw72PIcz7ArriTxD5GDM=.91ada34a-f561-417e-9299-d79dc5c97fcb@github.com>
References: <DXqYTIapXIiSRwOWNL6b-ZvDhxjlH4swj6880guHOG4=.b578edd5-fd66-4399-bc81-ff86f17371cd@github.com>
 <f92OiUI_WdAymgX0yBdIM27Vw72PIcz7ArriTxD5GDM=.91ada34a-f561-417e-9299-d79dc5c97fcb@github.com>
Message-ID: <ierd7N_91KaRs-jlFMa_AJ5duHdPjfdtow4yvl2TfNg=.f84e3950-750c-4ddf-832b-f7ce28e1ed89@github.com>

On Wed, 10 Nov 2021 11:59:16 GMT, Hendrik Schreiber <hschreiber at openjdk.org> wrote:

>> Trivial improvement.
>> 
>> Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`.
>> Repeat (again) in the code example that the `State` `Runnable `should be implemented as static class and not reference the instance to be cleaned, to make the point even more clear to those people who never read the javadoc *prose*.
>> 
>> I have signed the OCA a while back as [hschreiber](https://openjdk.java.net/census#hschreiber).
>
> Hendrik Schreiber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added extra info to Cleaner comment.

Marked as reviewed by mchung (Reviewer).

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

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

From ihse at openjdk.java.net  Thu Dec  2 19:57:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 19:57:18 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
 <eG7yZvI4mfso0wtx04mfr6spLrr0yrB17bBmIZUwl-w=.618ac88d-4ee7-4eb2-b8c3-7adae8b1e4e6@github.com>
 <RSU05-OjUEVCKg7zlHr4H9w7GjSTctawLXxXFu6zQiE=.25ca1009-b638-4854-a782-b2adec6db022@github.com>
 <k5N_2k_3YNKtDtJGIDE3eCsPlOV88NUTzt8Tkkf2cFw=.189808c2-04a3-45fe-8221-790a10aa7696@github.com>
 <d0EXlPXv_oDqZWTqyd3jwYQ0kDXonvzsJvjaLgE2iPc=.85f6bb20-a5f1-41e4-a8e0-14df740b0f50@github.com>
 <mmBV0SG_q3Ko0fbrdD1FSWJWOZxVMy7OF5nw562_ZKY=.ce521db4-5cd5-453f-abaf-414d0877781f@github.com>
 <7mR_iCEJRYWqMJhIXOvexTc-Jen4AVFTge91tV1YqSg=.442238f0-c217-4541-8d2c-b1e099814019@github.com>
 <M8K_4WettXBRsfwxU1mMIUsk8Wi79uyLXPnnml5Kiac=.37d440fb-edd7-4e74-ae2f-790324426b30@github.com>
Message-ID: <Vf4tCn1i2Yp63w0m-RNBeYG1C6CinVTB0iHjxfvRmoM=.48f54590-6569-424a-8437-3a5059e19ceb@github.com>

On Thu, 2 Dec 2021 19:12:37 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Oh, I didn't expand the diff far enough to actually see the context correctly when I reviewed this as I would never have imagined the conditional to be placed after the rule. While this will work as so far as using the correct files, incremental builds will not be correct, because the rules are defined in the first pass.
>> 
>> I very much agree with Magnus that this conditional belongs around line 63.
>
> yes, thanks, feeling rather stupid here! i'll raise an issue to fix

@andrew-m-leonard Don't be. Make is a horrible programming language, both syntactically and semantically. It's taken me years to be somewhat comfortable with it, and often I just manage to get it right only by sticking to a few, well-proven and battle-hardened patterns. :)

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

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

From rriggs at openjdk.java.net  Thu Dec  2 20:01:16 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 20:01:16 GMT
Subject: RFR: 8276904: Optional.toString() is unnecessarily expensive
In-Reply-To: <7LPo8Xrb90mML_TUByFyAItiRggBb8lnos2cziqOpuw=.26535767-2bb7-4ae4-bf1e-ef50dc167589@github.com>
References: <7LPo8Xrb90mML_TUByFyAItiRggBb8lnos2cziqOpuw=.26535767-2bb7-4ae4-bf1e-ef50dc167589@github.com>
Message-ID: <q5OM0CFzJJBo1MYwaXAtvuyqzYO7ouwXHraXs4mP7oU=.db757725-3869-48f1-8111-602e4e2c6645@github.com>

On Wed, 10 Nov 2021 17:44:04 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Use string concatenation instead of `String.format`.

Looks ok on the face of it. I would be useful to see the performance of the improvement.

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

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

From duke at openjdk.java.net  Thu Dec  2 20:04:19 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 2 Dec 2021 20:04:19 GMT
Subject: Integrated: 8276806: Use Objects.checkFromIndexSize where possible in
 java.base
In-Reply-To: <rRt4fug6WBvxUSmgBIJxFvjN7J8-Jie3mcTcFIkq8S4=.c82caffa-2215-4690-8de6-3a206230c569@github.com>
References: <rRt4fug6WBvxUSmgBIJxFvjN7J8-Jie3mcTcFIkq8S4=.c82caffa-2215-4690-8de6-3a206230c569@github.com>
Message-ID: <v669UNcDQrBKTBrgD9bkiwt3Mm5CaKC_BYwOYW7ns9c=.1fe123d9-5e9e-4906-89da-c90e6de7658a@github.com>

On Mon, 8 Nov 2021 14:25:10 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> This is a follow-up for https://github.com/openjdk/jdk/pull/4507, looks like there are some cases that were not covered.
> 
> Also this is related to https://github.com/openjdk/jdk/pull/3615

This pull request has now been integrated.

Changeset: 73a9654c
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73a9654c2685e14454a355a16bfe3f6687966f14
Stats:     54 lines in 11 files changed: 11 ins; 14 del; 29 mod

8276806: Use Objects.checkFromIndexSize where possible in java.base

Reviewed-by: rriggs, lancea

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

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

From duke at openjdk.java.net  Thu Dec  2 20:43:56 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Thu, 2 Dec 2021 20:43:56 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
Message-ID: <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>

> This change optimizes random number generators using Math.unsignedMultiplyHigh()

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

  add seeds for the random generators to eliminate run-to-run variance

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6206/files
  - new: https://git.openjdk.java.net/jdk/pull/6206/files/8bde4731..78a45142

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

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

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

From bchristi at openjdk.java.net  Thu Dec  2 20:44:19 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 2 Dec 2021 20:44:19 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source
 [v2]
In-Reply-To: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
 <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
Message-ID: <0gXyEfJJNpaLR25-eBZpRR-Jn8dX0LCYxsEdBI3u5DA=.79af9dd2-895d-4f8c-b853-78a5d1ee2015@github.com>

On Thu, 2 Dec 2021 02:36:47 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8276674 : Malformed Javadoc inline tags in JDK source
>
> Tim Prinzing 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 JDK-8276674
>  - Fixed @code and @link in some javadoc for JDK-8276674

Looks good.  Thanks for renaming, per Pavel's suggestion.  I can sponsor this.

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

Marked as reviewed by bchristi (Reviewer).

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

From duke at openjdk.java.net  Thu Dec  2 20:52:18 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 20:52:18 GMT
Subject: Integrated: JDK-8276674 : Malformed Javadoc inline tags in JDK source
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <TIDuuTFNp21jEDE1HwoI-nTiN8C2ePPoBZFDvmt2aUE=.cbbf6a77-afb1-49a9-bf90-8994656e8c8d@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: 652b5f85
Author:    Tim Prinzing <tim at prinzing.net>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/652b5f8546d0453238166f8fcd0cd3d882886bb4
Stats:     13 lines in 8 files changed: 0 ins; 0 del; 13 mod

8276674: Malformed Javadoc inline tags in JDK source

Reviewed-by: jjg, rriggs, prappo, bchristi

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

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

From duke at openjdk.java.net  Thu Dec  2 21:00:19 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Thu, 2 Dec 2021 21:00:19 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
Message-ID: <p5zllvjRkuZAAjlO0InM06RA2ABjgnOFJnAC0kqgXKM=.f6eaefe8-67c2-4821-8c5d-a6c00c389019@github.com>

On Thu, 2 Dec 2021 20:43:56 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add seeds for the random generators to eliminate run-to-run variance

The following speedups were observed for the JMH benchmarks. L128X128MixRandom shows 8% improvement, L128x256MixRandom shows 6% improvement and L128X1024MixRandom shows 14% improvement. (Another micro workload shows 10% improvement for both L128X128MixRandom and L128x256MixRandom while L128X1024MixRandom shows 25% improvement in performance.)

@JimLaskey Could you please review this PR which optimizes three of the Pseudo-Random Number Generators you implemented in https://bugs.openjdk.java.net/browse/JDK-8248862 ?

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

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

From duke at openjdk.java.net  Thu Dec  2 21:02:40 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:02:40 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
Message-ID: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>

JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

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

Commit messages:
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

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

From rkennke at openjdk.java.net  Thu Dec  2 21:04:18 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 21:04:18 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
In-Reply-To: <1nnsvpLLQktmQS-49pMILz5nsqtkMTzEUt8Ex_to9e0=.b8b1a67d-c7fd-443d-b021-3e8a39999cdf@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
 <1nnsvpLLQktmQS-49pMILz5nsqtkMTzEUt8Ex_to9e0=.b8b1a67d-c7fd-443d-b021-3e8a39999cdf@github.com>
Message-ID: <d0GGmdoijB_w99Qad6_v6lep4UP4Dfe49ZgwMuM1C74=.463c1d69-4792-4dbf-ad82-e5d9e4a78327@github.com>

On Thu, 2 Dec 2021 19:49:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Looks good.

Thank you!
I believe it makes sense to also use the ClassCache here, just as I did in #6375. I'll change this PR accordingly tomorrow.

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

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

From lancea at openjdk.java.net  Thu Dec  2 21:08:17 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Dec 2021 21:08:17 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <BirNhh9Ja_VPIbBsvqXQE9qnyVxSyIi1FqufTfgDhR0=.20a63cea-3b4d-4d8f-9f23-8e060321eff0@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

Marked as reviewed by lancea (Reviewer).

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

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

From rriggs at openjdk.java.net  Thu Dec  2 21:08:17 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 2 Dec 2021 21:08:17 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
In-Reply-To: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
Message-ID: <Psv1qcL30xKd9WubFezlgLrnb6XODyHbs54YoR5nRb0=.55e2968c-141d-4c5d-a984-08223e895bc2@github.com>

On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

The ClassValues are simple Booleans, that won't make much of difference if there's memory pressure and the ClassCache adds more objects and overhead of processing the queue, so I don't think its beneficial.

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

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

From rkennke at openjdk.java.net  Thu Dec  2 21:16:17 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 21:16:17 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
In-Reply-To: <Psv1qcL30xKd9WubFezlgLrnb6XODyHbs54YoR5nRb0=.55e2968c-141d-4c5d-a984-08223e895bc2@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
 <Psv1qcL30xKd9WubFezlgLrnb6XODyHbs54YoR5nRb0=.55e2968c-141d-4c5d-a984-08223e895bc2@github.com>
Message-ID: <hag1GDZymxR1LBVdTFqzDm_LMKKiPVFkxlcAaCD0LgI=.a8535ac6-55a0-4753-b95e-b18ed1e3eb53@github.com>

On Thu, 2 Dec 2021 21:05:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The ClassValues are simple Booleans, that won't make much of difference if there's memory pressure and the ClassCache adds more objects and overhead of processing the queue, so I don't think its beneficial.

Right. Ok thanks, let's wait for #6375 then.

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

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

From aleonard at openjdk.java.net  Thu Dec  2 21:19:33 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 21:19:33 GMT
Subject: RFR: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
Message-ID: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>

PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
This PR moves it before the recipe.

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Commit messages:
 - 8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup

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

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

From duke at openjdk.java.net  Thu Dec  2 21:25:53 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:53 GMT
Subject: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK
 source [v2]
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <GbmF-XM7XVPim_elGvQ6JdprN0moW9rcXDFloSFV32g=.5df294e6-a3f0-4043-bd7b-aebef585ba87@github.com>

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

Tim Prinzing 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 'master' into JDK-8276681
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6486/files
  - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc

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

  Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486

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

From duke at openjdk.java.net  Thu Dec  2 21:25:54 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:54 GMT
Subject: Integrated: JDK-8276681: Additional malformed Javadoc inline tags in
 JDK source
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <bWDNIhKSRZioOMEelJEP6XLFWIVlsL4db0dq8ci1uc8=.65ffd2fa-81ab-43c5-9b2e-f16adc02e97f@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: b8ac0d20
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8276681: Additional malformed Javadoc inline tags in JDK source

Reviewed-by: lancea

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

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

From ihse at openjdk.java.net  Thu Dec  2 21:31:17 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Dec 2021 21:31:17 GMT
Subject: RFR: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
In-Reply-To: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
References: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
Message-ID: <8ZHSQLfnU9pKXYLszivJbGapQ2M0D5Q6lpdEsY_suhc=.ea652bbb-3b6d-49dd-8114-171d23b9aa0f@github.com>

On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
> This PR moves it before the recipe.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thanks for fixing so quickly.

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

Marked as reviewed by ihse (Reviewer).

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

From duke at openjdk.java.net  Thu Dec  2 22:31:39 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Thu, 2 Dec 2021 22:31:39 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero extending
 cast
Message-ID: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>

This patch implements vector unsigned upcast intrinsics for x86. I also fixed a bug in the current implementation where the zero extension masks are computed incorrectly and add relevant tests.

Thank you very much.

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

Commit messages:
 - revert intrinsics
 - Merge branch 'master' into vectorUnsignedCastIntrinsics
 - retain relevant changes

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

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

From psandoz at openjdk.java.net  Thu Dec  2 22:31:43 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 2 Dec 2021 22:31:43 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <JJZnPzbXEu48puK1zGiXLMbtPrxq44rrB5mFcqcOhME=.6a8b0895-1516-4a86-a7fe-62046991d95a@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
 <2MpshpgM8Q5on_qdNcAqweKT6Pe-431p0sKC4fJXRqk=.6129cf7b-79aa-4282-a1a0-2a080ded63b6@github.com>
 <JJZnPzbXEu48puK1zGiXLMbtPrxq44rrB5mFcqcOhME=.6a8b0895-1516-4a86-a7fe-62046991d95a@github.com>
Message-ID: <asbYAXSkxf__mLVl48OBagads43BttBl0g-4hzovA_w=.b0e21db4-af09-4055-9710-72e0fcbc7646@github.com>

On Thu, 2 Dec 2021 22:04:36 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

>> I am inclined to separated out. Fix the bug, add the tests, and integrate for 18. Then enhance with the intrinsics for 19.
>> 
>> If you agree to that I will create two bugs.
>
> @PaulSandoz Yes, I think that should be the case, thank you very much.

@merykitty here you go:

[vectorapi] Mask incorrectly computed for zero extending cast
https://bugs.openjdk.java.net/browse/JDK-8278171

[vectorapi] Add x64 intrinsics for unsigned (zero extended) casts
https://bugs.openjdk.java.net/browse/JDK-8278173

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

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

From duke at openjdk.java.net  Thu Dec  2 22:31:42 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Thu, 2 Dec 2021 22:31:42 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <i5OVBIuulLhXzINrmzxyEsYbmbqkTwHgzCHcHWUGiKo=.2d115422-53b2-4aef-9a23-3e36b68e87ca@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> This patch implements vector unsigned upcast intrinsics for x86. I also fixed a bug in the current implementation where the zero extension masks are computed incorrectly and add relevant tests.
> 
> Thank you very much.

@PaulSandoz Could you take a look at this PR? Also, could you create an issue for this PR, please.
Should this be split into 2, the first one fixes the bug and add tests while the second one implements the intrinsics.
Thank you very much.

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

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

From duke at openjdk.java.net  Thu Dec  2 22:31:42 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Thu, 2 Dec 2021 22:31:42 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <2MpshpgM8Q5on_qdNcAqweKT6Pe-431p0sKC4fJXRqk=.6129cf7b-79aa-4282-a1a0-2a080ded63b6@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
 <2MpshpgM8Q5on_qdNcAqweKT6Pe-431p0sKC4fJXRqk=.6129cf7b-79aa-4282-a1a0-2a080ded63b6@github.com>
Message-ID: <JJZnPzbXEu48puK1zGiXLMbtPrxq44rrB5mFcqcOhME=.6a8b0895-1516-4a86-a7fe-62046991d95a@github.com>

On Thu, 2 Dec 2021 19:55:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch implements vector unsigned upcast intrinsics for x86. I also fixed a bug in the current implementation where the zero extension masks are computed incorrectly and add relevant tests.
>> 
>> Thank you very much.
>
> I am inclined to separated out. Fix the bug, add the tests, and integrate for 18. Then enhance with the intrinsics for 19.
> 
> If you agree to that I will create two bugs.

@PaulSandoz Yes, I think that should be the case, thank you very much.

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

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

From psandoz at openjdk.java.net  Thu Dec  2 22:31:41 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 2 Dec 2021 22:31:41 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <2MpshpgM8Q5on_qdNcAqweKT6Pe-431p0sKC4fJXRqk=.6129cf7b-79aa-4282-a1a0-2a080ded63b6@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> This patch implements vector unsigned upcast intrinsics for x86. I also fixed a bug in the current implementation where the zero extension masks are computed incorrectly and add relevant tests.
> 
> Thank you very much.

I am inclined to separated out. Fix the bug, add the tests, and integrate for 18. Then enhance with the intrinsics for 19.

If you agree to that I will create two bugs.

src/hotspot/cpu/x86/x86.ad line 1819:

> 1817:         return false;
> 1818:       }
> 1819:       break;

Collapse cases, since each has the code code?

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

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

From sviswanathan at openjdk.java.net  Thu Dec  2 22:44:15 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Dec 2021 22:44:15 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
Message-ID: <5DJuC2fuinRNHLIWEeKu-xIuxEHo-ddH5Z3AkhlN5fQ=.60790f60-9f4a-41d1-97f0-21a821e3b374@github.com>

On Thu, 2 Dec 2021 20:43:56 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add seeds for the random generators to eliminate run-to-run variance

@PaulSandoz Could you please also review this small PR.

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

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

From psandoz at openjdk.java.net  Thu Dec  2 23:06:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 2 Dec 2021 23:06:17 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
Message-ID: <UNcBxs4hDq6OqoXjK-mMjt9F2R40aD-MRW4OdxEmMh4=.e3157d05-5014-4700-9ce7-806ade12cad5@github.com>

On Thu, 2 Dec 2021 20:43:56 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add seeds for the random generators to eliminate run-to-run variance

Looks good. Some comments on the benchmark.

test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 57:

> 55:         rngL128X128MixRandom = RandomGeneratorFactory.of("L128X128MixRandom").create(42);
> 56:         rngL128X256MixRandom = RandomGeneratorFactory.of("L128X256MixRandom").create(174);
> 57:         rngL128X1024MixRandom = RandomGeneratorFactory.of("L128X1024MixRandom").create(308);

You can declare parameters:


@Param({"L128X128MixRandom", "L128X256MixRandom", "L128X1024MixRandom"})
String randomGeneratorName;

@Param("1024")
int size;

long[] buffer;
RandomGenerator randomGenerator;


@Setup
public void setup() {
    buffer = new long[size];
    randomGenerator = RandomGeneratorFactory.of(randomGeneratorName)
        .create(randomGeneratorName.hashCode());
}


Then you can simplify to just two benchmark methods. Further, the benchmark can be used for other PRNGs.

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

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

From duke at openjdk.java.net  Thu Dec  2 23:09:23 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Thu, 2 Dec 2021 23:09:23 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <UNcBxs4hDq6OqoXjK-mMjt9F2R40aD-MRW4OdxEmMh4=.e3157d05-5014-4700-9ce7-806ade12cad5@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
 <UNcBxs4hDq6OqoXjK-mMjt9F2R40aD-MRW4OdxEmMh4=.e3157d05-5014-4700-9ce7-806ade12cad5@github.com>
Message-ID: <xgpUwUXlQIL3GeEkRBU7CmH0oN7F6vi6COIDUK1syWE=.7e1741f9-d35f-43dc-9e76-692d473db7f1@github.com>

On Thu, 2 Dec 2021 23:02:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add seeds for the random generators to eliminate run-to-run variance
>
> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 57:
> 
>> 55:         rngL128X128MixRandom = RandomGeneratorFactory.of("L128X128MixRandom").create(42);
>> 56:         rngL128X256MixRandom = RandomGeneratorFactory.of("L128X256MixRandom").create(174);
>> 57:         rngL128X1024MixRandom = RandomGeneratorFactory.of("L128X1024MixRandom").create(308);
> 
> You can declare parameters:
> 
> 
> @Param({"L128X128MixRandom", "L128X256MixRandom", "L128X1024MixRandom"})
> String randomGeneratorName;
> 
> @Param("1024")
> int size;
> 
> long[] buffer;
> RandomGenerator randomGenerator;
> 
> 
> @Setup
> public void setup() {
>     buffer = new long[size];
>     randomGenerator = RandomGeneratorFactory.of(randomGeneratorName)
>         .create(randomGeneratorName.hashCode());
> }
> 
> 
> Then you can simplify to just two benchmark methods. Further, the benchmark can be used for other PRNGs.

Thank you Paul! Will make the necessary changes and update the benchmark...

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

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

From psandoz at openjdk.java.net  Thu Dec  2 23:25:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 2 Dec 2021 23:25:17 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <wlzv-Vy8YVEfuUTQYsxLBbOPlqbxb1hz6qnVqua2hjM=.e442bdec-25dd-42ad-aaea-64a80d626db2@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> When doing an unsigned upcast, we perform a signed cast followed by a bitwise and operation to clip the extended signed bit. The sign clip mask is currently calculated incorrectly, the correct mask should have the number of least significant bit set equal to the size of the source elements. This patch fixes this trivial issue and adds several tests for zero extension casts.
> 
> Thank you very much.

Looks good. Running tests. 

Something we should consider later: split this test out into smaller files and support the max vector. On supported platforms we could consider using the IR test framework to verify the correct IR node is generated.

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

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

From duke at openjdk.java.net  Fri Dec  3 00:17:04 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 00:17:04 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v5]
In-Reply-To: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
Message-ID: <lHyisIp9xmLLqJjWj8i-k2aNiD_gH6d8nvw4eyRr1I4=.61f735de-cc44-44a7-b465-c9209193fc19@github.com>

> This change optimizes random number generators using Math.unsignedMultiplyHigh()

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

  Update the JMH micro to take RNG parameters for elegant implementation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6206/files
  - new: https://git.openjdk.java.net/jdk/pull/6206/files/78a45142..e9c71477

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

  Stats: 35 lines in 1 file changed: 1 ins; 20 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6206.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6206/head:pull/6206

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

From duke at openjdk.java.net  Fri Dec  3 00:17:06 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 00:17:06 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <UNcBxs4hDq6OqoXjK-mMjt9F2R40aD-MRW4OdxEmMh4=.e3157d05-5014-4700-9ce7-806ade12cad5@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
 <UNcBxs4hDq6OqoXjK-mMjt9F2R40aD-MRW4OdxEmMh4=.e3157d05-5014-4700-9ce7-806ade12cad5@github.com>
Message-ID: <iIW3nzXU2FHBiNKlQWprXslRdpyRUNxELuBx9YrTGws=.5ebc974c-2027-4015-988c-6e68dd97d7e1@github.com>

On Thu, 2 Dec 2021 23:02:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add seeds for the random generators to eliminate run-to-run variance
>
> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 57:
> 
>> 55:         rngL128X128MixRandom = RandomGeneratorFactory.of("L128X128MixRandom").create(42);
>> 56:         rngL128X256MixRandom = RandomGeneratorFactory.of("L128X256MixRandom").create(174);
>> 57:         rngL128X1024MixRandom = RandomGeneratorFactory.of("L128X1024MixRandom").create(308);
> 
> You can declare parameters:
> 
> 
> @Param({"L128X128MixRandom", "L128X256MixRandom", "L128X1024MixRandom"})
> String randomGeneratorName;
> 
> @Param("1024")
> int size;
> 
> long[] buffer;
> RandomGenerator randomGenerator;
> 
> 
> @Setup
> public void setup() {
>     buffer = new long[size];
>     randomGenerator = RandomGeneratorFactory.of(randomGeneratorName)
>         .create(randomGeneratorName.hashCode());
> }
> 
> 
> Then you can simplify to just two benchmark methods. Further, the benchmark can be used for other PRNGs.

@PaulSandoz  Implemented the changes you suggested for the benchmark. Tested it on my side and ensured that it's working as expected...

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

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

From psandoz at openjdk.java.net  Fri Dec  3 00:35:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 3 Dec 2021 00:35:17 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v5]
In-Reply-To: <lHyisIp9xmLLqJjWj8i-k2aNiD_gH6d8nvw4eyRr1I4=.61f735de-cc44-44a7-b465-c9209193fc19@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <lHyisIp9xmLLqJjWj8i-k2aNiD_gH6d8nvw4eyRr1I4=.61f735de-cc44-44a7-b465-c9209193fc19@github.com>
Message-ID: <PRs6FUDoEi01fw2hhHPzfLI-TTg3_MYOWLkKI3sQO4U=.75db6592-378b-40c3-bd13-e11f9fcf35ff@github.com>

On Fri, 3 Dec 2021 00:17:04 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the JMH micro to take RNG parameters for elegant implementation

Very nice, much neater, just a few more minor comments.

test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 47:

> 45: public class RandomGeneratorNext {
> 46: 
> 47:     public RandomGenerator randomGenerator;

Suggestion:

    RandomGenerator randomGenerator;

test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 52:

> 50:     String randomGeneratorName;
> 51: 
> 52:     public static long[] buffer;

Suggestion:

    long[] buffer;

test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 69:

> 67: 
> 68:     @Benchmark
> 69:     @Fork(1)

Why is `@Fork` need here?

test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 70:

> 68:     @Benchmark
> 69:     @Fork(1)
> 70:     public void testFillBufferWithNextLong() {

Return `buffer` after the loop completes, just in case the JIT decides it is otherwise dead code

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

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

From jpai at openjdk.java.net  Fri Dec  3 01:54:15 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 3 Dec 2021 01:54:15 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <EEdwtz6ugFMmdsaZYHvTJSOQwiynfCyo3sF-qBzaEZ0=.623aeae7-a59f-4983-bb56-bb98e2f181be@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
 <EEdwtz6ugFMmdsaZYHvTJSOQwiynfCyo3sF-qBzaEZ0=.623aeae7-a59f-4983-bb56-bb98e2f181be@github.com>
Message-ID: <MmFHNHzx8txhWp7BofBtgVqnRNpnsGfZ3t-38AezoNE=.a87641f2-8450-4bd1-a63d-5a5ade8dc07d@github.com>

On Thu, 2 Dec 2021 19:04:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fyi, with this change the JCK did not flag a failure.

Thank you Roger for running those tests.

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

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

From duke at openjdk.java.net  Fri Dec  3 02:14:51 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 02:14:51 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v6]
In-Reply-To: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
Message-ID: <eH0X6XadI6c-nhWH_x5mc4ZLzhl-O4koEIPCcos2rlo=.c12104e9-22a3-4a20-9521-f493be62cb8b@github.com>

> This change optimizes random number generators using Math.unsignedMultiplyHigh()

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

  minor changes to the benchmark

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6206/files
  - new: https://git.openjdk.java.net/jdk/pull/6206/files/e9c71477..cf68fe00

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6206&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6206&range=04-05

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

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

From psandoz at openjdk.java.net  Fri Dec  3 02:14:53 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 3 Dec 2021 02:14:53 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v6]
In-Reply-To: <eH0X6XadI6c-nhWH_x5mc4ZLzhl-O4koEIPCcos2rlo=.c12104e9-22a3-4a20-9521-f493be62cb8b@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <eH0X6XadI6c-nhWH_x5mc4ZLzhl-O4koEIPCcos2rlo=.c12104e9-22a3-4a20-9521-f493be62cb8b@github.com>
Message-ID: <yP5uzMQ3cM2rSEyWyuyE3QyqactWw4B7aJZuepqUQfM=.1995df38-8ef5-435f-a9a4-82d906dddb46@github.com>

On Fri, 3 Dec 2021 02:11:24 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the benchmark

Marked as reviewed by psandoz (Reviewer).

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

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

From duke at openjdk.java.net  Fri Dec  3 02:15:00 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 02:15:00 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v5]
In-Reply-To: <PRs6FUDoEi01fw2hhHPzfLI-TTg3_MYOWLkKI3sQO4U=.75db6592-378b-40c3-bd13-e11f9fcf35ff@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <lHyisIp9xmLLqJjWj8i-k2aNiD_gH6d8nvw4eyRr1I4=.61f735de-cc44-44a7-b465-c9209193fc19@github.com>
 <PRs6FUDoEi01fw2hhHPzfLI-TTg3_MYOWLkKI3sQO4U=.75db6592-378b-40c3-bd13-e11f9fcf35ff@github.com>
Message-ID: <09-EeX2uyCxtlWKxsi7sp2jlkbsYSxNzuisfWJtnx3A=.bda5a5ed-8f86-4a8c-a740-7af938f379f8@github.com>

On Fri, 3 Dec 2021 00:27:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the JMH micro to take RNG parameters for elegant implementation
>
> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 47:
> 
>> 45: public class RandomGeneratorNext {
>> 46: 
>> 47:     public RandomGenerator randomGenerator;
> 
> Suggestion:
> 
>     RandomGenerator randomGenerator;

Incorporated your suggestion in the recent commit...

> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 52:
> 
>> 50:     String randomGeneratorName;
>> 51: 
>> 52:     public static long[] buffer;
> 
> Suggestion:
> 
>     long[] buffer;

Incorporated your suggestion in the recent commit...

> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 69:
> 
>> 67: 
>> 68:     @Benchmark
>> 69:     @Fork(1)
> 
> Why is `@Fork` need here?

Removed the @Fork annotation...

> test/micro/org/openjdk/bench/java/util/RandomGeneratorNext.java line 70:
> 
>> 68:     @Benchmark
>> 69:     @Fork(1)
>> 70:     public void testFillBufferWithNextLong() {
> 
> Return `buffer` after the loop completes, just in case the JIT decides it is otherwise dead code

Added the code to return buffer at the end of the loop...

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

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

From psandoz at openjdk.java.net  Fri Dec  3 02:34:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 3 Dec 2021 02:34:17 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <6KpJdWTbZ4bhWkG86stzrAWE-y1KCZt5gULW5TEm9uQ=.06bddd35-4c1a-4355-b9bc-5a4bb5ab699e@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> When doing an unsigned upcast, we perform a signed cast followed by a bitwise and operation to clip the extended signed bit. The sign clip mask is currently calculated incorrectly, the correct mask should have the number of least significant bit set equal to the size of the source elements. This patch fixes this trivial issue and adds several tests for zero extension casts.
> 
> Thank you very much.

Tests are good.

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

Marked as reviewed by psandoz (Reviewer).

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

From duke at openjdk.java.net  Fri Dec  3 03:47:17 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Fri, 3 Dec 2021 03:47:17 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <78d9uUqiyq-2mp-knENKVcnp3yThseltsgR_QXggmB0=.8860988a-83eb-4a48-904f-45ef45a6d401@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> When doing an unsigned upcast, we perform a signed cast followed by a bitwise and operation to clip the extended signed bit. The sign clip mask is currently calculated incorrectly, the correct mask should have the number of least significant bit set equal to the size of the source elements. This patch fixes this trivial issue and adds several tests for zero extension casts.
> 
> Thank you very much.

Thanks a lot for your support and review. Do I need another review here?

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

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

From duke at openjdk.java.net  Fri Dec  3 05:14:20 2021
From: duke at openjdk.java.net (swati sharma)
Date: Fri, 3 Dec 2021 05:14:20 GMT
Subject: Withdrawn: 8276048: Error in javadoc regarding Long method public
 static Long valueOf(String s)
In-Reply-To: <7wDCDLS9pKMyx9GofGcoZefAHVxIo_xS1Z8L0u7tfoY=.b915799f-017e-49ec-83d7-d8fadfb6320d@github.com>
References: <7wDCDLS9pKMyx9GofGcoZefAHVxIo_xS1Z8L0u7tfoY=.b915799f-017e-49ec-83d7-d8fadfb6320d@github.com>
Message-ID: <sHXfkvJpLuBWNUcfcTpYjPbiDPqNd7wSP5yNhYeQjD0=.fc543f71-6d7d-44bb-8002-38b709c74ffc@github.com>

On Wed, 27 Oct 2021 09:57:43 GMT, swati sharma <duke at openjdk.java.net> wrote:

> 8276048: Error in javadoc regarding Long method public static Long valueOf(String s)
> Fix: Changing integer to {@code Long}

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.java.net  Fri Dec  3 06:45:45 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 06:45:45 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v8]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <iVjwPPaqi-iB1ndHo7Qjil89hrQang7YS_MmMYyWK0g=.9f7e829b-e635-4ad5-a13b-ed369c0a231e@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

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

  Update symbol files to JDK 18 b26.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/b1b4ae2b..88273596

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

  Stats: 610 lines in 3 files changed: 593 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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

From jgneff at openjdk.java.net  Fri Dec  3 06:47:24 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Fri, 3 Dec 2021 06:47:24 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v16]
In-Reply-To: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com>
Message-ID: <NE7s1-HDJ1w0Zi2khE-ZXBSbrOX_CM-Sr8pvHcPLdxk=.9a110fd9-8588-4087-9034-bed0282628a6@github.com>

On Thu, 2 Dec 2021 15:35:40 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/8d9cb2ef...290a4903

I can't think of any more ways to break this. I tested pairs of JavaFX builds again on all six Linux architectures, from 32-bit ARM to IBM mainframe. I tested some of my own Java and JavaFX projects. All builds created identical artifacts: JAR files (classes, sources, and Javadoc), JMOD archives, and even all the files under the `jlink` output directory.

The `jpackage` tool fails to create reproducible Debian packages, but that seems to be nothing more than some inconsistent symbolic links under `lib/runtime/legal`.

Good job, Andrew!

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

Marked as reviewed by jgneff (no project role).

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

From alanb at openjdk.java.net  Fri Dec  3 07:37:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Dec 2021 07:37:17 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
Message-ID: <BLg2HhxGfolAXw75gUrLSwuJLSp2aam9hXOenu45Sp4=.5a120904-2308-45ad-8516-014135fa2f84@github.com>

On Thu, 2 Dec 2021 12:15:51 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I've solicited feedback from core-libs folk as this affects them the most. At present we, Oracle, run the jdk_svc tests as part of hotspot testing, but this change will suddenly cause jdk testing to include them. That is probably not an issue for testing within the CI framework but developers running jdk_tier3 locally, often, may have an unpleasant surprise at running over a thousand additional tests that probably have zero relevance to what they are trying to test. Local machines may take considerably longer than the 8+ minutes that you listed.

I don't expect there are many people that run jdk_tier3 locally. It's a mixed bag of tests for the Panama Vector API, RMI and JFR. Adding jdk_svc to this list just adds to the mix. The only synergy is that the RMI tests will be in the same tier as the JMX tests that use the RMI connectors. No objection to the change, I think it is just a re-balancing of tiers for CI systems.

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

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

From tnakamura at openjdk.java.net  Fri Dec  3 07:46:30 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Fri, 3 Dec 2021 07:46:30 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
Message-ID: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>

Could you review this fix?

Problem:
Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.

Cause and fix:
If module or package name was composed by ASCII then non-ASCII characters, 
ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.

Testing:
tier1 and tier2 on Linux have no regression.
I wasn't able to create an automate test for this issue. I appreciate any advice.

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

Commit messages:
 - 8278185: Custom JRE cannot find non-ASCII named module inside

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

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

From aleonard at openjdk.java.net  Fri Dec  3 08:33:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 08:33:20 GMT
Subject: Integrated: 8278163: --with-cacerts-src variable resolved after
 GenerateCacerts recipe setup
In-Reply-To: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
References: <1t8n2w7T2eWZPSIU9ncIitioV98d65dBlViPH_8wx3g=.b933c668-620b-4b29-9bcd-75a481d66584@github.com>
Message-ID: <A1BC3lVYZPAgVgRGgKyX_oLwbZs78DNLC6iZT1C0VEA=.b357b38c-2d1f-4626-a23c-bf54f9aafd65@github.com>

On Thu, 2 Dec 2021 21:07:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> PR https://github.com/openjdk/jdk/pull/6647 resolved the GENDATA_CACERTS_SRC fir --with-cacerts-src after the recipe, which meant the dependencies were wrong.
> This PR moves it before the recipe.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 45da3aea
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45da3aea22fd85f214e661b2c98631cb91ddb55d
Stats:     8 lines in 1 file changed: 4 ins; 3 del; 1 mod

8278163: --with-cacerts-src variable resolved after GenerateCacerts recipe setup

Reviewed-by: ihse

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

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

From aleonard at openjdk.java.net  Fri Dec  3 10:05:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 10:05:43 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge jdk:master
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=16
  Stats: 329 lines in 8 files changed: 306 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From sundar at openjdk.java.net  Fri Dec  3 10:10:33 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 3 Dec 2021 10:10:33 GMT
Subject: RFR: 8278205: jlink plugins should dump .class file in debug mode
Message-ID: <8_RJoqrrA5nUjmdsUKyM1bKP5Rf9s_d5MQwTrfsaFvk=.2acc3387-e1ec-449d-b4b6-27a65057fdb0@github.com>

jlink plugins dump .class files in debug mode. jpackage tests already set jlink.debug property to true.

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

Commit messages:
 - 8278205: jlink plugins should dump .class file in debug mode

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

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

From jlaskey at openjdk.java.net  Fri Dec  3 12:38:13 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 3 Dec 2021 12:38:13 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <3_bFZNrHz1lV2eXs_8a8yJupCSxUQA4GQ6AOCqY6qBs=.7058051b-7f19-48ea-b9ad-2f9c95239f9f@github.com>

On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

Change looks reasonable. A regression test should be provided. Contact me directly for advice.

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

Changes requested by jlaskey (Reviewer).

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

From jlaskey at openjdk.java.net  Fri Dec  3 12:43:16 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 3 Dec 2021 12:43:16 GMT
Subject: RFR: 8278205: jlink plugins should dump .class file in debug mode
In-Reply-To: <8_RJoqrrA5nUjmdsUKyM1bKP5Rf9s_d5MQwTrfsaFvk=.2acc3387-e1ec-449d-b4b6-27a65057fdb0@github.com>
References: <8_RJoqrrA5nUjmdsUKyM1bKP5Rf9s_d5MQwTrfsaFvk=.2acc3387-e1ec-449d-b4b6-27a65057fdb0@github.com>
Message-ID: <eVsrfjdafx4_QVpkj3rttuQfxG8yY8I-2zARCOwXrwg=.e822a711-e42d-460c-861f-848f11fed9bc@github.com>

On Fri, 3 Dec 2021 10:03:30 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> jlink plugins dump .class files in debug mode. jpackage tests already set jlink.debug property to true.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

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

From jlaskey at openjdk.java.net  Fri Dec  3 12:51:19 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 3 Dec 2021 12:51:19 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v6]
In-Reply-To: <eH0X6XadI6c-nhWH_x5mc4ZLzhl-O4koEIPCcos2rlo=.c12104e9-22a3-4a20-9521-f493be62cb8b@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <eH0X6XadI6c-nhWH_x5mc4ZLzhl-O4koEIPCcos2rlo=.c12104e9-22a3-4a20-9521-f493be62cb8b@github.com>
Message-ID: <wkGFDzWm_AWDY_SZyGqvaj2bD4qvGmX_A1Ku24yTGso=.81ac5a81-6db2-42cf-b61a-447a8756dbfe@github.com>

On Fri, 3 Dec 2021 02:14:51 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> This change optimizes random number generators using Math.unsignedMultiplyHigh()
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the benchmark

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

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

From sundar at openjdk.java.net  Fri Dec  3 13:26:19 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 3 Dec 2021 13:26:19 GMT
Subject: Integrated: 8278205: jlink plugins should dump .class file in debug
 mode
In-Reply-To: <8_RJoqrrA5nUjmdsUKyM1bKP5Rf9s_d5MQwTrfsaFvk=.2acc3387-e1ec-449d-b4b6-27a65057fdb0@github.com>
References: <8_RJoqrrA5nUjmdsUKyM1bKP5Rf9s_d5MQwTrfsaFvk=.2acc3387-e1ec-449d-b4b6-27a65057fdb0@github.com>
Message-ID: <fRdIWMQ2jUUCCcaMlHscorl6l4W4CffeOSEsnJoU1g8=.10702a5b-bcfb-4082-b297-e1b7671c2b21@github.com>

On Fri, 3 Dec 2021 10:03:30 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> jlink plugins dump .class files in debug mode. jpackage tests already set jlink.debug property to true.

This pull request has now been integrated.

Changeset: ba2a8e5a
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ba2a8e5a496799451095362279b9dd4b6df20b67
Stats:     41 lines in 5 files changed: 35 ins; 0 del; 6 mod

8278205: jlink plugins should dump .class file in debug mode

Reviewed-by: jlaskey

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

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

From mcimadamore at openjdk.java.net  Fri Dec  3 13:26:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Dec 2021 13:26:22 GMT
Subject: Integrated: 8278144: Javadoc for
 MemorySegment::set/MemorySegment::setAtIndex is missing throws tag
In-Reply-To: <d-sB9aLt81a8kEIcpCLcJ-mR4cScasUFme3synlPI14=.62f5fd29-03bd-4f93-827d-35e02f8a46f4@github.com>
References: <d-sB9aLt81a8kEIcpCLcJ-mR4cScasUFme3synlPI14=.62f5fd29-03bd-4f93-827d-35e02f8a46f4@github.com>
Message-ID: <ATQwL3S8awigDUjJTY85_tkvLTg1q1V8flEMJKFLo_w=.0cc3d1c8-47ed-474b-af43-7dd0fe988da3@github.com>

On Thu, 2 Dec 2021 12:26:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds missing `@throws` tags to the javadoc of `MemorySegment::set` and `MemorySegment::setAtIndex`.
> These methods can fail with `UnsupportedOperationException` if the segment is read-only.

This pull request has now been integrated.

Changeset: 3f28a214
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f28a21414be32375dc0f4b12d349826bacd4810
Stats:     17 lines in 1 file changed: 17 ins; 0 del; 0 mod

8278144: Javadoc for MemorySegment::set/MemorySegment::setAtIndex is missing throws tag

Reviewed-by: sundar

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

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

From aleonard at openjdk.java.net  Fri Dec  3 13:44:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 13:44:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <MiWcaJhqMh9CbBVG8plCkgPtyTVKoAjYFQCnPz9SaBA=.0acfc66d-2138-487f-9f1f-dc4fce51af2f@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John, for your help with this as well, your platform testing has been most useful as well.
I've Proposed the CSR now (https://bugs.openjdk.java.net/browse/JDK-8277755), so that should go through the approval process..
@AlanBateman @LanceAndersen i'd also like to get your final reviews as well please?
Many thanks
Andrew

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

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

From alanb at openjdk.java.net  Fri Dec  3 13:53:18 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Dec 2021 13:53:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
Message-ID: <FGUZr5Te5YtPUKpsXj3_Uu3Z7Lm1pbkgbCusoGWASmo=.0b663170-2720-4040-8c88-7353c7d19e1d@github.com>

On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see above comment, thanks
> 
> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.

> @AlanBateman @LanceAndersen i'd also like to get your final reviews as well please?

I plan to review this in the coming days.

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

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

From rriggs at openjdk.java.net  Fri Dec  3 15:50:14 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 3 Dec 2021 15:50:14 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
Message-ID: <RPOGUwRTWqI2AFWDslpNBfyTFl3kS-6UoXtQIfDJPdY=.5152c2ff-29bb-4cd7-98ba-636a0b8e3788@github.com>

On Wed, 1 Dec 2021 18:19:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
> incompletely specified. The behavior for invalid values of the properties is different and
> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
> uninitialized. 
> 
> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
> either by system properties supplied on the command line or security properties are logged.
> The `Config` class marks either or both the filter and filter factory values as unusable
> and remembers the exception message.
> 
> Subsequent calls to the methods that get or set the filter or filter factory or create 
> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
> The nature of the invalid property is reported as an `IllegalStateException` on first use.
> 
> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization

@stuart-marks, @jaikiran Please review,  Thanks

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

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

From rriggs at openjdk.java.net  Fri Dec  3 16:37:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 3 Dec 2021 16:37:35 GMT
Subject: RFR: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases.
Message-ID: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>

The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.

In both constructors, add the following to the paragraph the describes invoking the factory:

     * When the filter factory {@code apply} method is invoked it may throw a runtime exception
     * preventing the {@code ObjectInputStream} from being constructed.

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

Commit messages:
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

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

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

From rriggs at openjdk.java.net  Fri Dec  3 16:40:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 3 Dec 2021 16:40:18 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
Message-ID: <QNlWPnaloHRxq60COf1rlL3sT2J_yPmQi9Q9N4p17M8=.900d989d-00c4-48d0-af08-085dcc8c80d6@github.com>

On Sat, 20 Nov 2021 10:08:41 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.java.net/browse/JDK-8003417?
> 
> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
> 
> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
> 
> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.

Looks good to me.  Another set of eyes would be good on this fringe case.

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

Marked as reviewed by rriggs (Reviewer).

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

From psandoz at openjdk.java.net  Fri Dec  3 17:12:23 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 3 Dec 2021 17:12:23 GMT
Subject: RFR: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <78d9uUqiyq-2mp-knENKVcnp3yThseltsgR_QXggmB0=.8860988a-83eb-4a48-904f-45ef45a6d401@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
 <78d9uUqiyq-2mp-knENKVcnp3yThseltsgR_QXggmB0=.8860988a-83eb-4a48-904f-45ef45a6d401@github.com>
Message-ID: <nZLzhORgFUiA0UyVxGGm84ZBzhgp97SfcOQSVDjycmE=.376a937c-6f46-43ed-be79-f7c843987577@github.com>

On Fri, 3 Dec 2021 03:44:09 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> Thanks a lot for your support and review. Do I need another review here?

No need for this one, for next PR for the intrinsics will likely need two HotSpot reviewers.

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

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

From duke at openjdk.java.net  Fri Dec  3 17:12:24 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Fri, 3 Dec 2021 17:12:24 GMT
Subject: Integrated: 8278171: [vectorapi] Mask incorrectly computed for zero
 extending cast
In-Reply-To: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
References: <GzVFIZ0WPZgcxjoK9Sw9FB9Baop_eB5HUcCu8-2fpZY=.673b115c-fa7d-45a8-80aa-86d23318cb13@github.com>
Message-ID: <teoBubeE3DMgbe0rfT2KDLyOpZHuy4aAiKWBHNAnvhk=.61517a81-c223-4c7c-a8b2-322f0c8b78bb@github.com>

On Wed, 1 Dec 2021 12:03:15 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> When doing an unsigned upcast, we perform a signed cast followed by a bitwise and operation to clip the extended signed bit. The sign clip mask is currently calculated incorrectly, the correct mask should have the number of least significant bit set equal to the size of the source elements. This patch fixes this trivial issue and adds several tests for zero extension casts.
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: 2e30fa93
Author:    merykitty <anhmdq99 at gmail.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e30fa936dd5fffceb17d338271f5e725c85801c
Stats:     322 lines in 2 files changed: 321 ins; 0 del; 1 mod

8278171: [vectorapi] Mask incorrectly computed for zero extending cast

Reviewed-by: psandoz

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

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

From psandoz at openjdk.java.net  Fri Dec  3 17:22:18 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 3 Dec 2021 17:22:18 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <p5zllvjRkuZAAjlO0InM06RA2ABjgnOFJnAC0kqgXKM=.f6eaefe8-67c2-4821-8c5d-a6c00c389019@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
 <p5zllvjRkuZAAjlO0InM06RA2ABjgnOFJnAC0kqgXKM=.f6eaefe8-67c2-4821-8c5d-a6c00c389019@github.com>
Message-ID: <UDeNgt13toF82fCb0jnQ7UKM3PKn6StCMEHhP0sYaWs=.fa45f8ec-dc5f-49e5-ba49-d16562477c10@github.com>

On Thu, 2 Dec 2021 20:56:46 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add seeds for the random generators to eliminate run-to-run variance
>
> @JimLaskey Could you please review this PR which optimizes three of the Pseudo-Random Number Generators you implemented in https://bugs.openjdk.java.net/browse/JDK-8248862 ?

@vamsi-parasa you can now integrate this and then I or someone else will sponsor it

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

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

From jgneff at openjdk.java.net  Fri Dec  3 17:42:28 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Fri, 3 Dec 2021 17:42:28 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <od9xwOLsOaRVk4u8h1PBkTKz0nPxitpConZSDvNmG7s=.607eac3d-41d2-409a-8d76-04b28008eb57@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

> @jgneff thank you John, for your help with this as well, your platform testing has been most useful as well.

You're welcome. I did not test on *x64* macOS or Windows, by the way. I'll test JavaFX builds on those platforms as soon as this enhancement is included in an [early-access build][1].

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

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

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

From duke at openjdk.java.net  Fri Dec  3 18:03:12 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 18:03:12 GMT
Subject: RFR: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh() [v4]
In-Reply-To: <UDeNgt13toF82fCb0jnQ7UKM3PKn6StCMEHhP0sYaWs=.fa45f8ec-dc5f-49e5-ba49-d16562477c10@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
 <PT0TxGggJ9zU4n0VCm0F4UaeQTT0fyWfn9f6bT9v2Rc=.66ac2052-26dd-4885-a0d6-4aa80ec5b399@github.com>
 <p5zllvjRkuZAAjlO0InM06RA2ABjgnOFJnAC0kqgXKM=.f6eaefe8-67c2-4821-8c5d-a6c00c389019@github.com>
 <UDeNgt13toF82fCb0jnQ7UKM3PKn6StCMEHhP0sYaWs=.fa45f8ec-dc5f-49e5-ba49-d16562477c10@github.com>
Message-ID: <L5lfsYnKrLJSvGohneBtOd5vZqbh5NcoaUSduOx6mEA=.e767de13-76ed-4a0b-afdf-eccdd85d962e@github.com>

On Fri, 3 Dec 2021 17:19:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @JimLaskey Could you please review this PR which optimizes three of the Pseudo-Random Number Generators you implemented in https://bugs.openjdk.java.net/browse/JDK-8248862 ?
>
> @vamsi-parasa you can now integrate this and then I or someone else will sponsor it

Thank you @PaulSandoz  and @JimLaskey for reviewing the PR!

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

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

From aleonard at openjdk.java.net  Fri Dec  3 18:04:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 18:04:23 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <JmxOUHcJHVEn-h9tY_EvKkkYakgcBwlHSl-DWwaJUgw=.570e8abd-a281-4218-a67b-2cdae97ee55a@github.com>

On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge jdk:master
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

I've got a mac so can test that, a little tricking building, but i'll do that this evening

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

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

From duke at openjdk.java.net  Fri Dec  3 18:21:25 2021
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Fri, 3 Dec 2021 18:21:25 GMT
Subject: Integrated: 8275821: Optimize random number generators developed in
 JDK-8248862 using Math.unsignedMultiplyHigh()
In-Reply-To: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
References: <lFhGI7N8_QxkhIbcyZAMy2YRu0TIc69MMOcvwgVMDN4=.35419880-d670-46ac-985d-6bfccdd26a48@github.com>
Message-ID: <Kde653HQhSGC0tzijPnSDvrqMOQUBdb6GgXo9OuSYeU=.48c3782f-014c-4fb0-b562-36c9a3e46076@github.com>

On Tue, 2 Nov 2021 03:02:42 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

> This change optimizes random number generators using Math.unsignedMultiplyHigh()

This pull request has now been integrated.

Changeset: 38f525e9
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/38f525e96e767597d16698d4b243b681782acc9f
Stats:     103 lines in 4 files changed: 72 ins; 28 del; 3 mod

8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh()

Reviewed-by: psandoz, jlaskey

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

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

From serb at openjdk.java.net  Fri Dec  3 18:58:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Dec 2021 18:58:16 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation
In-Reply-To: <YUGA1y62YYO6pW3TmVVA6u2FVCGBeSI0fm68BKcFhxs=.4ff07036-f6eb-4c88-8b77-2c16da437308@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <OYXY3EfnLesP0j3ctkTaMLftQoKHmzeCYBxO3J8Z6Iw=.0414edba-4953-4d77-901b-de1cccb696d1@github.com>
 <YUGA1y62YYO6pW3TmVVA6u2FVCGBeSI0fm68BKcFhxs=.4ff07036-f6eb-4c88-8b77-2c16da437308@github.com>
Message-ID: <oHHnesKTjVCKyV3HfD2iTkfDbQhUWWgl3xNyO7g6A9M=.78d853a7-3b6d-4e61-bb4d-8ddc5fcb4c83@github.com>

On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This is the case at Adoptium for example, which uses the Mozilla trusted CA certs.

But they didn't think skipping this test was too strong a step? For example validation of the certs expiration is quite useful. I tried to update the test to take into account additional certs, but it caused a merge conflict each time the certs in OpenJDK are updated. Probably we can add a config file that can inject/override some info in the test(at least skip the checksum validation)? By default this config file will be empty and will not be modified in the OpenJDK, but the vendors will be able to modify it. @wangweij @rhalade what do you think?

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

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

From rhalade at openjdk.java.net  Fri Dec  3 19:09:23 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 3 Dec 2021 19:09:23 GMT
Subject: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to
 enable deterministic cacerts generation [v2]
In-Reply-To: <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
References: <G8-efNnV-rm9nZB7VvAtbkxjooqAtg39xD6_FB7PPos=.f6e00f71-38d7-41bf-91c6-d5d7e8e19012@github.com>
 <kZvtcRb0PLPUh--qpazvcQVm9IyDfp_zK4uBoXB67PI=.d4775b56-3db6-4c97-acd3-6b54b7dab83f@github.com>
Message-ID: <D4HFIhEOharaQH0yIUShMNuLSm5C1d1o6UFG1b6L8K4=.2138739c-5d93-4045-859e-58d86447931b@github.com>

On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Addition of a configure option --with-cacerts-src='user cacerts folder' to allow developers to specify their own cacerts PEM folder for generation of the cacerts store using the deterministic openjdk GenerateCacerts tool.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard 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:
> 
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8278080: Add --with-cacerts-src='user cacerts folder' to enable determinsitic cacerts generation
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The purpose of this test is to ensure integrity of the cacerts file along with basic validation of included roots. Having a config file with this information sounds like a good idea for now to be able to handle multiple files.

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

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

From bchristi at openjdk.java.net  Sat Dec  4 00:05:15 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Sat, 4 Dec 2021 00:05:15 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
Message-ID: <YeDaTjL7o4etbHkbqr6_p_MdE7oB83gaWNI1nhKF-Cw=.1268e4be-1d79-4dd7-8f6d-a5b55ba56a7f@github.com>

On Sat, 20 Nov 2021 10:08:41 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.java.net/browse/JDK-8003417?
> 
> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
> 
> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
> 
> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/util/WeakHashMap.java line 826:

> 824:                 throw new ConcurrentModificationException();
> 825: 
> 826:             WeakHashMap.this.remove(lastReturned.get());

Unlike `currentKey`, `HashIterator` does not necessarily maintain a strong reference to the referent of `lastReturned`. If the `lastReturned` WeakReference were cleared between `lastReturned` being set, and the `remove()` call, the null key could again be erroneously removed. It would be cool to add a test case for this (maybe using large objects as keys would tempt the GC to clear the weakrefs via `jdk.test.lib.util.ForceGC`).

Since we store the `NULL_KEY` sentinel value for the null key, I believe `Entry.get()` will only return null in the case that the weakref has been cleared.  So could we instead fix this with:


if (lastReturned.get() != null) {
    WeakHashMap.this.remove(lastReturned.get());
}


?
Or, if we're worried about the ref being cleared between the null check and remove(), maybe:

Object lastReturnedKey = lastReturned.get();
if (lastReturnedKey != null) {
    WeakHashMap.this.remove(lastReturned.get());
}

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

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

From naoto at openjdk.java.net  Sat Dec  4 00:08:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 00:08:36 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending on
 previous code
Message-ID: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>

Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

Commit messages:
 - 8275721: Name of UTC timezone in a locale changes depending on previous code

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

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

From smarks at openjdk.java.net  Sat Dec  4 00:40:16 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Sat, 4 Dec 2021 00:40:16 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <YeDaTjL7o4etbHkbqr6_p_MdE7oB83gaWNI1nhKF-Cw=.1268e4be-1d79-4dd7-8f6d-a5b55ba56a7f@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
 <YeDaTjL7o4etbHkbqr6_p_MdE7oB83gaWNI1nhKF-Cw=.1268e4be-1d79-4dd7-8f6d-a5b55ba56a7f@github.com>
Message-ID: <V9BhpTYaSkFs9OCtai7CyF4hp6WPPsOrL4HRJU4Oou8=.bf73f963-16ef-4b43-851a-1d5882f1462b@github.com>

On Sat, 4 Dec 2021 00:02:04 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8003417?
>> 
>> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
>> 
>> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
>> 
>> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
>> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.
>
> src/java.base/share/classes/java/util/WeakHashMap.java line 826:
> 
>> 824:                 throw new ConcurrentModificationException();
>> 825: 
>> 826:             WeakHashMap.this.remove(lastReturned.get());
> 
> Unlike `currentKey`, `HashIterator` does not necessarily maintain a strong reference to the referent of `lastReturned`. If the `lastReturned` WeakReference were cleared between `lastReturned` being set, and the `remove()` call, the null key could again be erroneously removed. It would be cool to add a test case for this (maybe using large objects as keys would tempt the GC to clear the weakrefs via `jdk.test.lib.util.ForceGC`).
> 
> Since we store the `NULL_KEY` sentinel value for the null key, I believe `Entry.get()` will only return null in the case that the weakref has been cleared.  So could we instead fix this with:
> 
> 
> if (lastReturned.get() != null) {
>     WeakHashMap.this.remove(lastReturned.get());
> }
> 
> 
> ?
> Or, if we're worried about the ref being cleared between the null check and remove(), maybe:
> 
> Object lastReturnedKey = lastReturned.get();
> if (lastReturnedKey != null) {
>     WeakHashMap.this.remove(lastReturned.get());
> }

Yes, this is my concern too; lastReturned is a weak ref, and it is possible for it to have been cleared at this point, so get() can return null. I will post a more complete explanation.

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

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

From smarks at openjdk.java.net  Sat Dec  4 01:27:10 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Sat, 4 Dec 2021 01:27:10 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
Message-ID: <V5AJwDUxCpW6udFROlrUobvf24zIvis2X3aIO0XbWoc=.b6c6912e-1c69-48ac-ac27-50efae6cbca5@github.com>

On Sat, 20 Nov 2021 10:08:41 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.java.net/browse/JDK-8003417?
> 
> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
> 
> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
> 
> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.

I've put extensive comments and explanation into the bug report. I put them there instead of here because they're more closely related to the test case in that bug report, and they also include general statements about WeakHashMap iteration, not specific to the change proposed here.

TL;DR I don't think that changing remove to `remove(lastReturned.get())` is the correct fix. It requires revisting the invariants maintained by `HashIterator`. It might be as simple as removing the clearing of `currentKey` from `hasNext()`, as mentioned in the bug report, but this requires more thought.

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

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

From naoto at openjdk.java.net  Sat Dec  4 05:46:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 05:46:57 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v2]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <XemM8bzfuYIOW0ATMiJngNKGoQ9lE_ocOxrcbN349wY=.641798df-c0e9-448f-844e-7fb41b58ded6@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Fixed COMPAT substitution for FULL names and modified the priority.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/10957100..3ec08e4d

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

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

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

From plevart at openjdk.java.net  Sat Dec  4 08:53:13 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 4 Dec 2021 08:53:13 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v6]
In-Reply-To: <2FChUUIV-in_3gH0WBc5KrPAyuRi8aPgRvSL8aDpBck=.87eb44e5-9f0a-4ecb-81f9-550dd96154b5@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <2FChUUIV-in_3gH0WBc5KrPAyuRi8aPgRvSL8aDpBck=.87eb44e5-9f0a-4ecb-81f9-550dd96154b5@github.com>
Message-ID: <PdEtM50rRPaVUNBf-XfoWkRhZgvfkDmTA2B-dt2jUgI=.bf8381fe-9fe1-41a3-b48a-a9e9d85a1a44@github.com>

On Thu, 2 Dec 2021 16:22:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import

Changes requested by plevart (Reviewer).

src/java.base/share/classes/java/io/ClassCache.java line 63:

> 61:             protected SoftReference<T> computeValue(Class<?> type) {
> 62:                 return new SoftReference<>(ClassCache.this.computeValue(type), queue);
> 63:             }

How does this work? You create a bare SoftReference here and register it with queue....

...then down in processQueue() you pick it up and cast to CacheRef... Doesn't this throw ClassCastException ?

src/java.base/share/classes/java/io/ClassCache.java line 85:

> 83:             CacheRef<? extends T> cacheRef = (CacheRef<? extends T>)ref;
> 84:             map.remove(cacheRef.getType());
> 85:         }

See the cast to CacheRef here?

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

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

From plevart at openjdk.java.net  Sat Dec  4 08:53:13 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 4 Dec 2021 08:53:13 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v4]
In-Reply-To: <pPyS_IrUtaqFmxpTStvkcpBXWCjPPV6RYULvSIYhKkY=.77d251b7-9b20-4b4b-8054-a4a8cec3d57b@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <GxF0lIhMoXZBbIw1MrqD8pmkNsR5V7RgZq5RsG2hPF8=.be5d7458-9fe7-4fc1-8980-5ec717b5ccc8@github.com>
 <oBtYO8OJwEpf_59DHI7fE2QXEb2BTtOr28IF4DJgLoU=.935ecf28-7c66-4156-9b41-91fa7395822f@github.com>
 <pPyS_IrUtaqFmxpTStvkcpBXWCjPPV6RYULvSIYhKkY=.77d251b7-9b20-4b4b-8054-a4a8cec3d57b@github.com>
Message-ID: <qQo575XNjpWsJCu5Kqrt8__9BUFgr--mqUUTw_-P1qI=.34a77176-02e8-4e46-85e7-438ab9def246@github.com>

On Thu, 2 Dec 2021 14:24:06 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:
>> 
>>> 2131:             if (oldReflector != null) {
>>> 2132:                 reflector = oldReflector;
>>> 2133:             }
>> 
>> Map.computeIfAbsent(key, () -> new FieldReflector(matchFields, localDesc));
>> might be more compact.
>
> That would be nicer, indeed. Problem is that matchFields throws an InvalidClassException, and that would have to get passed through the lambda.
> Also, that problem is pre-existing and not related to the change.

Yes, I did computeIfAbsent() originally just to find out handling check exception/wrapping/unwrapping would make the code much more complex.

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

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

From duke at openjdk.java.net  Sat Dec  4 18:47:18 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 4 Dec 2021 18:47:18 GMT
Subject: Withdrawn: 8271598: CDS classlist file should support uber JARs
In-Reply-To: <opq7VcOgSqCUpO1JKo5u9LpYRP5ihFFI8hWkT24lTqo=.946ce71f-98aa-4120-a210-f9f127f81e0f@github.com>
References: <opq7VcOgSqCUpO1JKo5u9LpYRP5ihFFI8hWkT24lTqo=.946ce71f-98aa-4120-a210-f9f127f81e0f@github.com>
Message-ID: <kYdparqwuanoUKLGJ3sXCZPm6K3o1IWWDL15AKflBiA=.e000661a-6787-4876-b836-7579527f49e6@github.com>

On Sat, 9 Oct 2021 00:15:43 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Currently, for archive classes for custom loaders, CDS supports the following source locations in the classlist:

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.java.net  Sat Dec  4 22:14:20 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 22:14:20 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap
In-Reply-To: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
Message-ID: <uTiDTQuzI_A1bE9D6m3gBwDEObxTDJnTOBXIiktfzbw=.7c32ef63-5936-4d0f-a9b7-da67aa0912eb@github.com>

On Wed, 24 Nov 2021 05:16:40 GMT, liach <duke at openjdk.java.net> wrote:

> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.

Yes, behavioral changes in a widely-used class would merit CSR review.

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

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

From naoto at openjdk.java.net  Sat Dec  4 22:34:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 22:34:50 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v3]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Use isFixedOffset() instead of useDaylightTime()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/3ec08e4d..cf217f56

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

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

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

From duke at openjdk.java.net  Sun Dec  5 00:31:12 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 5 Dec 2021 00:31:12 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap
In-Reply-To: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
Message-ID: <4QPnxA6H9TDEKeXStJ3ndmNl3zwYc02bGhxRF0zBfxY=.75daaf20-4d5e-419d-ac79-f51a5cfbe553@github.com>

On Wed, 24 Nov 2021 05:16:40 GMT, liach <duke at openjdk.java.net> wrote:

> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.

Since I don't have an account on the JBS, I will post the CSR markdown draft here and hope someone can create one for me.

CSR of: JDK-8277520

Component: core-libs
Subcomponent: java.util:collections
Compatibility Kind: behavioral
Compatibility risk: low
Compatibility Risk Description: Previously successful calls to `IdentityHashMap::computeIfAbsent` etc. may now fail.
Interface Kind: Java API
Scope: SE
Description:

## Summary
Explicitly state that the `computeIfAbsent`, `computeIfPresent`, `compute`, and `merge` methods in `IdentityHashMap` will throw `ConcurrentModificationException` when the (re)mapping function modifies the map.

## Problem
Previously, with the default implementation provided by the `Map` interface, the 4 methods in `IdentityHashMap` will never throw `ConcurrentModificationException`, but the efficient override implementations requires the (re)mapping function to not modify this map when (re)mapping function's modification to the map is detected.

## Solution
Adds documentation to specify the new behavior of the 4 methods in `IdentityHashMap`. Such behavior is compatible with that specified in the `Map` superinterface.

## Specification
We propose to add these documentation for the 4 concurrency-hostile methods as follows: (implementations ignored)

    /**
     * {@inheritDoc}
     *
     * <p>This method will, on a best-effort basis, throw a
     * {@link ConcurrentModificationException} if it is detected that the
     * mapping function modifies this map during computation.
     *
     * @throws ConcurrentModificationException if it is detected that the
     * mapping function modified this map
     */
    @Override
    public V computeIfAbsent(K key, Function<? super K, ? extends V> mappingFunction) {
    }

    /**
     * {@inheritDoc}
     *
     * <p>This method will, on a best-effort basis, throw a
     * {@link ConcurrentModificationException} if it is detected that the
     * remapping function modifies this map during computation.
     *
     * @throws ConcurrentModificationException if it is detected that the
     * remapping function modified this map
     */
    @Override
    public V computeIfPresent(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    }

    /**
     * {@inheritDoc}
     *
     * <p>This method will, on a best-effort basis, throw a
     * {@link ConcurrentModificationException} if it is detected that the
     * remapping function modifies this map during computation.
     *
     * @throws ConcurrentModificationException if it is detected that the
     * remapping function modified this map
     */
    @Override
    public V compute(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    }

    /**
     * {@inheritDoc}
     *
     * <p>This method will, on a best-effort basis, throw a
     * {@link ConcurrentModificationException} if it is detected that the
     * remapping function modifies this map during computation.
     *
     * @throws ConcurrentModificationException if it is detected that the
     * remapping function modified this map
     */
    @Override
    public V merge(K key, V value, BiFunction<? super V, ? super V, ? extends V> remappingFunction) {
    }

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

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

From alanb at openjdk.java.net  Sun Dec  5 18:40:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 5 Dec 2021 18:40:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <dpsfeZ0Nef4LRbl-LW8GH_1wKTuJJFDUfwjJnPWqFZk=.1887e108-f5a7-4a33-b5b7-888eb07b6331@github.com>

On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge jdk:master
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

I looked at the latest patch (06863697) and I think you've got it to a good place (and thank you to John Neffenger for all the help).

One comment on the usage message is that it might be a bit clearer to say "for the timestamps of entries" rather than "for entry timestamps". I'm also wondering if it would be useful to include an example of an ISO 8601 in the usage message.

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

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

From darcy at openjdk.java.net  Sun Dec  5 23:53:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 5 Dec 2021 23:53:39 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
Message-ID: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>

Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.

(Enabling the reference checks is left for future work.)

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

Commit messages:
 - JDK-8278273: Remove unnecessary exclusion of doclint accessibility checks

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

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

From lancea at openjdk.java.net  Mon Dec  6 01:53:19 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Dec 2021 01:53:19 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>

On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge jdk:master
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

Overall the latest update looks good

a few minor comments below 

the CSR needs some updates and I will look to provide comments tomorrow

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 86:

> 84:         unexpected versioned entry {0} for release {1}
> 85: error.date.notvalid=\
> 86:         date {0} is not a valid ISO 8601 date and time

Please rephrase to use wording similar to what is in the Javadoc date-time with offset and zone

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 88:

> 86:         date {0} is not a valid ISO 8601 date and time
> 87: error.date.out.of.range=\
> 88:         date {0} is not within the valid range

Please  include the range in the message

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 298:

> 296: \  -0, --no-compress          Store only; use no ZIP compression
> 297: main.help.opt.create.update.index.date=\
> 298: \      --date=TIMESTAMP       The timestamp in ISO 8601 format to use\n\

Same comment as above perhaps show the syntax

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:

> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
> 111: err.date.out.of.range=--date {0} is out of the valid range

Same comments as above

test/jdk/tools/jar/JarEntryTime.java line 191:

> 189:                                 "2038-11-26T06:06:06+00:00",
> 190:                                 "2098-02-18T00:00:00-08:00",
> 191:                                 "2099-12-31T23:59:59+00:00"};

I believe the parsing format you are using supports formats such as '2011-12-03T10:15:30', '2011-12-03T10:15:30+01:00' and'2011-12-03T10:15:30+01:00[Europe/Paris]'.

please add a few extra values to the above

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

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

From jpai at openjdk.java.net  Mon Dec  6 04:54:16 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Dec 2021 04:54:16 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
Message-ID: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>

On Wed, 1 Dec 2021 18:19:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
> incompletely specified. The behavior for invalid values of the properties is different and
> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
> uninitialized. 
> 
> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
> either by system properties supplied on the command line or security properties are logged.
> The `Config` class marks either or both the filter and filter factory values as unusable
> and remembers the exception message.
> 
> Subsequent calls to the methods that get or set the filter or filter factory or create 
> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
> The nature of the invalid property is reported as an `IllegalStateException` on first use.
> 
> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization

src/java.base/share/classes/java/io/ObjectInputFilter.java line 526:

> 524:      * {@code jdk.serialFilter} is defined then it is used to configure the filter.
> 525:      * The filter is created as if {@link #createFilter(String) createFilter} is called,
> 526:      * if the filter string is invalid the initialization fails and subsequent attempts to

Hello Roger,
> if the filter string is invalid the initialization fails

Should this instead be "if the filter string is invalid the initialization of {@code Config} class fails ..."

src/java.base/share/classes/java/io/ObjectInputFilter.java line 527:

> 525:      * The filter is created as if {@link #createFilter(String) createFilter} is called,
> 526:      * if the filter string is invalid the initialization fails and subsequent attempts to
> 527:      * {@linkplain Config#getSerialFilter() get the filter}, {@link Config#setSerialFilter set a filter},

> {@link Config#setSerialFilter set a filter}

Should this instead be "{@link Config#setSerialFilter(ObjectInputFilter)  set a filter}" i.e. include the param as part of the `@link`, like in other places?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 532:

> 530:      * invalid serial filter.
> 531:      * If the system property {@code jdk.serialFilter} or the {@link java.security.Security}
> 532:      * property is not set the filter can be set with

> or the {@link java.security.Security} property is not set the filter can be set ...

Is it intentional that the name of security property is left out here? Perhaps this should be:
 `or the {@link java.security.Security} property {@code jdk.serialFilter} is not set the filter ....`

or even:

`or the {@link java.security.Security} property of the same name is not set the filter....`

src/java.base/share/classes/java/io/ObjectInputFilter.java line 751:

> 749:                 if (serialFilter != null) {
> 750:                     throw new IllegalStateException("Serial filter can only be set once");
> 751:                 } else if (invalidFilterMessage != null) {

The `invalidFilterMessage` is a `static` `final` `String` which gets initialized during the static initialization of the class and as such doesn't get changed after that. Do you think this lock on `serialFilterLock` is necessary for this check or it can be moved outside this `synchronized` block?

src/java.base/share/classes/java/io/ObjectInputFilter.java line 859:

> 857:         /*
> 858:          * Return message for an invalid filter factory configuration saved from the static init.
> 859:          * It can be called before the static initializer is complete and has set the message/null.

More of a curiosity than a review comment - Is that because the `Config.getSerialFilterFactory()/setSerialFilterFactory(...)` could be called from the constructor of the user configured factory class, which gets invoked when static initialization is in progress for the `Config` class?

test/jdk/java/io/Serializable/serialFilter/InvalidGlobalFilterTest.java line 38:

> 36: /*
> 37:  * @test
> 38:  * @bug 8269336

Would this need an update to include the new bug id of this PR?

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

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

From jpai at openjdk.java.net  Mon Dec  6 05:02:13 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Dec 2021 05:02:13 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
Message-ID: <IL0Fw6zyJ8r8n_UUGriv-5DrnW2yzM77A0PlGsOt7kk=.b8c0bc52-cb8b-43e9-a8e4-3c382b393f27@github.com>

On Mon, 6 Dec 2021 04:25:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 526:
> 
>> 524:      * {@code jdk.serialFilter} is defined then it is used to configure the filter.
>> 525:      * The filter is created as if {@link #createFilter(String) createFilter} is called,
>> 526:      * if the filter string is invalid the initialization fails and subsequent attempts to
> 
> Hello Roger,
>> if the filter string is invalid the initialization fails
> 
> Should this instead be "if the filter string is invalid the initialization of {@code Config} class fails ..."

Please ignore this above comment. Clearly, the initialization of `Config` class doesn't fail, but the initialization of the JVM wide serial filter fails. I still had the older semantics of `Config`  class in mind when I submitted that above comment.

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

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

From iris at openjdk.java.net  Mon Dec  6 06:19:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 6 Dec 2021 06:19:14 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <53hKkuTiEAI3u8ktsivvFxPwR0ZS-B8rgpLDmApjyIs=.00cd21e6-1731-4507-955a-a125b416aa13@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by iris (Reviewer).

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

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

From alanb at openjdk.java.net  Mon Dec  6 07:08:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 07:08:12 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <9SgzaJHojLAPSAitHsNAMOfU1ghzZWmKXT6OJEUsteQ=.c09933d0-7ce6-4bcd-8a58-d3a87d44ca88@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.java.net  Mon Dec  6 07:10:21 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 6 Dec 2021 07:10:21 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
Message-ID: <AzPA2qM90ShR-IUuw_JvxC59xjHVO7VoxC2PEufDp_Q=.57e94bab-7095-4564-a10e-e34bfc191ac1@github.com>

On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Draft: Eliminated duplicate code using lambda expressions
>  - Draft: Use blocking mode also for target channel

Please keep this PR open. More commits will follow on the next weeks.

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

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

From lbourges at openjdk.java.net  Mon Dec  6 08:45:22 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 6 Dec 2021 08:45:22 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <AzPA2qM90ShR-IUuw_JvxC59xjHVO7VoxC2PEufDp_Q=.57e94bab-7095-4564-a10e-e34bfc191ac1@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
 <AzPA2qM90ShR-IUuw_JvxC59xjHVO7VoxC2PEufDp_Q=.57e94bab-7095-4564-a10e-e34bfc191ac1@github.com>
Message-ID: <KY5-2HexWZDuBr_YP0dNKYRKRa6fkCWzytzD4c4wozY=.38c2d1e1-fe5e-47b1-807f-5b66c32f9412@github.com>

On Mon, 6 Dec 2021 07:07:03 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Draft: Eliminated duplicate code using lambda expressions
>>  - Draft: Use blocking mode also for target channel
>
> Please keep this PR open. More commits will follow on the next weeks.

Looks promising, keep moving, @mkarg !

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

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

From shade at openjdk.java.net  Mon Dec  6 09:14:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Dec 2021 09:14:12 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <BLg2HhxGfolAXw75gUrLSwuJLSp2aam9hXOenu45Sp4=.5a120904-2308-45ad-8516-014135fa2f84@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
 <BLg2HhxGfolAXw75gUrLSwuJLSp2aam9hXOenu45Sp4=.5a120904-2308-45ad-8516-014135fa2f84@github.com>
Message-ID: <OwhCRu_BdkdTJT0ZIJlh8ATFL5dHBJB6SGoNPj96qqY=.ea0b9f98-c340-4467-81a1-cb7bf7dfb4c4@github.com>

On Fri, 3 Dec 2021 07:34:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to the change, I think it is just a re-balancing of tiers for CI systems.

Yes, quite. @dholmes-ora, are you happy with Alan's assessment?

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

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

From alanb at openjdk.java.net  Mon Dec  6 10:39:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 10:39:14 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <_utni5gaQ9TX5e_wf8Ba9xNsaFhEbznz9H9s6Uu_D8E=.7db944b5-fa23-4579-a946-341d3f1f8476@github.com>

On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

Yes, I think we would be good to have a test. If it's too hard using the tools then a test that uses the image reader API directly would be okay. @naotoj may have some suggestions too.

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

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

From ihse at openjdk.java.net  Mon Dec  6 11:52:13 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Dec 2021 11:52:13 GMT
Subject: RFR: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <M43NwMLrzLg5w5zG-jkuYauBK7tju7uJceREYeZsYBE=.b62af4b6-91e6-4c87-8aa8-8217400fb12c@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

??

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

Marked as reviewed by ihse (Reviewer).

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

From dholmes at openjdk.java.net  Mon Dec  6 11:57:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Dec 2021 11:57:13 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <OwhCRu_BdkdTJT0ZIJlh8ATFL5dHBJB6SGoNPj96qqY=.ea0b9f98-c340-4467-81a1-cb7bf7dfb4c4@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
 <4860e31d-225d-8b6c-c151-356246c81203@oracle.com>
 <BLg2HhxGfolAXw75gUrLSwuJLSp2aam9hXOenu45Sp4=.5a120904-2308-45ad-8516-014135fa2f84@github.com>
 <OwhCRu_BdkdTJT0ZIJlh8ATFL5dHBJB6SGoNPj96qqY=.ea0b9f98-c340-4467-81a1-cb7bf7dfb4c4@github.com>
Message-ID: <SE0Vo1nqpsySKDV-YTMN783gdB_yPKm4Cxrl_FUASwk=.a938a595-87b9-486c-bcf6-f3d411c5147c@github.com>

On Mon, 6 Dec 2021 09:11:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I've solicited feedback from core-libs folk as this affects them the most. At present we, Oracle, run the jdk_svc tests as part of hotspot testing, but this change will suddenly cause jdk testing to include them. That is probably not an issue for testing within the CI framework but developers running jdk_tier3 locally, often, may have an unpleasant surprise at running over a thousand additional tests that probably have zero relevance to what they are trying to test. Local machines may take considerably longer than the 8+ minutes that you listed.
>> 
>> I don't expect there are many people that run jdk_tier3 locally. It's a mixed bag of tests for the Panama Vector API, RMI and JFR. Adding jdk_svc to this list just adds to the mix. The only synergy is that the RMI tests will be in the same tier as the JMX tests that use the RMI connectors. No objection to the change, I think it is just a re-balancing of tiers for CI systems.
>
>> No objection to the change, I think it is just a re-balancing of tiers for CI systems.
> 
> Yes, quite. @dholmes-ora, are you happy with Alan's assessment?

@shipilev yes I'm fine with Alan's assessment. Thanks

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

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

From alanb at openjdk.java.net  Mon Dec  6 12:02:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 12:02:10 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <DSiqJ7IJ-pPAWdkKLoxrZD4jTtNOmfLgBpw14g85UCE=.61f55476-213f-4b2b-9e2f-bb244569d3e7@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

Marked as reviewed by alanb (Reviewer).

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

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

From shade at openjdk.java.net  Mon Dec  6 12:02:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Dec 2021 12:02:11 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <Om3mzgbK4SgRJw4pG9I0k3x50VVnld7X9Dijqfsv1Y0=.d9dd7ce9-09b9-4c51-9d77-a8a62149a339@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

Ok, good. I need some formal (R)eviews to get this going :)

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

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

From aleonard at openjdk.java.net  Mon Dec  6 12:08:46 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:46 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v18]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <HUdSlcxc7Db4bvyCPazeMOVYuwS8G4xsbPm0rVVF-sk=.534d96c6-3b6e-40ec-a8f9-ee574eb6f4b9@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/06863697..2a2d781b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=16-17

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

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

From aleonard at openjdk.java.net  Mon Dec  6 12:08:50 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:50 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <aVMTZPoS6tN2IPPZTIAh_f8gIlMKat_I0wYZKsiiQoM=.7fc26ccf-4f0d-421c-a261-8f6ce20f4fe7@github.com>

On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge jdk:master
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

> I looked at the latest patch ([0686369](https://github.com/openjdk/jdk/commit/068636971e833cb582790667171a67e40c823bb1)) and I think you've got it to a good place (and thank you to John Neffenger for all the help).
> 
> One comment on the usage message is that it might be a bit clearer to say "for the timestamps of entries" rather than "for entry timestamps". I'm also wondering if it would be useful to include an example of an ISO 8601 in the usage message.

@AlanBateman thanks. I've reworded, and added an example

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

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

From aleonard at openjdk.java.net  Mon Dec  6 12:08:57 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:57 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
 <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>
Message-ID: <JgJbkkolGx0rZ6P4rFEt5UHLDBduiTilxHRpUjNB1ew=.232caeca-2185-4f44-a747-94be302f411e@github.com>

On Mon, 6 Dec 2021 00:15:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge jdk:master
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>>    
>>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 86:
> 
>> 84:         unexpected versioned entry {0} for release {1}
>> 85: error.date.notvalid=\
>> 86:         date {0} is not a valid ISO 8601 date and time
> 
> Please rephrase to use wording similar to what is in the Javadoc date-time with offset and zone

reworded

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 88:
> 
>> 86:         date {0} is not a valid ISO 8601 date and time
>> 87: error.date.out.of.range=\
>> 88:         date {0} is not within the valid range
> 
> Please  include the range in the message

added range

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 298:
> 
>> 296: \  -0, --no-compress          Store only; use no ZIP compression
>> 297: main.help.opt.create.update.index.date=\
>> 298: \      --date=TIMESTAMP       The timestamp in ISO 8601 format to use\n\
> 
> Same comment as above perhaps show the syntax

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:
> 
>> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
>> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
>> 111: err.date.out.of.range=--date {0} is out of the valid range
> 
> Same comments as above

done

> test/jdk/tools/jar/JarEntryTime.java line 191:
> 
>> 189:                                 "2038-11-26T06:06:06+00:00",
>> 190:                                 "2098-02-18T00:00:00-08:00",
>> 191:                                 "2099-12-31T23:59:59+00:00"};
> 
> I believe the parsing format you are using supports formats such as '2011-12-03T10:15:30', '2011-12-03T10:15:30+01:00' and'2011-12-03T10:15:30+01:00[Europe/Paris]'.
> 
> please add a few extra values to the above

added more tests
note '2011-12-03T10:15:30' is not valid as it needs a offset or Z, so it represents a reproducible "instant"

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

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

From rkennke at openjdk.java.net  Mon Dec  6 12:12:44 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 6 Dec 2021 12:12:44 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v7]
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

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

  Fix cast; add testcase to cover memory pressure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6375/files
  - new: https://git.openjdk.java.net/jdk/pull/6375/files/57428e0f..e6e34cea

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

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

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

From rkennke at openjdk.java.net  Mon Dec  6 12:12:48 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 6 Dec 2021 12:12:48 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v6]
In-Reply-To: <PdEtM50rRPaVUNBf-XfoWkRhZgvfkDmTA2B-dt2jUgI=.bf8381fe-9fe1-41a3-b48a-a9e9d85a1a44@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <2FChUUIV-in_3gH0WBc5KrPAyuRi8aPgRvSL8aDpBck=.87eb44e5-9f0a-4ecb-81f9-550dd96154b5@github.com>
 <PdEtM50rRPaVUNBf-XfoWkRhZgvfkDmTA2B-dt2jUgI=.bf8381fe-9fe1-41a3-b48a-a9e9d85a1a44@github.com>
Message-ID: <kXBk-pIc-2YmpsylBymJcbbH3ppRzXPP3fmBzT9fgps=.4c98115b-63f4-478d-92b5-666477d645f9@github.com>

On Sat, 4 Dec 2021 08:47:03 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary import
>
> src/java.base/share/classes/java/io/ClassCache.java line 63:
> 
>> 61:             protected SoftReference<T> computeValue(Class<?> type) {
>> 62:                 return new SoftReference<>(ClassCache.this.computeValue(type), queue);
>> 63:             }
> 
> How does this work? You create a bare SoftReference here and register it with queue....
> 
> ...then down in processQueue() you pick it up and cast to CacheRef... Doesn't this throw ClassCastException ?

> 

Indeed, good catch! Apparently no test (existing or new) covers the memory-pressure scenario. My new test only covers the scenario when the Class disappears altogether. I added a test to verify behaviour under memory pressure, and pushed a fix.

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

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

From aleonard at openjdk.java.net  Mon Dec  6 13:57:48 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 13:57:48 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/2a2d781b..c5104305

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=17-18

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

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

From rriggs at openjdk.java.net  Mon Dec  6 15:29:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 15:29:18 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v7]
In-Reply-To: <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>
Message-ID: <T1RDIneMpxZ3Kyq0amas5sg_u5xghi6Qfmz_bT6svnY=.4bd80606-3c0f-42fe-9e9c-7b2ce42a2a5b@github.com>

On Mon, 6 Dec 2021 12:12:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cast; add testcase to cover memory pressure

Thanks for the updates.  LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.java.net  Mon Dec  6 16:01:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:01:43 GMT
Subject: RFR: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases. [v2]
In-Reply-To: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
References: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
Message-ID: <3oSKuAouBjDZ4sRQ0u_v3lroJ_jqdy2B9bhfs4W4t0k=.d58ef637-bd84-4826-9008-aee04449aaa4@github.com>

> The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.
> 
> In both constructors, add the following to the paragraph the describes invoking the factory:
> 
>      * When the filter factory {@code apply} method is invoked it may throw a runtime exception
>      * preventing the {@code ObjectInputStream} from being constructed.

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

  Clarified that a runtime exception may be thrown by the filter factory returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
  not by the `getSerialFilterFactory` method.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6704/files
  - new: https://git.openjdk.java.net/jdk/pull/6704/files/ecb9aa90..da95d900

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

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

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

From rriggs at openjdk.java.net  Mon Dec  6 16:08:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:08:15 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
Message-ID: <OtAnpVjo58Wm7fQ2EaNLl87zhHj9EFNxrGWuzMGBRfA=.acc30b63-d5ca-410a-9eed-13cff3ca3a23@github.com>

On Mon, 6 Dec 2021 04:27:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 527:
> 
>> 525:      * The filter is created as if {@link #createFilter(String) createFilter} is called,
>> 526:      * if the filter string is invalid the initialization fails and subsequent attempts to
>> 527:      * {@linkplain Config#getSerialFilter() get the filter}, {@link Config#setSerialFilter set a filter},
> 
>> {@link Config#setSerialFilter set a filter}
> 
> Should this instead be "{@link Config#setSerialFilter(ObjectInputFilter)  set a filter}" i.e. include the param as part of the `@link`, like in other places?

I intended to use @linkplain, using prose with a link is more readable then a sentence broken up with full method references.

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

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

From rriggs at openjdk.java.net  Mon Dec  6 16:11:16 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:11:16 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
Message-ID: <QZ87uCaF4nmD-1SP4AdbUBpdPYjahAk6xzbB-QHWO34=.a9952829-7dc6-4557-86a4-e6c4d2066d04@github.com>

On Mon, 6 Dec 2021 04:30:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 532:
> 
>> 530:      * invalid serial filter.
>> 531:      * If the system property {@code jdk.serialFilter} or the {@link java.security.Security}
>> 532:      * property is not set the filter can be set with
> 
>> or the {@link java.security.Security} property is not set the filter can be set ...
> 
> Is it intentional that the name of security property is left out here? Perhaps this should be:
>  `or the {@link java.security.Security} property {@code jdk.serialFilter} is not set the filter ....`
> 
> or even:
> 
> `or the {@link java.security.Security} property of the same name is not set the filter....`

Yes, for consistency, the first suggestion.

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

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

From rriggs at openjdk.java.net  Mon Dec  6 16:21:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:21:10 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
Message-ID: <8e0qbcFPb_4lX7blR0LRYZFjlsGMqHNeDpQlIw4JBXM=.e52f4174-2e1c-4321-8319-1e3f4249fafe@github.com>

On Mon, 6 Dec 2021 04:40:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 751:
> 
>> 749:                 if (serialFilter != null) {
>> 750:                     throw new IllegalStateException("Serial filter can only be set once");
>> 751:                 } else if (invalidFilterMessage != null) {
> 
> The `invalidFilterMessage` is a `static` `final` `String` which gets initialized during the static initialization of the class and as such doesn't get changed after that. Do you think this lock on `serialFilterLock` is necessary for this check or it can be moved outside this `synchronized` block?

Checking `serialFilter` for non-null required the synchronization.
The check of `invalidFilterMessage` can be pulled out of the synchronization since in expected usage the method is only called once so the performance isn't significant.

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

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

From rriggs at openjdk.java.net  Mon Dec  6 16:24:16 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:24:16 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified
In-Reply-To: <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <YSbfLBHMPoxzoNPXMPNPx7V7-e8BE1FWt-1pBUQ9HMI=.72b4fe8a-793b-4c62-a1e7-6314f45295e9@github.com>
Message-ID: <lGcISPvdYXTVjz4avDP-rXq0cnojVQhuNZc6EnWJk7E=.b45aa07e-9ce2-4d9d-bd43-04b9fb47816d@github.com>

On Mon, 6 Dec 2021 04:44:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 859:
> 
>> 857:         /*
>> 858:          * Return message for an invalid filter factory configuration saved from the static init.
>> 859:          * It can be called before the static initializer is complete and has set the message/null.
> 
> More of a curiosity than a review comment - Is that because the `Config.getSerialFilterFactory()/setSerialFilterFactory(...)` could be called from the constructor of the user configured factory class, which gets invoked when static initialization is in progress for the `Config` class?

Yes, it can be called before the `Config` class has completed initialization and `invalidFactoryMessage` may be seen as null.

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

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

From alanb at openjdk.java.net  Mon Dec  6 16:30:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 16:30:38 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return offsets
Message-ID: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>

Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.

The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.

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

Commit messages:
 - Initial commit

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

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

From alanb at openjdk.java.net  Mon Dec  6 16:39:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 16:39:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
Message-ID: <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>

On Mon, 6 Dec 2021 13:57:48 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:

> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
> 299: \                             optional time-zone format, to use for the timestamps of\n\
> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"

The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".

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

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

From psandoz at openjdk.java.net  Mon Dec  6 16:46:15 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Dec 2021 16:46:15 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets
In-Reply-To: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
Message-ID: <FAZBM1nDrf4tcKNTjx7EipgrNA7EU-JOWlHneetruXM=.0dd7c1b4-1b07-4f5f-8413-1ff391d1f651@github.com>

On Fri, 3 Dec 2021 13:05:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
> 
> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.

Slowly chipping away... but we are getting really close to being able to deprecate all the unsafe accessor methods.

Did you also consider the method `staticFieldBase` and the field `INVALID_FIELD_OFFSET`? I think those could also be included since the aim is to discourage unsafe access to fields of objects.

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

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

From rriggs at openjdk.java.net  Mon Dec  6 16:59:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 16:59:41 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified [v2]
In-Reply-To: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
Message-ID: <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>

> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
> incompletely specified. The behavior for invalid values of the properties is different and
> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
> uninitialized. 
> 
> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
> either by system properties supplied on the command line or security properties are logged.
> The `Config` class marks either or both the filter and filter factory values as unusable
> and remembers the exception message.
> 
> Subsequent calls to the methods that get or set the filter or filter factory or create 
> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
> The nature of the invalid property is reported as an `IllegalStateException` on first use.
> 
> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization

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

  Address review comments to consistently identify security property names
  and use the correct bug number in the test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6645/files
  - new: https://git.openjdk.java.net/jdk/pull/6645/files/4dec7f48..52ab7b5b

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

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

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

From darcy at openjdk.java.net  Mon Dec  6 17:00:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 17:00:19 GMT
Subject: Integrated: JDK-8278273: Remove unnecessary exclusion of doclint
 accessibility checks
In-Reply-To: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
References: <OKNZ1gcgCPFduWd3NdsgKj_vmwFW0LA9RVYRkHCVphE=.697f62e0-7b86-4d70-8055-ba7176494ec7@github.com>
Message-ID: <VWMQuiOsa2iCff9JBfJVQ1whou8KgJBEI_4gti100rI=.7c9de73f-e287-47cf-8e1b-1620f79b2a1c@github.com>

On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory builds indicate it is not currently necessary to exclude the doclint accessibility checks; this patch enables them.
> 
> (Enabling the reference checks is left for future work.)

This pull request has now been integrated.

Changeset: 5045eb53
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5045eb538b3afc6cf646642f1109473597b3004a
Stats:     14 lines in 7 files changed: 0 ins; 0 del; 14 mod

8278273: Remove unnecessary exclusion of doclint accessibility checks

Reviewed-by: iris, alanb, ihse

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

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

From naoto at openjdk.java.net  Mon Dec  6 17:05:14 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Dec 2021 17:05:14 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <SVSW8h-fqeH_NPpnTDh-fYY9uc7gaJSEPyKYG7hPd7Q=.e9e82f3e-6c4f-4549-8d91-9f37536d294e@github.com>

On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

Regression tests for `ResourceBundle` class have tests that dynamically generate modules. Although I have not used non-ASCII module names, tests under `test/jdk/java/util/ResourceBundle/modules` may shed some light on the subject.

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

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

From alanb at openjdk.java.net  Mon Dec  6 17:50:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 17:50:15 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets
In-Reply-To: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
Message-ID: <4lhU41InJT9ArnSqU7RZTzMyEPdOoFKZPMxwr4-c-Nk=.fc8ca032-f3ec-4dd4-b4c0-0161fffc072c@github.com>

On Fri, 3 Dec 2021 13:05:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
> 
> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.

Yes, we have to keep chipping away at this. Most of the on-heap usages that I found could have been replaced with VarHandles a long time ago but many of these projects are still building to old JDK releases and maybe MR JARs are still problematic in the build. The great progress on the memory API in Project Panama means it won't be long before those accessors are needed for off-heap. So yes, a few more releases and we should be able to make more progress.

I toyed with including staticFieldBase but I didn't find anything like the usage as the offset methods. Easy to include if you think it's worth doing.

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

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

From prr at openjdk.java.net  Mon Dec  6 17:54:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:54:18 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
Message-ID: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>

On Mon, 29 Nov 2021 08:18:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Use Integer.signum() in BasicTableUI

src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:

> 113:          */
> 114:         public double getX1() {
> 115:             return x1;

What do these changes have to do with the subject of the PR ?

src/java.desktop/share/classes/sun/java2d/Spans.java line 322:

> 320:             float otherStart = otherSpan.getStart();
> 321: 
> 322:             return Float.compare(mStart, otherStart);

We don't need the variable any more, do we ?

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

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

From prr at openjdk.java.net  Mon Dec  6 17:57:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:57:14 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nSZ4HW0XPapNwI8DZeL4VLDLuQGT-Nl9z48R8lHsfHY=.d25aabd8-99e9-48d5-a5e0-eed809c72074@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by prr (Reviewer).

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

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

From psandoz at openjdk.java.net  Mon Dec  6 18:01:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Dec 2021 18:01:17 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets
In-Reply-To: <4lhU41InJT9ArnSqU7RZTzMyEPdOoFKZPMxwr4-c-Nk=.fc8ca032-f3ec-4dd4-b4c0-0161fffc072c@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
 <4lhU41InJT9ArnSqU7RZTzMyEPdOoFKZPMxwr4-c-Nk=.fc8ca032-f3ec-4dd4-b4c0-0161fffc072c@github.com>
Message-ID: <IaKvX9YzBdmbOMyVrIWbyrx-4ej4y_KihEHUapNU5YQ=.119c438c-682f-4175-b382-abe4147b2af0@github.com>

On Mon, 6 Dec 2021 17:47:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I toyed with including staticFieldBase but I didn't find anything like the usage as the offset methods. Easy to include if you think it's worth doing.

Yes, I think you should include it, it's part of this set of functionality (since base is used in conjunction with offsets)

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

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

From rriggs at openjdk.java.net  Mon Dec  6 18:16:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 6 Dec 2021 18:16:15 GMT
Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry
In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com>
Message-ID: <pQaaiMddu_WF6fzD_lBXpHTN3TU1IwKmUX80wnk6TM0=.8b060e34-88ec-4dc2-b5fc-e08ea477f685@github.com>

On Sat, 20 Nov 2021 10:08:41 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.java.net/browse/JDK-8003417?
> 
> The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR.
> 
> The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part.
> 
> A new jtreg test has been added which reproduces the issue as well as verifies the fix.
> `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please.

The value of `currentKey` should track the value of `lastReturned.get()` and does so in the `nextEntry()` and `remove()` methods.  
The odd statement is in `hasNext` that set the state of `currentkey` to null independently of `lastReturned`.
Leaving it non-null will allow `remove` to operate correctly but may have a downside of keeping a strong reference to last key until the HashIterator is GC'd.
The `remove()` method can correctly use `currentKey` to remove the last entry returned.

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

Changes requested by rriggs (Reviewer).

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

From alanb at openjdk.java.net  Mon Dec  6 18:19:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 18:19:39 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets [v2]
In-Reply-To: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
Message-ID: <SZEkc_qjoptaU9j_q36lGdBVfAZitfTt7FEau3ZYqxw=.6f3cc437-974c-45bc-9c62-94f9adf2ec78@github.com>

> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
> 
> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.

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

 - Add staticFieldBase to the list
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6700/files
  - new: https://git.openjdk.java.net/jdk/pull/6700/files/794c6160..40bb5e7e

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

  Stats: 5387 lines in 366 files changed: 3786 ins; 549 del; 1052 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6700/head:pull/6700

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

From alanb at openjdk.java.net  Mon Dec  6 18:19:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 18:19:40 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets
In-Reply-To: <IaKvX9YzBdmbOMyVrIWbyrx-4ej4y_KihEHUapNU5YQ=.119c438c-682f-4175-b382-abe4147b2af0@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
 <4lhU41InJT9ArnSqU7RZTzMyEPdOoFKZPMxwr4-c-Nk=.fc8ca032-f3ec-4dd4-b4c0-0161fffc072c@github.com>
 <IaKvX9YzBdmbOMyVrIWbyrx-4ej4y_KihEHUapNU5YQ=.119c438c-682f-4175-b382-abe4147b2af0@github.com>
Message-ID: <q4ZM_ZXcUv4mSzNRMOxetuKbGUOqgPLizbSF1gdmUIU=.12f5ecad-c3f0-4804-962c-cd745e19fad0@github.com>

On Mon, 6 Dec 2021 17:57:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Yes, I think you should include it, it's part of this set of functionality (since base is used in conjunction with offsets)

Okay, done.

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

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

From mchung at openjdk.java.net  Mon Dec  6 18:38:21 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 6 Dec 2021 18:38:21 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets [v2]
In-Reply-To: <SZEkc_qjoptaU9j_q36lGdBVfAZitfTt7FEau3ZYqxw=.6f3cc437-974c-45bc-9c62-94f9adf2ec78@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
 <SZEkc_qjoptaU9j_q36lGdBVfAZitfTt7FEau3ZYqxw=.6f3cc437-974c-45bc-9c62-94f9adf2ec78@github.com>
Message-ID: <8yrs2lpSJ0_SWgB8z4mnOMpbys3P14A8V-B1pr5RwuA=.54174276-9058-4685-a081-c48d1847e86b@github.com>

On Mon, 6 Dec 2021 18:19:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
>> 
>> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add staticFieldBase to the list
>  - Merge
>  - Initial commit

It's okay to leave `INVALID_FIELD_OFFSET` as is as it's also for `arrayBaseOffset`.

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

Marked as reviewed by mchung (Reviewer).

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

From aleonard at openjdk.java.net  Mon Dec  6 19:11:45 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:45 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/c5104305..59617359

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=18-19

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

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

From aleonard at openjdk.java.net  Mon Dec  6 19:11:48 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:48 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
 <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
Message-ID: <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>

On Mon, 6 Dec 2021 16:36:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:
> 
>> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
>> 299: \                             optional time-zone format, to use for the timestamps of\n\
>> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"
> 
> The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".

ah yes, should have known that, and I did Latin at school !

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

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

From aleonard at openjdk.java.net  Mon Dec  6 19:11:50 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:50 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
 <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
 <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>
Message-ID: <3VHyKp-lqs2LwNAxotV1buStEUkcs6DkMvMAyXXa9gI=.950b3374-826b-4ff9-bfff-7e5677a5f3f3@github.com>

On Mon, 6 Dec 2021 19:04:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:
>> 
>>> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
>>> 299: \                             optional time-zone format, to use for the timestamps of\n\
>>> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"
>> 
>> The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".
>
> ah yes, should have known that, and I did Latin at school !

fixed

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

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

From joehw at openjdk.java.net  Mon Dec  6 19:26:21 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 6 Dec 2021 19:26:21 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v3]
In-Reply-To: <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
Message-ID: <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>

On Sat, 4 Dec 2021 22:34:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use isFixedOffset() instead of useDaylightTime()

src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 31:

> 29: 
> 30: import java.text.MessageFormat;
> 31: import java.time.ZoneId;

nit, the import is not used?

test/jdk/sun/util/resources/TimeZone/ChineseTimeZoneNameTest.java line 66:

> 64: 
> 65:     @Test(dataProvider="locales")
> 66:     public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) {

Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?

The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (??????):
utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");

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

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

From asemenyuk at openjdk.java.net  Mon Dec  6 19:28:26 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 6 Dec 2021 19:28:26 GMT
Subject: RFR: 8278311: Debian packaging doesn't work
Message-ID: <Pnk84Sw6RXuFsHRg9uuPf2uvE0lU6soye_2pA39RIGU=.b1580b7a-3ff1-4889-b4a7-36e1f4ebb742@github.com>

8278311: Debian packaging doesn't work

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

Commit messages:
 - Changes from another fix removed
 - 8278311: Debian packaging doesn't work

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

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

From psandoz at openjdk.java.net  Mon Dec  6 19:35:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Dec 2021 19:35:17 GMT
Subject: RFR: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets [v2]
In-Reply-To: <SZEkc_qjoptaU9j_q36lGdBVfAZitfTt7FEau3ZYqxw=.6f3cc437-974c-45bc-9c62-94f9adf2ec78@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
 <SZEkc_qjoptaU9j_q36lGdBVfAZitfTt7FEau3ZYqxw=.6f3cc437-974c-45bc-9c62-94f9adf2ec78@github.com>
Message-ID: <Cv898cyXHTfly7PbjZz6zMo2P3qx2oGaWIWe4JQgx3M=.cac021b0-7637-4200-99c5-f94d85750a48@github.com>

On Mon, 6 Dec 2021 18:19:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
>> 
>> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add staticFieldBase to the list
>  - Merge
>  - Initial commit

Marked as reviewed by psandoz (Reviewer).

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

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

From joe.darcy at oracle.com  Mon Dec  6 19:51:42 2021
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 6 Dec 2021 11:51:42 -0800
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap
In-Reply-To: <4QPnxA6H9TDEKeXStJ3ndmNl3zwYc02bGhxRF0zBfxY=.75daaf20-4d5e-419d-ac79-f51a5cfbe553@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
 <4QPnxA6H9TDEKeXStJ3ndmNl3zwYc02bGhxRF0zBfxY=.75daaf20-4d5e-419d-ac79-f51a5cfbe553@github.com>
Message-ID: <80eb51a8-7080-eeaa-2e20-ef80d861478c@oracle.com>


On 12/4/2021 4:31 PM, liach wrote:
> On Wed, 24 Nov 2021 05:16:40 GMT, liach <duke at openjdk.java.net> wrote:
>
>> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.
> Since I don't have an account on the JBS, I will post the CSR markdown draft here and hope someone can create one for me.


Created CSR https://bugs.openjdk.java.net/browse/JDK-8278313.

-Joe


From naoto at openjdk.java.net  Mon Dec  6 20:32:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Dec 2021 20:32:55 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v4]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Removed unused import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/cf217f56..8f96e833

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

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

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

From naoto at openjdk.java.net  Mon Dec  6 20:41:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Dec 2021 20:41:17 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v3]
In-Reply-To: <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
 <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>
Message-ID: <pgz5JP-ry0BIOupfgdgEpX6XbeOOYGYM_HHBSup3Orc=.cfef893e-fd30-4298-804c-7165d62caf4d@github.com>

On Mon, 6 Dec 2021 18:52:51 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use isFixedOffset() instead of useDaylightTime()
>
> src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 31:
> 
>> 29: 
>> 30: import java.text.MessageFormat;
>> 31: import java.time.ZoneId;
> 
> nit, the import is not used?

Right. Removed.

> test/jdk/sun/util/resources/TimeZone/ChineseTimeZoneNameTest.java line 66:
> 
>> 64: 
>> 65:     @Test(dataProvider="locales")
>> 66:     public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) {
> 
> Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?
> 
> The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (??????):
> utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");

`??????` is actually coming from `COMPAT` provider, which is wrong. The expected name `??????` in CLDR is in `zh-Hant` resource bundle which is not available in `COMPAT` provider. Thus, comparing `zh-MO` and `zh-Hant` names effectively asserts that the name is correctly coming from `CLDR` provider. I confirmed that this regression test did fail with the runtime without the proposed fix.

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

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

From bchristi at openjdk.java.net  Mon Dec  6 20:41:43 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 6 Dec 2021 20:41:43 GMT
Subject: RFR: JDK-8276447 Deprecate finalization-related methods for
 removal [v4]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <yjAb3SVdTAs6VQz9haonP9y-ZnXker4ZyskjKghmwH0=.c6841727-32de-4840-94d8-4ae568a157fe@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From lancea at openjdk.java.net  Mon Dec  6 20:44:15 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Dec 2021 20:44:15 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <x-Jr9rzAV33O7lOJ1SlhFnkn0HFLb-jTHgA6irxBPOI=.9e72919e-5e02-42de-bef4-c22c36183af3@github.com>

On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The current revision looks good.

The CSR needs similar clean-up for consistency as you just did for the PR.  Do you want to make a pass through it?

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

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

From joehw at openjdk.java.net  Mon Dec  6 20:56:12 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 6 Dec 2021 20:56:12 GMT
Subject: RFR: 8275721: Name of UTC timezone in a locale changes depending
 on previous code [v4]
In-Reply-To: <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>
Message-ID: <mVqn2SMGJGR5JxEKEK_EFwNEwuPeuEDtP9dckE095vQ=.2f3fb939-51e0-4160-810e-71cfcc50efd2@github.com>

On Mon, 6 Dec 2021 20:32:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused import

Marked as reviewed by joehw (Reviewer).

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

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

From aleonard at openjdk.java.net  Mon Dec  6 21:22:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 21:22:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@github.com>
Message-ID: <iDaP3c87Alx054qxYXrIVfTu_oJpU5HQy5LVtsgKXVU=.d90a68ea-aa7f-45c2-95b7-9fd68b115dd8@github.com>

On Mon, 29 Nov 2021 19:08:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> @AlanBateman yes, see above comment, thanks
>> 
>> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.
>
>> > @AlanBateman yes, see above comment, thanks
>> 
>> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.
> 
> I agree with Alan.  We are too close to RDP 1 to consider this type of change for JDK 18 as we need more time to discuss, update the CSR, test (and we will need additional tests for this), and give it time to bake.  IMHO this will need to go into JDK 19 assuming we move forward with changes similar to the latest commit

@LanceAndersen i've done a cleanup of the CSR, I think it looks consistent now: https://bugs.openjdk.java.net/browse/JDK-8277755
thanks

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

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

From darcy at openjdk.java.net  Mon Dec  6 21:52:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 21:52:37 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v9]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <BEusjHE7fm_NEwQ_f8OXu9JsbamDJicDAIidVxJnHU8=.94cbc3cc-5e3e-447c-b86d-463e971bc506@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol files to JDK 18 b26.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...9f68398a

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=08
  Stats: 3870 lines in 67 files changed: 3827 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

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

From heidinga at redhat.com  Mon Dec  6 14:23:13 2021
From: heidinga at redhat.com (Dan Heidinga)
Date: Mon, 6 Dec 2021 09:23:13 -0500
Subject: Reflect arrayElementGetter
In-Reply-To: <CAENv9VHbo60m2V15mUByaoS8VLQ3CGVY0NBKeKpXBJEO18n_VQ@mail.gmail.com>
References: <CAENv9VHbo60m2V15mUByaoS8VLQ3CGVY0NBKeKpXBJEO18n_VQ@mail.gmail.com>
Message-ID: <CAJq4Gi7aKrykQjubcnTe8s0aWw1NsnG+iNJrt6am8NUUaqhnhw@mail.gmail.com>

On Mon, Dec 6, 2021 at 8:10 AM Thiago Henrique Hupner <thihup at gmail.com> wrote:
>
> Hi all.
>
> I've found something weird.
> If I try to "reflect" a MethodHandle.arrayElementGetter, the method
> returned is not accessible, so I need to call setAccessible to be able to
> use it.
> The same happens to arrayElementSetter,
>
> I'd like to know if this is the expected behavior. I was assuming that
> it would return me some java.lang.reflect.Array, but it seems to be
> returning
> an internal implementation.

This is expected behaviour.  The MethodHandle::arrayElementGetter &
::arrayElementSetter methods produce a MethodHandle that reads /
writes an array element "as if by the aaload / aastore bytecode".
Those "as if" words are key as the design intent behind MethodHandles
is that they operate as close to the bytecode semantics as possible.

The j.l.r.Array implementations are native methods so binding to them
- and, at least conceptually, wrapping them with an MH::asType
operation to correct the signature - would be less performant than the
bytecode based access the current implementation supports.  Huge
caveats apply to this reasoning.

MethodHandles that aren't directly looked up using a MHs::Lookup are
generally not intended to be cracked and the result may change from
release to release as better implementations get explored.

--Dan


From jpai at openjdk.java.net  Tue Dec  7 01:50:20 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 7 Dec 2021 01:50:20 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified [v2]
In-Reply-To: <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
Message-ID: <oHTxjxAqpysin3Xv3l5klAZT-G2zTD4zQigBmI8Sc4s=.2d009956-259c-442e-b8bf-30cc3246d074@github.com>

On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments to consistently identify security property names
>   and use the correct bug number in the test.

Thank you Roger for the updates. This looks fine to me.

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

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

From almatvee at openjdk.java.net  Tue Dec  7 05:32:16 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 7 Dec 2021 05:32:16 GMT
Subject: RFR: 8278311: Debian packaging doesn't work
In-Reply-To: <Pnk84Sw6RXuFsHRg9uuPf2uvE0lU6soye_2pA39RIGU=.b1580b7a-3ff1-4889-b4a7-36e1f4ebb742@github.com>
References: <Pnk84Sw6RXuFsHRg9uuPf2uvE0lU6soye_2pA39RIGU=.b1580b7a-3ff1-4889-b4a7-36e1f4ebb742@github.com>
Message-ID: <fFYfiA0z7Ar6FtXycmmUm-vurG0H3PLn3Mc02sAGDRw=.1a25b76c-ab25-4248-8845-a5414bcefe92@github.com>

On Mon, 6 Dec 2021 19:20:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8278311: Debian packaging doesn't work

Marked as reviewed by almatvee (Reviewer).

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

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

From plevart at openjdk.java.net  Tue Dec  7 06:26:14 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 7 Dec 2021 06:26:14 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v7]
In-Reply-To: <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>
Message-ID: <LQNcIksO3U37KNqfn25iGiClgANQelvswZrdWSH_p2Q=.aec1fe05-cd47-4467-b6d3-a3d4827a7181@github.com>

On Mon, 6 Dec 2021 12:12:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cast; add testcase to cover memory pressure

Changes requested by plevart (Reviewer).

test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 84:

> 82: 
> 83:         assertNotNull(ObjectStreamClass.lookup(TestClass.class).getFields());
> 84:     }

I don't quite get this test. It loads ObjectStreamClass_MemoryLeakExample class from child class loader, constructs an instance from it and calls .toString() on an instance. This is just to indicate that the class initializer of that class did lookup an ObjectStreamClass instance for Test class loaded by the same child loader. OK so far...
Then there is this loop that tries to exhibit some memory pressure while constantly looking up OSC for another Test class (this time loaded by parent class loader) presumably to trigger clearing the SoftReference(s) of both classes loaded by child ClassLoader.... Is this what the loop was supposed to do?
And finally there is an assertNotNull that does another lookup for OSC of Test class loaded by parent class loader, retrive its fields and check that the returned OSC instance as well as the field array are not null. This will always succeed regardless of what you do before the assertion.

I don't think you need any custom class loading to verify the correctness of caching. The following two tests pass on old implementation of OSC. Do they pass on the new one too?


public class ObjectStreamClassCaching {

    @Test
    public void testCachingEffectiveness() throws Exception {
        var ref = lookupObjectStreamClass(TestClass.class);
        System.gc();
        Thread.sleep(100L);
        // to trigger any ReferenceQueue processing...
        lookupObjectStreamClass(AnotherTestClass.class);
        Assertions.assertFalse(ref.refersTo(null),
                               "Cache lost entry although memory was not under pressure");
    }

    @Test
    public void testCacheReleaseUnderMemoryPressure() throws Exception {
        var ref = lookupObjectStreamClass(TestClass.class);
        pressMemoryHard(ref);
        System.gc();
        Thread.sleep(100L);
        Assertions.assertTrue(ref.refersTo(null),
                              "Cache still has entry although memory was pressed hard");
    }

    // separate method so that the looked-up ObjectStreamClass is not kept on stack
    private static WeakReference<?> lookupObjectStreamClass(Class<?> cl) {
        return new WeakReference<>(ObjectStreamClass.lookup(cl));
    }

    private static void pressMemoryHard(Reference<?> ref) {
        try {
            var list = new ArrayList<>();
            while (!ref.refersTo(null)) {
                list.add(new byte[1024 * 1024 * 64]); // 64 MiB chunks
            }
        } catch (OutOfMemoryError e) {
            // release
        }
    }
}

class TestClass implements Serializable {
}

class AnotherTestClass implements Serializable {
}

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

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

From duke at openjdk.java.net  Tue Dec  7 08:19:22 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:19:22 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>

On Mon, 6 Dec 2021 17:46:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
> 
>> 113:          */
>> 114:         public double getX1() {
>> 115:             return x1;
> 
> What do these changes have to do with the subject of the PR ?

Just a tiny clean-up in on of affected files. Do you want this to be reverted?

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

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

From duke at openjdk.java.net  Tue Dec  7 08:28:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:28:47 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

  8277868: Inline local var

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/6744a562..1b3a5d4b

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

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

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

From duke at openjdk.java.net  Tue Dec  7 08:54:13 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:54:13 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <xdI5FAZqZeQHMoHxBRdogY8q6Q3K20lfn9baQ4RHpkc=.23bdf93d-a1e4-46f0-8002-ef66029ffe1e@github.com>

On Mon, 6 Dec 2021 17:48:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/sun/java2d/Spans.java line 322:
> 
>> 320:             float otherStart = otherSpan.getStart();
>> 321: 
>> 322:             return Float.compare(mStart, otherStart);
> 
> We don't need the variable any more, do we ?

inlined

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

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

From alanb at openjdk.java.net  Tue Dec  7 09:28:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Dec 2021 09:28:14 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>

On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing.  I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.

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

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

From aleonard at openjdk.java.net  Tue Dec  7 09:36:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 09:36:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
Message-ID: <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>

On Tue, 7 Dec 2021 09:24:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing. I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.

@AlanBateman thank you Alan, yes that does look simpler, the alternate bit just confused things unnecessarily. Ah of course, -J-..
I'm good with the updates,
thanks
Andrew

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

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

From rkennke at openjdk.java.net  Tue Dec  7 10:42:50 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 7 Dec 2021 10:42:50 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v8]
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

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

  Add improved test by @plevart

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6375/files
  - new: https://git.openjdk.java.net/jdk/pull/6375/files/e6e34cea..cfaf08cd

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

  Stats: 102 lines in 2 files changed: 83 ins; 18 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6375/head:pull/6375

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

From rkennke at openjdk.java.net  Tue Dec  7 10:42:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 7 Dec 2021 10:42:53 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v7]
In-Reply-To: <LQNcIksO3U37KNqfn25iGiClgANQelvswZrdWSH_p2Q=.aec1fe05-cd47-4467-b6d3-a3d4827a7181@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <r474ZNjvk8pBOeq54nHml-gzVaws9_6QNrHRIAeLaW0=.23dfa59b-4123-4f3d-b2fa-48e2f792905e@github.com>
 <LQNcIksO3U37KNqfn25iGiClgANQelvswZrdWSH_p2Q=.aec1fe05-cd47-4467-b6d3-a3d4827a7181@github.com>
Message-ID: <SYT14DUnrY4Lc2IGfASEIiwbvD0GrE8w0SGV9JguSyY=.3b0257b8-65ee-4c52-902e-a6a282dd258b@github.com>

On Tue, 7 Dec 2021 06:23:22 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cast; add testcase to cover memory pressure
>
> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoaderLeak.java line 84:
> 
>> 82: 
>> 83:         assertNotNull(ObjectStreamClass.lookup(TestClass.class).getFields());
>> 84:     }
> 
> I don't quite get this test. It loads ObjectStreamClass_MemoryLeakExample class from child class loader, constructs an instance from it and calls .toString() on an instance. This is just to indicate that the class initializer of that class did lookup an ObjectStreamClass instance for Test class loaded by the same child loader. OK so far...
> Then there is this loop that tries to exhibit some memory pressure while constantly looking up OSC for another Test class (this time loaded by parent class loader) presumably to trigger clearing the SoftReference(s) of both classes loaded by child ClassLoader.... Is this what the loop was supposed to do?
> And finally there is an assertNotNull that does another lookup for OSC of Test class loaded by parent class loader, retrive its fields and check that the returned OSC instance as well as the field array are not null. This will always succeed regardless of what you do before the assertion.
> 
> I don't think you need any custom class loading to verify the correctness of caching. The following two tests pass on old implementation of OSC. Do they pass on the new one too?
> 
> 
> public class ObjectStreamClassCaching {
> 
>     @Test
>     public void testCachingEffectiveness() throws Exception {
>         var ref = lookupObjectStreamClass(TestClass.class);
>         System.gc();
>         Thread.sleep(100L);
>         // to trigger any ReferenceQueue processing...
>         lookupObjectStreamClass(AnotherTestClass.class);
>         Assertions.assertFalse(ref.refersTo(null),
>                                "Cache lost entry although memory was not under pressure");
>     }
> 
>     @Test
>     public void testCacheReleaseUnderMemoryPressure() throws Exception {
>         var ref = lookupObjectStreamClass(TestClass.class);
>         pressMemoryHard(ref);
>         System.gc();
>         Thread.sleep(100L);
>         Assertions.assertTrue(ref.refersTo(null),
>                               "Cache still has entry although memory was pressed hard");
>     }
> 
>     // separate method so that the looked-up ObjectStreamClass is not kept on stack
>     private static WeakReference<?> lookupObjectStreamClass(Class<?> cl) {
>         return new WeakReference<>(ObjectStreamClass.lookup(cl));
>     }
> 
>     private static void pressMemoryHard(Reference<?> ref) {
>         try {
>             var list = new ArrayList<>();
>             while (!ref.refersTo(null)) {
>                 list.add(new byte[1024 * 1024 * 64]); // 64 MiB chunks
>             }
>         } catch (OutOfMemoryError e) {
>             // release
>         }
>     }
> }
> 
> class TestClass implements Serializable {
> }
> 
> class AnotherTestClass implements Serializable {
> }

The test was a rather crude (but successful) attempt to demonstrate the ClassCastException. Thanks for providing the better testcase. I verified that it succeeds with this PR, and also demonstrates the ClassCastException if I revert my previous change in ClassCache. I pushed this new test, and removed my old one.

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

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

From shade at openjdk.java.net  Tue Dec  7 11:34:16 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Dec 2021 11:34:16 GMT
Subject: RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
In-Reply-To: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
References: <Uig0D8IYJ0N6kMsT7sFzCOiAoJJnzPfdDeKN1X0148Y=.66d8aeba-b814-4b8f-9c63-6c5482871ba7@github.com>
Message-ID: <B3aRgg_GVY55V2jpoVcVyo9hEBChO3rvXQj-aF3wXis=.3d189db1-971c-4fc8-9048-378d00e9792d@github.com>

On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines.
> 
> This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast.
> 
> So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow.
> 
> Sample run before:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                                174   174     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	2m38.242s
> user	80m7.216s
> sys	2m13.846s
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               2904  2901     3     0 <<
> ==============================
> TEST FAILURE
> 
> real	18m13.933s
> user	546m50.556s
> sys	25m7.086s
> 
> 
> Sample run after:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk:tier3                               1296  1296     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	7m49.017s
> user	287m30.943s
> sys	13m20.060s
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>> jtreg:test/jdk:tier4                               1783  1780     3     0 <<
> ==============================
> TEST FAILURE
> 
> 
> real	12m19.973s
> user	351m48.561s
> sys	14m51.566s

All right, I'll be integrating it soon. Last call for comments :)

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

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

From tnakamura at openjdk.java.net  Tue Dec  7 11:54:53 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Tue, 7 Dec 2021 11:54:53 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
 [v2]
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <negUUO_VHwR0toxnl1kFnfJZ8R6bJ1gqN6yoN_raUsM=.5c61cdf9-2be8-4772-b8bb-7615da4aa78d@github.com>

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

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

  Added a testcase

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6693/files
  - new: https://git.openjdk.java.net/jdk/pull/6693/files/6c73d436..9f689aae

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

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

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

From tnakamura at openjdk.java.net  Tue Dec  7 11:54:54 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Tue, 7 Dec 2021 11:54:54 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <rz_yo90g6clLRtRKO-QVeOGiNQb70SH-Y0hzXeI5mjY=.3a98af6f-839b-47fa-8b13-a9cd10a2cd73@github.com>

On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

Thank you so much for the valuable advices, Jim, Alan, and Naoto.

The created test calls `ImageStringsReader.stringFromByteBufferMatches()` directly.
It's a package private method, and I tried to use library style.

The upper public method, `BasicImageReader.match()`, is hard to prepare data.
Calling jlink is also complex for me. So, I choose this way.

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

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

From lancea at openjdk.java.net  Tue Dec  7 12:06:17 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 7 Dec 2021 12:06:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
 <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
Message-ID: <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>

On Tue, 7 Dec 2021 09:32:47 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> > I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing. I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.
> 
> @AlanBateman thank you Alan, yes that does look simpler, the alternate bit just confused things unnecessarily. Ah of course, -J-.. I'm good with the updates, thanks Andrew

The latest CSR update looks good so I think you are in good shape now

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

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

From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v2]
In-Reply-To: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
 <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
Message-ID: <9S_GeeZQl7DEU-sc0rPTWTs-rECNOmwEQRsj-zMotqU=.4f156b22-5909-4451-8652-9af749bb288f@github.com>

On Tue, 7 Dec 2021 08:16:08 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
>> 
>>> 113:          */
>>> 114:         public double getX1() {
>>> 115:             return x1;
>> 
>> What do these changes have to do with the subject of the PR ?
>
> Just a tiny clean-up in on of affected files. Do you want this to be reverted?

I believe it makes to preserve the cast: the fields are of type `float` and explicit cast hints there's a type conversion.

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

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

From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
Message-ID: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>

On Tue, 7 Dec 2021 08:28:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Inline local var

src/java.base/share/classes/java/util/Calendar.java line 3420:

> 3418:     private int compareTo(long t) {
> 3419:         long thisTime = getMillisOf(this);
> 3420:         return Long.compare(thisTime, t);

Probably, in this case `thisTime` variable can also be dropped.

src/java.base/share/classes/java/util/Date.java line 977:

> 975:         long thisTime = getMillisOf(this);
> 976:         long anotherTime = getMillisOf(anotherDate);
> 977:         return Long.compare(thisTime, anotherTime);

Looks like local variables can also be dropped here as each value is used once.

src/java.base/share/classes/java/util/UUID.java line 517:

> 515:         return (this.mostSigBits < val.mostSigBits ? -1 :
> 516:                 (this.mostSigBits > val.mostSigBits ? 1 :
> 517:                  Long.compare(this.leastSigBits, val.leastSigBits)));

In this case Javadoc specifies only -1, 0 or 1 can be returned. `Long.compare` does not specify this but returns these values. Couldn't it cause any problems in the future if implementation of `Long.compare` is changed?

Does it make sense to use `Long.compare` for `mostSigBits` too?

int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:14:16 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:14:16 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
 <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
 <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>
Message-ID: <j7reY7ihE07r7PR_RI_ELgPYthsw7iZWz7camV6P2EQ=.603da07e-b769-49e8-9edb-7ccb21636c97@github.com>

On Tue, 7 Dec 2021 12:03:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The latest CSR update looks good so I think you are in good shape now

@LanceAndersen thank you Lance

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:14:17 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:14:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>

On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
thanks

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

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

From mcimadamore at openjdk.java.net  Tue Dec  7 13:20:29 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Dec 2021 13:20:29 GMT
Subject: RFR: 8278341: Liveness check for global scope is not as fast as it
 could be
Message-ID: <HtkxUMSsRl44jzPz6fUIBoHXth21Mx2CNkf6sglAY9s=.dbfd8575-3f84-48b8-b9b8-10bc2982099d@github.com>

When doing some unrelated performance measurements, I realized that segments backed by global scope were still paying a relatively high cost for liveness checks - that's because GlobalScopeImpl extends from SharedScopeImpl, and does not override the `isAlive` method. This means that when checking for liveness, we will still do (in some cases - e.g. when calling `checkValidStateSlow`) a volatile VH get on the scope state - which is useless in this case.

This simple patch adds the missing override.

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

Commit messages:
 - Override isAlive in global scope implementation

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

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

From alanb at openjdk.java.net  Tue Dec  7 13:31:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Dec 2021 13:31:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>
Message-ID: <QPzt4WMTT0tj-3ZnN_-w5sBB5--rBU85ruypu9tMAyo=.cbb1baaa-36c2-4a86-8823-3fd52efcdef6@github.com>

On Tue, 7 Dec 2021 13:10:53 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> @jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
> thanks

For the CSR then you need to press "Finalize".

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:49:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:49:23 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <l8CsQJ1WwyqKris7jDJw_xTOk_wr5u81JrUwNqyLK4c=.25f95a47-137d-4806-8e11-f7f8b299949c@github.com>

On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thanks, CSR now Finalized

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

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

From shade at openjdk.java.net  Tue Dec  7 13:59:14 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Dec 2021 13:59:14 GMT
Subject: RFR: 8278341: Liveness check for global scope is not as fast as it
 could be
In-Reply-To: <HtkxUMSsRl44jzPz6fUIBoHXth21Mx2CNkf6sglAY9s=.dbfd8575-3f84-48b8-b9b8-10bc2982099d@github.com>
References: <HtkxUMSsRl44jzPz6fUIBoHXth21Mx2CNkf6sglAY9s=.dbfd8575-3f84-48b8-b9b8-10bc2982099d@github.com>
Message-ID: <EO7DdVkgTQCd3zLc15b8L7EGMmGWWkucmgn8lLaRnME=.a12ef774-0822-490a-9f48-edc8d265a226@github.com>

On Tue, 7 Dec 2021 13:12:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When doing some unrelated performance measurements, I realized that segments backed by global scope were still paying a relatively high cost for liveness checks - that's because GlobalScopeImpl extends from SharedScopeImpl, and does not override the `isAlive` method. This means that when checking for liveness, we will still do (in some cases - e.g. when calling `checkValidStateSlow`) a volatile VH get on the scope state - which is useless in this case.
> 
> This simple patch adds the missing override.

Looks good!

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

Marked as reviewed by shade (Reviewer).

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

From jvernee at openjdk.java.net  Tue Dec  7 14:12:18 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 7 Dec 2021 14:12:18 GMT
Subject: RFR: 8278341: Liveness check for global scope is not as fast as it
 could be
In-Reply-To: <HtkxUMSsRl44jzPz6fUIBoHXth21Mx2CNkf6sglAY9s=.dbfd8575-3f84-48b8-b9b8-10bc2982099d@github.com>
References: <HtkxUMSsRl44jzPz6fUIBoHXth21Mx2CNkf6sglAY9s=.dbfd8575-3f84-48b8-b9b8-10bc2982099d@github.com>
Message-ID: <BnSt3dsRs2DAM-yfBoh8BzqROIwhqXnk9P-WOcuVAxw=.5109050c-1c3e-411b-9119-acd9b4cc68a0@github.com>

On Tue, 7 Dec 2021 13:12:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When doing some unrelated performance measurements, I realized that segments backed by global scope were still paying a relatively high cost for liveness checks - that's because GlobalScopeImpl extends from SharedScopeImpl, and does not override the `isAlive` method. This means that when checking for liveness, we will still do (in some cases - e.g. when calling `checkValidStateSlow`) a volatile VH get on the scope state - which is useless in this case.
> 
> This simple patch adds the missing override.

Marked as reviewed by jvernee (Reviewer).

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

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

From alanb at openjdk.java.net  Tue Dec  7 14:25:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Dec 2021 14:25:19 GMT
Subject: Integrated: 8277863: Deprecate sun.misc.Unsafe methods that return
 offsets
In-Reply-To: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
References: <g7tV1lA62zl0KbHJgATt09UAPz5VJA9BJEa2d-Oh39A=.009b7d33-ada5-43e9-aa54-8b5f7758eaf2@github.com>
Message-ID: <IYJKwvvTMxy_0LifSsPCGDC0t-yKOysFAssi1lZi030=.7ac28207-59c4-4b59-a6e0-c9f7b674408c@github.com>

On Fri, 3 Dec 2021 13:05:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Deprecate the sun.misc.Unsafe methods that return field offsets. These method are an impediment to possible future changes. Layout may not be fixed in the future, the VM should be allowed to re-layout dynamically based on patterns of usage. We also have the issue of libraries using these methods to get offsets (sometimes of classes with the same layout as JDK classes) so they can directly access the fields of privileged classes. It's untenable for libraries to rely on this going forward.
> 
> The java.lang.invoke.VarHandle API (added in Java 9) provides a strongly typed reference to a variable that is a safe and a much better alternative to many cases that use these methods. Deprecating these method provides a gentle nudge in that directory. Once the Panama memory APIs are permanent then we can look at terminally deprecating and removing these methods, along with the accessors.

This pull request has now been integrated.

Changeset: 56ca66e8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/56ca66e86f848d3790115aa2faec632c226d8cd2
Stats:     20 lines in 1 file changed: 20 ins; 0 del; 0 mod

8277863: Deprecate sun.misc.Unsafe methods that return offsets

Reviewed-by: psandoz, mchung

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

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

From duke at openjdk.java.net  Tue Dec  7 14:39:46 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:46 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v4]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <6H721EvqNvo4S4PAIRiqFgVtORHDFVjUW_nQ3LJIdvM=.685ca0ab-0ba9-4501-9e4e-6de9ca93be51@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

 - 8277868: Revert irrelevant changes
 - 8277868: Inline local vars

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/1b3a5d4b..bb06bf2f

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

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

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

From duke at openjdk.java.net  Tue Dec  7 14:39:51 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:51 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v3]
In-Reply-To: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
 <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
Message-ID: <RfAx0opkX4lKUfu0edbgotzC4KFnDpeipa3-1_109mI=.232d9ebe-15be-475f-a720-c6165dcb0b3c@github.com>

On Tue, 7 Dec 2021 12:01:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Inline local var
>
> src/java.base/share/classes/java/util/Calendar.java line 3420:
> 
>> 3418:     private int compareTo(long t) {
>> 3419:         long thisTime = getMillisOf(this);
>> 3420:         return Long.compare(thisTime, t);
> 
> Probably, in this case `thisTime` variable can also be dropped.

Inlined

> src/java.base/share/classes/java/util/Date.java line 977:
> 
>> 975:         long thisTime = getMillisOf(this);
>> 976:         long anotherTime = getMillisOf(anotherDate);
>> 977:         return Long.compare(thisTime, anotherTime);
> 
> Looks like local variables can also be dropped here as each value is used once.

Inlined

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

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

From darcy at openjdk.java.net  Thu Dec  9 17:07:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Dec 2021 17:07:18 GMT
Subject: Integrated: JDK-8273146: Start of release updates for JDK 19
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <qJE3l7bbGSefMtF1mI5-Sd-2nDoul8oEzCgvQr4LMis=.1f8167ad-2d8f-4c84-b3a1-afa5493430e1@github.com>

On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

This pull request has now been integrated.

Changeset: 09831e7a
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09831e7aa47ebe41eab2f3014ebbacf338097ef6
Stats:     4252 lines in 67 files changed: 4206 ins; 7 del; 39 mod

8273146: Start of release updates for JDK 19
8277511: Add SourceVersion.RELEASE_19
8277513: Add source 19 and target 19 to javac

Reviewed-by: dholmes, alanb, erikj, iris, mikael, ihse

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

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

From naoto at openjdk.java.net  Thu Dec  9 17:31:18 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Dec 2021 17:31:18 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
 [v4]
In-Reply-To: <3_bFZNrHz1lV2eXs_8a8yJupCSxUQA4GQ6AOCqY6qBs=.7058051b-7f19-48ea-b9ad-2f9c95239f9f@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
 <3_bFZNrHz1lV2eXs_8a8yJupCSxUQA4GQ6AOCqY6qBs=.7058051b-7f19-48ea-b9ad-2f9c95239f9f@github.com>
Message-ID: <GKDtkOS1baPGiKaTzgp7BcZuShxQ_mxKxue4ibeiHO4=.8174e614-0007-43d0-b398-aa11f8798acc@github.com>

On Fri, 3 Dec 2021 12:35:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed testcase name to JImageNonAsciiNameTest.java
>
> Change looks reasonable. A regression test should be provided. Contact me directly for advice.

Sure, I can. But I would like @JimLaskey to have a final look at it.

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

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

From jlaskey at openjdk.java.net  Thu Dec  9 17:39:16 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 9 Dec 2021 17:39:16 GMT
Subject: RFR: 8278185: Custom JRE cannot find non-ASCII named module inside
 [v4]
In-Reply-To: <3_bFZNrHz1lV2eXs_8a8yJupCSxUQA4GQ6AOCqY6qBs=.7058051b-7f19-48ea-b9ad-2f9c95239f9f@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
 <3_bFZNrHz1lV2eXs_8a8yJupCSxUQA4GQ6AOCqY6qBs=.7058051b-7f19-48ea-b9ad-2f9c95239f9f@github.com>
Message-ID: <oXDYlQ8vTDlSYuoUwYZtzTTVXvOK7xhDOAC2v7h7VJ0=.ccb138b6-005b-4bc0-b55e-0f721e612061@github.com>

On Fri, 3 Dec 2021 12:35:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed testcase name to JImageNonAsciiNameTest.java
>
> Change looks reasonable. A regression test should be provided. Contact me directly for advice.

> Sure, I can. But I would like @JimLaskey to have a final look at it.

Standing by

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

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

From aleonard at openjdk.java.net  Thu Dec  9 18:07:58 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:07:58 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/59617359..436762f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=19-20

  Stats: 457 lines in 3 files changed: 296 ins; 147 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From aleonard at openjdk.java.net  Thu Dec  9 18:08:03 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:08:03 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <l8VPJRM10FjI9eO-Q7DVZfq41tNNNbBBz6Ct3zxXqYo=.0cfb2f9f-5533-4300-8afc-a488661fff70@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <l8VPJRM10FjI9eO-Q7DVZfq41tNNNbBBz6Ct3zxXqYo=.0cfb2f9f-5533-4300-8afc-a488661fff70@github.com>
Message-ID: <QLWc-Hc1IuYZepb82LyMl-5KbVTOFyyglqzZhe1Kt4g=.cc363dac-0f34-4d90-9cbe-2da844ec1d7c@github.com>

On Wed, 8 Dec 2021 16:51:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2339:
> 
>> 2337:         } else {
>> 2338:           e.setTime(origTime);
>> 2339:         }
> 
> I think the 8 usages would be a bit clearer if renamed setZipEntryTime. Minor nit in the 2-arg setDate is that it's using 2-space indent instead of 4.

thanks, fixed

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

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

From aleonard at openjdk.java.net  Thu Dec  9 18:09:37 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:09:37 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
Message-ID: <BB7TzfyXAG-bIBlCDYR0jpA-cu-Ci76NOUAwzXa4he4=.b686676f-d66a-48ce-9314-fdbfc73a65fd@github.com>

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR

@LanceAndersen hi Lance, i've moved the new jar reproducible changes into a new test class in TestNG ReproducibleJar.java
and added the Unix 2038 XFS special case
Ready for your review please, if you're able to test on that mach5 machine again please?

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

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

From alanb at openjdk.java.net  Thu Dec  9 18:40:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 9 Dec 2021 18:40:20 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v2]
In-Reply-To: <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
Message-ID: <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>

On Thu, 9 Dec 2021 07:58:33 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clean up reproducer test case
>  - Keep helper in ZipFileSystem simple

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 211:

> 209: 
> 210:     private String getRealPath(byte[] resolvedPath) {
> 211:         byte[] path = zfs.lookupPath(resolvedPath);

Can getRealPath be changed to be no-arg method that calls getResolvedPath and then does the lookup. I think that would be a clearer than assuming the argument is a resolved path.

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

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

From tnakamura at openjdk.java.net  Thu Dec  9 19:08:21 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 9 Dec 2021 19:08:21 GMT
Subject: Integrated: 8278185: Custom JRE cannot find non-ASCII named module
 inside
In-Reply-To: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
References: <ZbAeXOC-oNhihY-cwSz198X_Lahx95YDW-EMNmYsSiY=.9bc0057e-2969-4191-92c6-9fce5892fe2a@github.com>
Message-ID: <tvrNmCZaxmFw-KT3O4wN5tEZqczdiAQeNplRWImYRNQ=.f74c88ac-ed3a-44ef-8eb6-025e1365fd4d@github.com>

On Fri, 3 Dec 2021 07:29:17 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> Could you review this fix?
> 
> Problem:
> Custom JRE generated by jlink cannot find non-ASCII named modules included inside the JRE.
> 
> Cause and fix:
> If module or package name was composed by ASCII then non-ASCII characters, 
> ImageStringsReader:stringFromByteBufferMatches() miscalculated the length of matched string. The first part of ASCII characters was missing. This patch corrected the value.
> 
> Testing:
> tier1 and tier2 on Linux have no regression.
> I wasn't able to create an automate test for this issue. I appreciate any advice.

This pull request has now been integrated.

Changeset: fcd67a52
Author:    Toshio Nakamura <tnakamura at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fcd67a5242b7db06e4cb06b574972a463b209b2e
Stats:     99 lines in 2 files changed: 98 ins; 0 del; 1 mod

8278185: Custom JRE cannot find non-ASCII named module inside

Reviewed-by: naoto

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

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

From lancea at openjdk.java.net  Thu Dec  9 21:24:29 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 9 Dec 2021 21:24:29 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
Message-ID: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>

On Thu, 9 Dec 2021 18:07:58 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Hi Andrew,

Thank you for splitting out the test into its own file and addressing the test issues we found.

Overall looks good.  I have suggested some additional changes so the test is slightly more TestNG friendly and a few places where it would be useful to add comments

test/jdk/tools/jar/ReproducibleJar.java line 30:

> 28:  *          reproducible
> 29:  * @modules jdk.jartool
> 30:  * @run testng ReproducibleJar

Probably use othervm given you are toggling the TZ for extra safety

test/jdk/tools/jar/ReproducibleJar.java line 49:

> 47: import java.time.LocalDateTime;
> 48: import java.time.ZonedDateTime;
> 49: import java.time.ZoneId;

Duplicate import?  Perhaps get rid to the import of line 43

test/jdk/tools/jar/ReproducibleJar.java line 74:

> 72:     private static final File jarFileSourceDate1 = new File("JarEntryTimeSourceDate1.jar");
> 73:     private static final File jarFileSourceDate2 = new File("JarEntryTimeSourceDate2.jar");
> 74: 

Please consider using caps for your static final variable names

test/jdk/tools/jar/ReproducibleJar.java line 87:

> 85:                                 "2098-02-18T00:00:00-08:00",
> 86:                                 "2099-12-31T23:59:59+00:00"};
> 87: 

I would suggest converting to a DataProvider for the test.

test/jdk/tools/jar/ReproducibleJar.java line 95:

> 93:                                  "2006-04-06T12:38:00",
> 94:                                  "2012-08-24T16"};
> 95: 

Another good use of a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 102:

> 100:         jarFileSourceDate1.delete();
> 101:         jarFileSourceDate2.delete();
> 102:         TimeZone.setDefault(TZ);

I believe you could just call runAfter() from within this method

test/jdk/tools/jar/ReproducibleJar.java line 114:

> 112:     }
> 113: 
> 114:     @Test

Please add a comment introducing the intent of the test.  As mentioned above, please consider using a DataProvider vs. an array with the test.

test/jdk/tools/jar/ReproducibleJar.java line 120:

> 118:         // Test --date source date
> 119:         for (String sourceDate : sourceDates) {
> 120:             createOuterInnerDirs(dirOuter, dirInner);

If you use a DataProvider,  you could call this method from your runBeforeMethod

test/jdk/tools/jar/ReproducibleJar.java line 147:

> 145:             cleanup(dirInner);
> 146:             cleanup(dirOuter);
> 147:             jarFileSourceDate1.delete();

Is the above needed given your  `@AfterMethod`

test/jdk/tools/jar/ReproducibleJar.java line 152:

> 150: 
> 151:     @Test
> 152:     public void testInvalidSourceDate() throws Throwable {

Please add a basic comment of the intent of the method and consider using a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 165:

> 163: 
> 164:     @Test
> 165:     public void testJarsReproducible() throws Throwable {

Please add a basic comment of the intent of the method and consider using a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 193:

> 191: 
> 192:             // Check jars are identical
> 193:             checkSameContent(jarFileSourceDate1, jarFileSourceDate2);

You could if you choose use:

 Assert.assertEquals(Files.readAllBytes(jarFileSourceDate1.toPath(), Files.readAllBytes(jarFileSourceDate2.toPath()));

test/jdk/tools/jar/ReproducibleJar.java line 199:

> 197:             jarFileSourceDate1.delete();
> 198:             jarFileSourceDate2.delete();
> 199:         }

I believe your` @AfterMethod` will address this so the above is not needed

test/jdk/tools/jar/ReproducibleJar.java line 202:

> 200:     }
> 201: 
> 202:     static void createOuterInnerDirs(File dirOuter, File dirInner) throws Throwable {

I believe you are always passing in the same parameter values, so perhaps no need for the parameters?

test/jdk/tools/jar/ReproducibleJar.java line 208:

> 206:          *         foo.txt
> 207:          */
> 208:         Assert.assertTrue(dirOuter.mkdir());

Please move the  comment above the method

test/jdk/tools/jar/ReproducibleJar.java line 219:

> 217:     }
> 218: 
> 219:     static void checkFileTime(long now, long original) throws Throwable {

Please add a basic comment of the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 241:

> 239:     }
> 240: 
> 241:     static void checkSameContent(File f1, File f2) throws Throwable {

See comment above for consideration  regarding the use of Assert.assertEquals

test/jdk/tools/jar/ReproducibleJar.java line 249:

> 247:     }
> 248: 
> 249:     private static boolean isTimeSettingChanged() {

Please add a basic comment describing the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 260:

> 258:     }
> 259: 
> 260:     private static boolean isInTransition() {

Please add a basic comment of the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 278:

> 276:         File[] x = dir.listFiles();
> 277:         if (x != null) {
> 278:             for (int i = 0; i < x.length; i++) {

Could use enhanced for loop here if you desire

test/jdk/tools/jar/ReproducibleJar.java line 286:

> 284: 
> 285:     static void extractJar(File jarFile) throws Throwable {
> 286:         String javahome = System.getProperty("java.home");

Please add a basic comment of the intent of the method.

Any reason you chose not to use JAR_TOOL here?

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

Marked as reviewed by lancea (Reviewer).

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

From aleonard at openjdk.java.net  Thu Dec  9 22:15:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 22:15:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <VzPePmIUH5tmjcOBgh_FQadm-NkB3FHn7T-Uqu3jEvU=.2ff03ae8-68d2-4943-977a-f93516d69711@github.com>

On Thu, 9 Dec 2021 18:14:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ReproducibleJar.java line 87:
> 
>> 85:                                 "2098-02-18T00:00:00-08:00",
>> 86:                                 "2099-12-31T23:59:59+00:00"};
>> 87: 
> 
> I would suggest converting to a DataProvider for the test.

thanks, that's neat, not used a @DataProvider before

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

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

From jjg at openjdk.java.net  Fri Dec 10 01:56:54 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 01:56:54 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
Message-ID: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>

Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

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

Commit messages:
 - JDK-8273179: Update nroff pages in JDK 18 before RC

Changes: https://git.openjdk.java.net/jdk18/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=5&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273179
  Stats: 858 lines in 28 files changed: 448 ins; 146 del; 264 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/5/head:pull/5

PR: https://git.openjdk.java.net/jdk18/pull/5

From dholmes at openjdk.java.net  Fri Dec 10 02:15:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Dec 2021 02:15:33 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <XrztouvnRkkwistowUfWLgdBTgHP0fRisw3FZGuvalE=.413f903f-4421-4369-9da2-05853a6aaecb@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Hi Jon,

This all looks good - I'm familiar with many of the changes made to the sources but not yet generated.

We will have to be careful not to regress the copyright year or version if any subsequent updates are made before next year, or before the version loses the EA designator.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 02:53:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 02:53:14 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Hi David,

The copyright year will naturally sort itself out in a few weeks time ;-)  

When these changes make their way down from 18 to 19, we will probably want to regenerate these files with 19-EA.

-- Jon

We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period.

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 02:53:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 02:53:14 GMT
Subject: [jdk18] Integrated: JDK-8273179: Update nroff pages in JDK 18 before
 RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <aUgePa-CZTl_8YUtExHfRcG35KchfIqrsFZfnblx5Cw=.16776a76-72c6-4eb0-bfd7-1a7d25843819@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

This pull request has now been integrated.

Changeset: ed5d53ae
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/ed5d53ae0eb0b12de11fb3d79ae0371c093ce434
Stats:     858 lines in 28 files changed: 448 ins; 146 del; 264 mod

8273179: Update nroff pages in JDK 18 before RC

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From iris at openjdk.java.net  Fri Dec 10 03:12:20 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 10 Dec 2021 03:12:20 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <6aEQaagQdXw209dha2rqp32uSxtxze-f-1-j32dROQE=.53c0fcde-680f-40c6-bbc7-44a1e4635f11@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From serb at openjdk.java.net  Fri Dec 10 03:18:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Dec 2021 03:18:37 GMT
Subject: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the
 java.util.logging [v2]
In-Reply-To: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
References: <qgr9AoAEl2VhjQIefvu0fn8Q2_9I32-VRd_bg3u6IZE=.35e2776a-74ad-48ea-a11e-0546d9b2f1c6@github.com>
Message-ID: <oMxSMgfs2sbqnG2_YD9cgbzxAqLrq9qC0QFF6ZlYZBc=.88298f7c-52c3-40ed-8b35-51b5f60f10c1@github.com>

> At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8273101
 - Some tests deleted
 - Update the RootLevelInConfigFile test
 - Initial version of JDK-8273101

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

Changes: https://git.openjdk.java.net/jdk/pull/5326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=01
  Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326

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

From jincheng at ca.ibm.com  Fri Dec 10 03:30:15 2021
From: jincheng at ca.ibm.com (Cheng Jin)
Date: Thu, 9 Dec 2021 23:30:15 -0400
Subject: Request for backport the OpenJDK fix in XSLTC.java to JDK11 & JDK17
Message-ID: <OF40838492.33E06D2C-ON002587A7.0012BB3C-852587A7.00133FC2@ibm.com>



Hi there,

As for the bug with the class name in XSLTC.java I previously raised at
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/083135.html
,
I notice it has been resolved at
https://bugs.openjdk.java.net/browse/JDK-8276657 as follows:

https://github.com/openjdk/jdk/blob/a093cdddaf5ab88eb84a147e523db5c3e1be54be/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java

public boolean compile(InputSource input, String name) {
        try {
            // Reset globals in case we're called by compile(ArrayList v);
            reset();

            // The systemId may not be set, so we'll have to check the URL
            String systemId = null;
            if (input != null) {
                systemId = input.getSystemId();
            }

            // Set the translet class name if not already set
            if (_className == null) {
                if (name != null) {
                    setClassName(name);
                }
                else if (systemId != null && !systemId.isEmpty()) { <------
                    String clsName = Util.baseName(systemId);
                    if (clsName != null && !clsName.isEmpty()) {
                        setClassName(clsName);
                    }
                }


With this fix at https://git.openjdk.java.net/jdk/pull/6620, would you
please backport it to JDK11 & JDK17 given the code there is at the same
place? Thanks in advance.


Thanks and Best Regards
Cheng Jin

From dholmes at openjdk.java.net  Fri Dec 10 04:21:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Dec 2021 04:21:18 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
 <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>
Message-ID: <qVuvwqe8lbBR-Web-A5nWUe6iY9w4VxcPcqZFqsmbqk=.f9daa291-cb0a-4c8f-ad0a-cde4ac1cf5ae@github.com>

On Fri, 10 Dec 2021 02:48:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.
>
> We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period.

Hi @jonathan-gibbons ,

I have a couple of manpage related tasks for early in the 19 release cycle that will take care of updating the version number.

Unfortunately for this change it looks like whomever did the source uodate to the javadoc manpage did not know about the test:

test/langtools/jdk/javadoc/tool/CheckManPageOptions.java

which is now failing on all platforms. :( I will file a bug.

David

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 04:33:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 04:33:14 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <oP-JJ5AfuaU7KEDEmjWC-rZ0kVRFQy5KRAyWHyrukrg=.3670ffc5-0df7-41e6-afe6-66fbb8732685@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

hmmm, I thought we had taken care of that test. I will investigate

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From cjplummer at openjdk.java.net  Fri Dec 10 07:06:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 10 Dec 2021 07:06:36 GMT
Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with
 RuntimeException 'JShellToolProvider' missing from stdout/stderr
Message-ID: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com>

The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump.

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

Commit messages:
 - Retry heap dump if main thread stack trace is not present.

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

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

From cstein at openjdk.java.net  Fri Dec 10 08:16:46 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 10 Dec 2021 08:16:46 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

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

  Turn `getRealPath()` into a no-arg helper method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6768/files
  - new: https://git.openjdk.java.net/jdk/pull/6768/files/e62721a5..12e106c6

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

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

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

From cstein at openjdk.java.net  Fri Dec 10 08:16:51 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 10 Dec 2021 08:16:51 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v2]
In-Reply-To: <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
 <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>
Message-ID: <FZGnKR2-pTsFbFnVtfkQ8cB2uZkR-hlDSkWKY-CW5jw=.64d5ce0e-9a6b-481f-adea-a5ea0d9d4d97@github.com>

On Thu, 9 Dec 2021 18:37:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Clean up reproducer test case
>>  - Keep helper in ZipFileSystem simple
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 211:
> 
>> 209: 
>> 210:     private String getRealPath(byte[] resolvedPath) {
>> 211:         byte[] path = zfs.lookupPath(resolvedPath);
> 
> Can getRealPath be changed to be no-arg method that calls getResolvedPath and then does the lookup. I think that would be a clearer than assuming the argument is a resolved path.

Done via https://github.com/openjdk/jdk/pull/6768/commits/12e106c6e69449f1fbde9e5b6a5ff3305c5de547

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

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

From alanb at openjdk.java.net  Fri Dec 10 09:08:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Dec 2021 09:08:14 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <4GBNHwF6NlDHsQlgt4HM7Gatr4SStsQdn833oZFBRRo=.30c50bd4-e4ff-4eed-a1c1-5dad3b896e3f@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

The changes to zipfs in the latest revision look good

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

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

From kevinw at openjdk.java.net  Fri Dec 10 09:21:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 10 Dec 2021 09:21:14 GMT
Subject: RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with
 RuntimeException 'JShellToolProvider' missing from stdout/stderr
In-Reply-To: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com>
References: <82dnaI69u1ANOPdqoB7ry88-ILyEv3t47dHoBGZUUIo=.d190cf0a-47d3-4b91-881c-627657bebfff@github.com>
Message-ID: <apRnp7Nlb-yQTlgrHHNtGMYOhHIIKKztHW1rwzySch8=.e5b9dd78-c6e7-4a7b-9503-060c730690ce@github.com>

On Fri, 10 Dec 2021 07:00:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does a few things before waiting again. If SA tries to get the stack trace while the thread is active, it may not be able to, and this causes the test to fail. I determined this only happens about 1 in 5000-10000 runs. So as a fix I'm allowing the test to do one retry. That should make it extremely unlikely that we ever see this failure again. I also bumped up the amount of time the test waits before doing the heap dump from 2 seconds to 4 just to make absolutely sure the main thread is fully started before doing the heap dump.

Looks good.

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

Marked as reviewed by kevinw (Committer).

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

From aleonard at openjdk.java.net  Fri Dec 10 10:22:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:22:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <VzPePmIUH5tmjcOBgh_FQadm-NkB3FHn7T-Uqu3jEvU=.2ff03ae8-68d2-4943-977a-f93516d69711@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
 <VzPePmIUH5tmjcOBgh_FQadm-NkB3FHn7T-Uqu3jEvU=.2ff03ae8-68d2-4943-977a-f93516d69711@github.com>
Message-ID: <sdtEkdKHJCmz245LSU5dDxn3TygcxcA-tHUfmMqXXt0=.d9debbe8-4a4a-46d3-a625-7f84656b00df@github.com>

On Thu, 9 Dec 2021 22:11:57 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> test/jdk/tools/jar/ReproducibleJar.java line 87:
>> 
>>> 85:                                 "2098-02-18T00:00:00-08:00",
>>> 86:                                 "2099-12-31T23:59:59+00:00"};
>>> 87: 
>> 
>> I would suggest converting to a DataProvider for the test.
>
> thanks, that's neat, not used a @DataProvider before

done

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

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

From aleonard at openjdk.java.net  Fri Dec 10 10:22:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:22:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <r6V_jdJP51WaXNR6ftXduSz5XUxBmO59r5lvFDv4B0g=.079de4d0-353b-4cd0-83db-dbf1496e07a2@github.com>

On Thu, 9 Dec 2021 18:14:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ReproducibleJar.java line 95:
> 
>> 93:                                  "2006-04-06T12:38:00",
>> 94:                                  "2012-08-24T16"};
>> 95: 
> 
> Another good use of a DataProvider

done

> test/jdk/tools/jar/ReproducibleJar.java line 193:
> 
>> 191: 
>> 192:             // Check jars are identical
>> 193:             checkSameContent(jarFileSourceDate1, jarFileSourceDate2);
> 
> You could if you choose use:
> 
>  Assert.assertEquals(Files.readAllBytes(jarFileSourceDate1.toPath(), Files.readAllBytes(jarFileSourceDate2.toPath()));

done

> test/jdk/tools/jar/ReproducibleJar.java line 219:
> 
>> 217:     }
>> 218: 
>> 219:     static void checkFileTime(long now, long original) throws Throwable {
> 
> Please add a basic comment of the intent of the method

done

> test/jdk/tools/jar/ReproducibleJar.java line 241:
> 
>> 239:     }
>> 240: 
>> 241:     static void checkSameContent(File f1, File f2) throws Throwable {
> 
> See comment above for consideration  regarding the use of Assert.assertEquals

done

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

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

From aleonard at openjdk.java.net  Fri Dec 10 10:34:26 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:34:26 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <TgRxJO4VAQ5qvbnoqmogGDCtxf20xmmEmypDbVsfEVI=.fc3758d2-65e1-40dc-87fc-05ec301ca213@github.com>

On Thu, 9 Dec 2021 18:40:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ReproducibleJar.java line 30:
> 
>> 28:  *          reproducible
>> 29:  * @modules jdk.jartool
>> 30:  * @run testng ReproducibleJar
> 
> Probably use othervm given you are toggling the TZ for extra safety

done

> test/jdk/tools/jar/ReproducibleJar.java line 49:
> 
>> 47: import java.time.LocalDateTime;
>> 48: import java.time.ZonedDateTime;
>> 49: import java.time.ZoneId;
> 
> Duplicate import?  Perhaps get rid to the import of line 43

done

> test/jdk/tools/jar/ReproducibleJar.java line 102:
> 
>> 100:         jarFileSourceDate1.delete();
>> 101:         jarFileSourceDate2.delete();
>> 102:         TimeZone.setDefault(TZ);
> 
> I believe you could just call runAfter() from within this method

done

> test/jdk/tools/jar/ReproducibleJar.java line 120:
> 
>> 118:         // Test --date source date
>> 119:         for (String sourceDate : sourceDates) {
>> 120:             createOuterInnerDirs(dirOuter, dirInner);
> 
> If you use a DataProvider,  you could call this method from your runBeforeMethod

done

> test/jdk/tools/jar/ReproducibleJar.java line 147:
> 
>> 145:             cleanup(dirInner);
>> 146:             cleanup(dirOuter);
>> 147:             jarFileSourceDate1.delete();
> 
> Is the above needed given your  `@AfterMethod`

done

> test/jdk/tools/jar/ReproducibleJar.java line 152:
> 
>> 150: 
>> 151:     @Test
>> 152:     public void testInvalidSourceDate() throws Throwable {
> 
> Please add a basic comment of the intent of the method and consider using a DataProvider

done

> test/jdk/tools/jar/ReproducibleJar.java line 165:
> 
>> 163: 
>> 164:     @Test
>> 165:     public void testJarsReproducible() throws Throwable {
> 
> Please add a basic comment of the intent of the method and consider using a DataProvider

done

> test/jdk/tools/jar/ReproducibleJar.java line 199:
> 
>> 197:             jarFileSourceDate1.delete();
>> 198:             jarFileSourceDate2.delete();
>> 199:         }
> 
> I believe your` @AfterMethod` will address this so the above is not needed

done

> test/jdk/tools/jar/ReproducibleJar.java line 202:
> 
>> 200:     }
>> 201: 
>> 202:     static void createOuterInnerDirs(File dirOuter, File dirInner) throws Throwable {
> 
> I believe you are always passing in the same parameter values, so perhaps no need for the parameters?

done

> test/jdk/tools/jar/ReproducibleJar.java line 208:
> 
>> 206:          *         foo.txt
>> 207:          */
>> 208:         Assert.assertTrue(dirOuter.mkdir());
> 
> Please move the  comment above the method

done

> test/jdk/tools/jar/ReproducibleJar.java line 249:
> 
>> 247:     }
>> 248: 
>> 249:     private static boolean isTimeSettingChanged() {
> 
> Please add a basic comment describing the intent of the method

done

> test/jdk/tools/jar/ReproducibleJar.java line 260:
> 
>> 258:     }
>> 259: 
>> 260:     private static boolean isInTransition() {
> 
> Please add a basic comment of the intent of the method

done

> test/jdk/tools/jar/ReproducibleJar.java line 278:
> 
>> 276:         File[] x = dir.listFiles();
>> 277:         if (x != null) {
>> 278:             for (int i = 0; i < x.length; i++) {
> 
> Could use enhanced for loop here if you desire

done

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

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

From aleonard at openjdk.java.net  Fri Dec 10 10:39:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:39:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <0EEjNNoJRT32Iu4DkEkbNlBxtql7-vNTQY6W5bQNBzA=.78b31bd9-2793-4115-990d-1b107d33f174@github.com>

On Thu, 9 Dec 2021 18:31:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ReproducibleJar.java line 74:
> 
>> 72:     private static final File jarFileSourceDate1 = new File("JarEntryTimeSourceDate1.jar");
>> 73:     private static final File jarFileSourceDate2 = new File("JarEntryTimeSourceDate2.jar");
>> 74: 
> 
> Please consider using caps for your static final variable names

done

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

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

From aleonard at openjdk.java.net  Fri Dec 10 10:50:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:50:10 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v22]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <sVgLyPgaY_Tobx0udk4h1LV7tt4jBxXfIRmCAS3meMA=.24ef9f90-f91d-4c31-9d50-454e1a80bd19@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/436762f2..0add0d3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=20-21

  Stats: 220 lines in 2 files changed: 85 ins; 59 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From aleonard at openjdk.java.net  Fri Dec 10 10:50:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:50:12 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <v5z4o5JvJ8Qj3lLiUeeH9geGPtCAES_CsAjfeq5Kt64=.076c1739-cd98-456e-bf1b-b833f6394c4e@github.com>

On Thu, 9 Dec 2021 18:15:42 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ReproducibleJar.java line 114:
> 
>> 112:     }
>> 113: 
>> 114:     @Test
> 
> Please add a comment introducing the intent of the test.  As mentioned above, please consider using a DataProvider vs. an array with the test.

done

> test/jdk/tools/jar/ReproducibleJar.java line 286:
> 
>> 284: 
>> 285:     static void extractJar(File jarFile) throws Throwable {
>> 286:         String javahome = System.getProperty("java.home");
> 
> Please add a basic comment of the intent of the method.
> 
> Any reason you chose not to use JAR_TOOL here?

done

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

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

From aleonard at openjdk.java.net  Fri Dec 10 10:54:06 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 10:54:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v23]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <2dSgZb69ciJ32Mzkv0h59ixpcmtIW2yyjEEf0s6_nLQ=.c5258be2-b540-4479-9a9d-eb16731e87b1@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/0add0d3b..82e740e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=21-22

  Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From aleonard at openjdk.java.net  Fri Dec 10 11:20:25 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 11:20:25 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
Message-ID: <M7QiVKczNw7OFZ40CHoU9k_tskn2xuP9eo1vgFe_ZiI=.a98db2fe-a608-4cba-a07a-73d5e31ccf0a@github.com>

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR

@LanceAndersen thank you for the review comments, i've just done a new commit with them all done.. assuming all the tests run ok, i'll integrate

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

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

From lancea at openjdk.java.net  Fri Dec 10 11:56:21 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Dec 2021 11:56:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v23]
In-Reply-To: <2dSgZb69ciJ32Mzkv0h59ixpcmtIW2yyjEEf0s6_nLQ=.c5258be2-b540-4479-9a9d-eb16731e87b1@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2dSgZb69ciJ32Mzkv0h59ixpcmtIW2yyjEEf0s6_nLQ=.c5258be2-b540-4479-9a9d-eb16731e87b1@github.com>
Message-ID: <FbBSLvQyVpyGmHrB81eBHxTy59ZWOVYbguEPjJuoX4Y=.d6a792fa-c71d-43f9-bc2a-b77e58b1edda@github.com>

On Fri, 10 Dec 2021 10:54:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Hi Andrew,

Thank you for the changes.  This looks much much better.  Please see additional simplification comment below.

I kicked off a Mach5 run in the meantime

test/jdk/tools/jar/SourceDateDataProvider.java line 54:

> 52:                                };
> 53: 
> 54:     @DataProvider(name = "SourceDateData.valid")

This class file is really not needed as you can just add the DataProvider to ReproducableJar example:

 ```
  @DataProvider
    private Object[][] invalidSourceDates() {
        return new Object[][] {
                                 {"1976-06-24T01:02:03+00:00"},
                                  {"1980-01-01T00:00:01+00:00"},
                                  {"2100-01-01T00:00:00+00:00"},
                                  {"2138-02-18T00:00:00-11:00"},
                                  {"2006-04-06T12:38:00"},
                                  {"2012-08-24T16"}
        };
    }


And the Test will just use

`@Test(dataProvider= "invalidStourceDates")`

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

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

From aleonard at openjdk.java.net  Fri Dec 10 14:09:00 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 14:09:00 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v24]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <XtNyi47o_x1mbYwIIvPB3N7t1QHByWqfczOTIb4-Mr8=.c9e46ddf-bb29-4977-a0b0-9db285f693af@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/82e740e4..0a69d014

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=22-23

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

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

From aleonard at openjdk.java.net  Fri Dec 10 14:09:06 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 14:09:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v23]
In-Reply-To: <FbBSLvQyVpyGmHrB81eBHxTy59ZWOVYbguEPjJuoX4Y=.d6a792fa-c71d-43f9-bc2a-b77e58b1edda@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2dSgZb69ciJ32Mzkv0h59ixpcmtIW2yyjEEf0s6_nLQ=.c5258be2-b540-4479-9a9d-eb16731e87b1@github.com>
 <FbBSLvQyVpyGmHrB81eBHxTy59ZWOVYbguEPjJuoX4Y=.d6a792fa-c71d-43f9-bc2a-b77e58b1edda@github.com>
Message-ID: <vC05fdEw9dPBw7VEJXq8rkUYKJRwMeP6X0QyyJaOg-I=.8ba7235e-6829-4333-9619-529e6a55f749@github.com>

On Fri, 10 Dec 2021 11:51:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/SourceDateDataProvider.java line 54:
> 
>> 52:                                };
>> 53: 
>> 54:     @DataProvider(name = "SourceDateData.valid")
> 
> This class file is really not needed as you can just add the DataProvider to ReproducableJar example:
> 
>  ```
>   @DataProvider
>     private Object[][] invalidSourceDates() {
>         return new Object[][] {
>                                  {"1976-06-24T01:02:03+00:00"},
>                                   {"1980-01-01T00:00:01+00:00"},
>                                   {"2100-01-01T00:00:00+00:00"},
>                                   {"2138-02-18T00:00:00-11:00"},
>                                   {"2006-04-06T12:38:00"},
>                                   {"2012-08-24T16"}
>         };
>     }
> 
> 
> And the Test will just use
> 
> `@Test(dataProvider= "invalidStourceDates")`

Thanks Lance, that is simpler, i've changed it

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

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

From rkennke at openjdk.java.net  Fri Dec 10 14:39:12 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 10 Dec 2021 14:39:12 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v8]
In-Reply-To: <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
Message-ID: <0h2E2pbr5JNh0xhjUC9Ar7yJPIW7nr-dDK-j1S1nzoU=.9008811c-c58f-481b-97d3-e98b9988e625@github.com>

On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add improved test by @plevart

This should go to openjdk/jdk18 now, right? Can I simply push it there, or do I need to re-open a PR against jdk18?

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

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

From kcr at openjdk.java.net  Fri Dec 10 14:47:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Dec 2021 14:47:13 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v8]
In-Reply-To: <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
Message-ID: <VkKT9rjUZrBra9D5_hbFf-s4HyIenHYRFqH0bykuvqw=.8668a102-6b08-41a8-abb3-7b6e675f6b27@github.com>

On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add improved test by @plevart

This is a P4 bug. If the priority is correct, it does not meet the criteria to get it into JDK 18 during RDP1, as indicated in [JEP 3](https://openjdk.java.net/jeps/3).

If this is objectively a P3 bug, and really does need to go into JDK 18, then you will need to close this PR and open a new pull request in the jdk18 repo.

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

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

From rkennke at openjdk.java.net  Fri Dec 10 14:59:15 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 10 Dec 2021 14:59:15 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v8]
In-Reply-To: <VkKT9rjUZrBra9D5_hbFf-s4HyIenHYRFqH0bykuvqw=.8668a102-6b08-41a8-abb3-7b6e675f6b27@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
 <VkKT9rjUZrBra9D5_hbFf-s4HyIenHYRFqH0bykuvqw=.8668a102-6b08-41a8-abb3-7b6e675f6b27@github.com>
Message-ID: <zmIwYN0KK3Fd1lIcB93NCGumKMc1YFgWLQjRIh2S5CQ=.b7482a14-6feb-4983-bebe-34a9ae9b3bc4@github.com>

On Fri, 10 Dec 2021 14:44:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a P4 bug. If the priority is correct, it does not meet the criteria to get it into JDK 18 during RDP1, as indicated in [JEP 3](https://openjdk.java.net/jeps/3).
> 
> If this is objectively a P3 bug, and really does need to go into JDK 18, then you will need to close this PR and open a new pull request in the jdk18 repo.

Hmm, good question. It is kind-of leaking: current implementation prevents unloading of classes that are referenced from the OSC caches, unless memory pressure is high enough to trigger soft-ref-cleaning. Does it qualify for P3 ("Major loss of function."), or even P2 ("Crashes, loss of data, severe memory leak.")? We have users hitting this problem under different circumstances, I'd say it qualifies for P3. Opinions? See:

https://bugzilla.redhat.com/show_bug.cgi?id=2016930

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

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

From rriggs at openjdk.java.net  Fri Dec 10 15:11:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 10 Dec 2021 15:11:15 GMT
Subject: RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
 [v8]
In-Reply-To: <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
 <_QGt29Bb_ukC8oRpL3hH8Bo9nQZgBNfozeGNMu0JinM=.5131061a-b3b9-4aab-8199-ff1c771d15b9@github.com>
Message-ID: <19HFNyoHXDVjfTwljXrjoRsum79PQtuDVP3VGVUsOEM=.7875f3d6-30ad-49e5-82e6-ac2daaf204b5@github.com>

On Tue, 7 Dec 2021 10:42:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
>> 
>> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
>> 
>> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add improved test by @plevart

This fix hasn't had any bake-time and might have some effects that aren't immediately noticeable.
I'd leave it in 19 for the time being. It could be back ported at a later point in time.

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

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

From hseigel at openjdk.java.net  Fri Dec 10 15:11:36 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 10 Dec 2021 15:11:36 GMT
Subject: RFR: 8277481: Obsolete seldom used CDS flags
Message-ID: <zrerr71iEltsvVRPOBJDRI3TdrAldgGOIcyIAKiuP6o=.5c5e2eed-71f9-464e-92df-73fa0dfcebfc@github.com>

Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64.

The use of UseSharedSpaces in ps_core_common.c was tested on Mac OS x64 by temporarily removing serviceability/sa/ClhsdbPmap.java#core from the problem list.

Thanks! Harold

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

Commit messages:
 - fix typo
 - 8277481: Obsolete seldom used CDS flags

Changes: https://git.openjdk.java.net/jdk/pull/6800/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6800&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277481
  Stats: 151 lines in 13 files changed: 22 ins; 94 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6800/head:pull/6800

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

From rkennke at openjdk.java.net  Fri Dec 10 16:27:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 10 Dec 2021 16:27:19 GMT
Subject: Integrated: 8277072: ObjectStreamClass caches keep ClassLoaders alive
In-Reply-To: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
References: <T9NIYKvloXQLbgiW7haEM8MPRaDJmif3olgjWLeROHg=.b9ac8158-5a29-4b9d-86c7-d129f24f9474@github.com>
Message-ID: <17vG-esyewuQCBps50Nw6GKU3Rg0x-1bnoKvcZUgUcg=.a65d51a5-86ca-4d60-b4dc-224da2c0226c@github.com>

On Fri, 12 Nov 2021 21:43:42 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high.
> 
> However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches.
> 
> The proposed change is to use WeakReference instead of SoftReference for the values in caches.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

This pull request has now been integrated.

Changeset: 8eb453ba
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775
Stats:     496 lines in 4 files changed: 284 ins; 186 del; 26 mod

8277072: ObjectStreamClass caches keep ClassLoaders alive

Reviewed-by: rriggs, plevart

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

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

From rkennke at openjdk.java.net  Fri Dec 10 16:31:45 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 10 Dec 2021 16:31:45 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v2]
In-Reply-To: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
Message-ID: <KcrD9qJTdBGjYVyHE8sykT5ri-lfBU9YIfBW_SHDYBY=.20cebc5c-774b-4127-8c1b-6bfc52324ed7@github.com>

> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - 8278065: Refactor subclassAudits to use ClassValue
 - Remove unused EntryFuture inner class from ObjectSteamClass
 - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
 - Use ClassValue to solve JDK-8277072
 - Use ForceGC instead of System.gc()
 - Convert test to testng
 - Fix indentation of new testcase
 - 8277072: ObjectStreamClass caches keep ClassLoaders alive

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

Changes: https://git.openjdk.java.net/jdk/pull/6637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=01
  Stats: 431 lines in 4 files changed: 115 ins; 273 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637

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

From duke at openjdk.java.net  Fri Dec 10 16:31:46 2021
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Fri, 10 Dec 2021 16:31:46 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue
In-Reply-To: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
Message-ID: <UIS3j8ihfBpGhvj1ZIinqwJIt9rcNvqJTuE3DYWrLu0=.54d98801-ff97-450b-a92d-cc2b2b750d15@github.com>

On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout JDK-8277072
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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

From jjg at openjdk.java.net  Fri Dec 10 16:40:19 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 16:40:19 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

javac changes look good. I suggest adding this bug number to the test to check that URIs are not double-encoded.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/PathFileObject.java line 183:

> 181:         @Override @DefinedBy(Api.COMPILER)
> 182:         public URI toUri() {
> 183:             // Work around bug JDK-8134451:

Nice to see the workaround go.  
Find the test that was added at the time of the workaround, and add this bug number (8271079) to the `@bug` line in that test, to mark that test as relevant to this issue.

test/langtools/tools/javac/T8271079.java line 39:

> 37: import java.util.*;
> 38: import java.util.jar.JarEntry;
> 39: import javax.tools.*;

You could add an explicit `import java.util.spi.ToolProvider;` to remove the need for qualified names in the code

test/langtools/tools/javac/T8271079.java line 58:

> 56:             testT8271079(mr);
> 57:         } finally {
> 58:             Files.deleteIfExists(mr);

If you generate files in the test's current directory, it's not wrong to delete them but there's no need either, and you might be deleting useful debug evidence if the test fails.

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

Marked as reviewed by jjg (Reviewer).

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

From aleonard at openjdk.java.net  Fri Dec 10 17:05:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 17:05:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
Message-ID: <b4U1jhgrzL-Dba7sGrevAkjJj7xajqip_13yoq2NiaU=.dcaa10a0-44c8-4578-a0fb-9a29cbfc2634@github.com>

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR

@LanceAndersen let me know if mach5 looks good please, then I think we're good to go..

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

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

From kcr at openjdk.java.net  Fri Dec 10 17:24:20 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Dec 2021 17:24:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <b4U1jhgrzL-Dba7sGrevAkjJj7xajqip_13yoq2NiaU=.dcaa10a0-44c8-4578-a0fb-9a29cbfc2634@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
 <b4U1jhgrzL-Dba7sGrevAkjJj7xajqip_13yoq2NiaU=.dcaa10a0-44c8-4578-a0fb-9a29cbfc2634@github.com>
Message-ID: <38dQUziBliV4P32qVtaActBccwxUvW-WvFjLsPEdHcg=.3672c132-bba9-4bbf-b887-db852ffebad4@github.com>

On Fri, 10 Dec 2021 17:01:41 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR
>
> @LanceAndersen let me know if mach5 looks good please, then I think we're good to go..

@andrew-m-leonard if this enhancement is now intended to go into JDK 19, then you can simply integrate it into jdk mainline when it is ready. In that case, the fix version of the [CSR](https://bugs.openjdk.java.net/browse/JDK-8277755) should be adjusted to 19 to match.

If, however, you would still like to get it into JDK 18, you will need to make a late enhancement request per [JEP 3](https://openjdk.java.net/jeps/3), and then recreate this PR against the jdk18 stabilization repo.

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

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

From aleonard at openjdk.java.net  Fri Dec 10 17:29:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 17:29:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <38dQUziBliV4P32qVtaActBccwxUvW-WvFjLsPEdHcg=.3672c132-bba9-4bbf-b887-db852ffebad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
 <b4U1jhgrzL-Dba7sGrevAkjJj7xajqip_13yoq2NiaU=.dcaa10a0-44c8-4578-a0fb-9a29cbfc2634@github.com>
 <38dQUziBliV4P32qVtaActBccwxUvW-WvFjLsPEdHcg=.3672c132-bba9-4bbf-b887-db852ffebad4@github.com>
Message-ID: <AZYv3ojd1_NFrErmi72ZfHPYOkAPCwED_qpRzurLnR0=.f6b160ab-7cad-4795-8b3b-7045b665232b@github.com>

On Fri, 10 Dec 2021 17:20:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @LanceAndersen let me know if mach5 looks good please, then I think we're good to go..
>
> @andrew-m-leonard if this enhancement is now intended to go into JDK 19, then you can simply integrate it into jdk mainline when it is ready. In that case, the fix version of the [CSR](https://bugs.openjdk.java.net/browse/JDK-8277755) should be adjusted to 19 to match.
> 
> If, however, you would still like to get it into JDK 18, you will need to make a late enhancement request per [JEP 3](https://openjdk.java.net/jeps/3), and then recreate this PR against the jdk18 stabilization repo.

@kevinrushforth thanks Kevin, I had totally missed that RDP1 was yesterday! i'll have some thought on what's best, cheers

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

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

From aleonard at openjdk.java.net  Fri Dec 10 17:55:15 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 17:55:15 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <2UeRbW69wsb0He7mVbNf2f8qv1chx5wKv6zBJoQ45gI=.6e7ecffb-795c-4750-a7ad-472b9c208167@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <l8CsQJ1WwyqKris7jDJw_xTOk_wr5u81JrUwNqyLK4c=.25f95a47-137d-4806-8e11-f7f8b299949c@github.com>
 <2UeRbW69wsb0He7mVbNf2f8qv1chx5wKv6zBJoQ45gI=.6e7ecffb-795c-4750-a7ad-472b9c208167@github.com>
Message-ID: <gB4gJ7ppedjHm18hTxE1KncSWTOFvPlX_TCOAE8kyco=.26ce04ad-a314-4f25-8064-647ea7ffd5e3@github.com>

On Tue, 7 Dec 2021 19:06:17 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Thanks, CSR now Finalized
>
>> Thanks, CSR now Finalized
> 
> Just a minor note: the CSR uses the adjective "extended" in three places for the DOS date and time field, but that field is actually a part of the original ZIP specification and not in an extended field. This implementation make a point never to touch the "Extended Timestamp Extra Field" defined in the 1997 [Info-ZIP Application Note 970311][1].
> 
> Maybe the confusion was from the required ISO 8601 extended format (rather than basic).
> 
> [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/zip/ZipEntry.html#setExtra(byte%5B%5D)

@jgneff John, I know you have an interest in this, what is your urgency for this support? jdk-18 or 19 ?

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

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

From jwilhelm at openjdk.java.net  Fri Dec 10 18:13:18 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 10 Dec 2021 18:13:18 GMT
Subject: RFR: Merge jdk18
Message-ID: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8277621: ARM32: multiple fastdebug failures with "bad AD file" after JDK-8276162
 - 8278538: Test langtools/jdk/javadoc/tool/CheckManPageOptions.java fails after the manpage was updated
 - 8273179: Update nroff pages in JDK 18 before RC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/6802/files
  Stats: 1142 lines in 30 files changed: 688 ins; 155 del; 299 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6802/head:pull/6802

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

From erikj at openjdk.java.net  Fri Dec 10 18:14:17 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 10 Dec 2021 18:14:17 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v2]
In-Reply-To: <KcrD9qJTdBGjYVyHE8sykT5ri-lfBU9YIfBW_SHDYBY=.20cebc5c-774b-4127-8c1b-6bfc52324ed7@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
 <KcrD9qJTdBGjYVyHE8sykT5ri-lfBU9YIfBW_SHDYBY=.20cebc5c-774b-4127-8c1b-6bfc52324ed7@github.com>
Message-ID: <tucLdHZEDuk0zORzIRdIiR4sWniV8QEiJ4r785X6BRg=.1c11f4dd-f3ef-4ea9-8ae5-aa4dfbb2f950@github.com>

On Fri, 10 Dec 2021 16:31:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [ ] tier3
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - 8278065: Refactor subclassAudits to use ClassValue
>  - Remove unused EntryFuture inner class from ObjectSteamClass
>  - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
>  - Use ClassValue to solve JDK-8277072
>  - Use ForceGC instead of System.gc()
>  - Convert test to testng
>  - Fix indentation of new testcase
>  - 8277072: ObjectStreamClass caches keep ClassLoaders alive

Skara is failing to run jcheck on this PR. I think this is ultimately a bug in Skara, that gets tickled by your source branch being quite far behind jdk:master, in combination with 62a7f5d3236ab2248518a475b1d8b71cb4bf1313 recently going in. If you merge jdk:master into your branch, I believe this will resolve itself for now.

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

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

From jwilhelm at openjdk.java.net  Fri Dec 10 18:46:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 10 Dec 2021 18:46:17 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>
References: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>
Message-ID: <kpQxjDOAP8oYJSlDDnHI_tQ-TqySIEgCecB0KZHOhlQ=.5b2f94bd-fbc6-4852-adbc-f0e5819b9f4a@github.com>

On Fri, 10 Dec 2021 17:51:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 61736f81
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61736f81fb4a20375c83d59e2b37a00aafb11107
Stats:     1142 lines in 30 files changed: 688 ins; 155 del; 299 mod

Merge

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

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

From erikj at openjdk.java.net  Fri Dec 10 18:54:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 10 Dec 2021 18:54:15 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v2]
In-Reply-To: <KcrD9qJTdBGjYVyHE8sykT5ri-lfBU9YIfBW_SHDYBY=.20cebc5c-774b-4127-8c1b-6bfc52324ed7@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
 <KcrD9qJTdBGjYVyHE8sykT5ri-lfBU9YIfBW_SHDYBY=.20cebc5c-774b-4127-8c1b-6bfc52324ed7@github.com>
Message-ID: <-VBBWC8lIDbFgIqhwjfEOESkUnzLXMZbWHiAXaICvuM=.a54730f9-f49e-4a6a-a73b-58b5bd6c05b8@github.com>

On Fri, 10 Dec 2021 16:31:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [ ] tier3
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - 8278065: Refactor subclassAudits to use ClassValue
>  - Remove unused EntryFuture inner class from ObjectSteamClass
>  - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
>  - Use ClassValue to solve JDK-8277072
>  - Use ForceGC instead of System.gc()
>  - Convert test to testng
>  - Fix indentation of new testcase
>  - 8277072: ObjectStreamClass caches keep ClassLoaders alive

> Skara is failing to run jcheck on this PR. I think this is ultimately a bug in Skara, that gets tickled by your source branch being quite far behind jdk:master, in combination with [62a7f5d](https://github.com/openjdk/jdk/commit/62a7f5d3236ab2248518a475b1d8b71cb4bf1313) recently going in. If you merge jdk:master into your branch, I believe this will resolve itself for now.

I've investigated further and filed https://bugs.openjdk.java.net/browse/SKARA-1281. Once fixed you would get an error message in this PR telling you to rebase your source branch.

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

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

From jgneff at openjdk.java.net  Fri Dec 10 19:20:19 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Fri, 10 Dec 2021 19:20:19 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <2UeRbW69wsb0He7mVbNf2f8qv1chx5wKv6zBJoQ45gI=.6e7ecffb-795c-4750-a7ad-472b9c208167@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <l8CsQJ1WwyqKris7jDJw_xTOk_wr5u81JrUwNqyLK4c=.25f95a47-137d-4806-8e11-f7f8b299949c@github.com>
 <2UeRbW69wsb0He7mVbNf2f8qv1chx5wKv6zBJoQ45gI=.6e7ecffb-795c-4750-a7ad-472b9c208167@github.com>
Message-ID: <cebAy-tSMK7pFfaTm6T4UkRyQ5N-REHLm2SAKUg9VfE=.32f543c7-d66d-4331-ad81-0172a4bb2003@github.com>

On Tue, 7 Dec 2021 19:06:17 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Thanks, CSR now Finalized
>
>> Thanks, CSR now Finalized
> 
> Just a minor note: the CSR uses the adjective "extended" in three places for the DOS date and time field, but that field is actually a part of the original ZIP specification and not in an extended field. This implementation make a point never to touch the "Extended Timestamp Extra Field" defined in the 1997 [Info-ZIP Application Note 970311][1].
> 
> Maybe the confusion was from the required ISO 8601 extended format (rather than basic).
> 
> [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/zip/ZipEntry.html#setExtra(byte%5B%5D)

> @jgneff John, I know you have an interest in this, what is your urgency for this support? jdk-18 or 19 ?

It's not urgent. I'm just being impatient. ??

If this pull request is integrated only into JDK 19, JavaFX won't be able to support reproducible builds until OpenJFX 20 in March 2023. Java projects in general are late to the reproducible builds party. Debian, for example, builds 31,571 packages and [less than three percent fail][1] to build in a reproducible manner. Those failing packages include OpenJDK and OpenJFX. Debian plans eventually to make [reproducibility a requirement][2], and other distributions may follow.

The only true urgency, of course, is to provide Java project owners better tools to detect the next supply chain attack on the packages they distribute.

[1]: https://tests.reproducible-builds.org/debian/bookworm/index_suite_amd64_stats.html
[2]: https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility

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

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

From lancea at openjdk.java.net  Fri Dec 10 19:43:10 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Dec 2021 19:43:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <UQGqcGXJ1oeevmfXCyYhpLF2BaKamhhfxM77M9gIwbw=.c278d9f1-ade9-4281-aee4-3d5758675a53@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

The changes look good.

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

Marked as reviewed by lancea (Reviewer).

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

From lancea at openjdk.java.net  Fri Dec 10 19:44:23 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Dec 2021 19:44:23 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
Message-ID: <txzrdPiJ4m3GxdDZ1vw1DPwy8ssCVKK24Jz136mNSwU=.12f0c785-ccf3-4c00-8ae0-b662923eb580@github.com>

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR

> @LanceAndersen let me know if mach5 looks good please, then I think we're good to go..

As soon as  the Mach5 finishes, I will let you know

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

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

From aleonard at openjdk.java.net  Fri Dec 10 20:30:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 20:30:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <cebAy-tSMK7pFfaTm6T4UkRyQ5N-REHLm2SAKUg9VfE=.32f543c7-d66d-4331-ad81-0172a4bb2003@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <l8CsQJ1WwyqKris7jDJw_xTOk_wr5u81JrUwNqyLK4c=.25f95a47-137d-4806-8e11-f7f8b299949c@github.com>
 <2UeRbW69wsb0He7mVbNf2f8qv1chx5wKv6zBJoQ45gI=.6e7ecffb-795c-4750-a7ad-472b9c208167@github.com>
 <cebAy-tSMK7pFfaTm6T4UkRyQ5N-REHLm2SAKUg9VfE=.32f543c7-d66d-4331-ad81-0172a4bb2003@github.com>
Message-ID: <SpjfMBA05Zm5F-SYkaJAE_DqYwMbPR1L3iEfgx6zIJA=.617469ce-0343-424a-b20e-8431c9373737@github.com>

On Fri, 10 Dec 2021 19:16:49 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> Thanks, CSR now Finalized
>> 
>> Just a minor note: the CSR uses the adjective "extended" in three places for the DOS date and time field, but that field is actually a part of the original ZIP specification and not in an extended field. This implementation make a point never to touch the "Extended Timestamp Extra Field" defined in the 1997 [Info-ZIP Application Note 970311][1].
>> 
>> Maybe the confusion was from the required ISO 8601 extended format (rather than basic).
>> 
>> [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/zip/ZipEntry.html#setExtra(byte%5B%5D)
>
>> @jgneff John, I know you have an interest in this, what is your urgency for this support? jdk-18 or 19 ?
> 
> It's not urgent. I'm just being impatient. ??
> 
> If this pull request is integrated only into JDK 19, JavaFX won't be able to support reproducible builds until OpenJFX 20 in March 2023. Java projects in general are late to the reproducible builds party. Debian, for example, builds 31,571 packages and [less than three percent fail][1] to build in a reproducible manner. Those failing packages include OpenJDK and OpenJFX. Debian plans eventually to make [reproducibility a requirement][2], and other distributions may follow.
> 
> The only true urgency, of course, is to provide Java project owners better tools to detect the next supply chain attack on the packages they distribute.
> 
> [1]: https://tests.reproducible-builds.org/debian/bookworm/index_suite_amd64_stats.html
> [2]: https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility

@jgneff thanks John, i'm going to raise the JEP 3 request and see where I get, as I concur with your statement:

> The only true urgency, of course, is to provide Java project owners better tools to detect the next supply chain attack on the packages they distribute.

The risk is minimal, also given the extensive testing we have done.

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

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

From aleonard at openjdk.java.net  Fri Dec 10 20:54:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 20:54:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <38dQUziBliV4P32qVtaActBccwxUvW-WvFjLsPEdHcg=.3672c132-bba9-4bbf-b887-db852ffebad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
 <b4U1jhgrzL-Dba7sGrevAkjJj7xajqip_13yoq2NiaU=.dcaa10a0-44c8-4578-a0fb-9a29cbfc2634@github.com>
 <38dQUziBliV4P32qVtaActBccwxUvW-WvFjLsPEdHcg=.3672c132-bba9-4bbf-b887-db852ffebad4@github.com>
Message-ID: <LUL4a0s91dDKr8Oz4CncPBoofPQPYf-gmDS685ABH9s=.b5416fa6-17ac-4391-b916-d391fd2743a9@github.com>

On Fri, 10 Dec 2021 17:20:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @LanceAndersen let me know if mach5 looks good please, then I think we're good to go..
>
> @andrew-m-leonard if this enhancement is now intended to go into JDK 19, then you can simply integrate it into jdk mainline when it is ready. In that case, the fix version of the [CSR](https://bugs.openjdk.java.net/browse/JDK-8277755) should be adjusted to 19 to match.
> 
> If, however, you would still like to get it into JDK 18, you will need to make a late enhancement request per [JEP 3](https://openjdk.java.net/jeps/3), and then recreate this PR against the jdk18 stabilization repo.

@kevinrushforth fyi: https://bugs.openjdk.java.net/issues/?filter=33407

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

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

From rkennke at openjdk.java.net  Fri Dec 10 21:07:37 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 10 Dec 2021 21:07:37 GMT
Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v3]
In-Reply-To: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
References: <vV6TMGprgPSPrzrhtiLtmwtB4GY2f2PVNu1GczgEJzA=.8d7f49e1-4bb5-4d94-9129-e3d7e56cc284@github.com>
Message-ID: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com>

> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

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

 - Merge branch 'master' into JDK-8278065
 - 8278065: Refactor subclassAudits to use ClassValue
 - Remove unused EntryFuture inner class from ObjectSteamClass
 - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072
 - Use ClassValue to solve JDK-8277072
 - Use ForceGC instead of System.gc()
 - Convert test to testng
 - Fix indentation of new testcase
 - 8277072: ObjectStreamClass caches keep ClassLoaders alive

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

Changes: https://git.openjdk.java.net/jdk/pull/6637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=02
  Stats: 105 lines in 3 files changed: 2 ins; 87 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637

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

From aleonard at openjdk.java.net  Fri Dec 10 21:10:56 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 10 Dec 2021 21:10:56 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v25]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <iwTR2yXAkNWaTpseSqkxVwPZJ4AR9nJxcg7Vz0cQpTU=.dbc77db2-1a34-4c46-b229-ce5e1e391fc2@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/0a69d014..f99fc418

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=23-24

  Stats: 96 lines in 1 file changed: 4 ins; 5 del; 87 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

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

From kcr at openjdk.java.net  Fri Dec 10 21:23:18 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 10 Dec 2021 21:23:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <QPzt4WMTT0tj-3ZnN_-w5sBB5--rBU85ruypu9tMAyo=.cbb1baaa-36c2-4a86-8823-3fd52efcdef6@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>
 <QPzt4WMTT0tj-3ZnN_-w5sBB5--rBU85ruypu9tMAyo=.cbb1baaa-36c2-4a86-8823-3fd52efcdef6@github.com>
Message-ID: <gZh3iLekZrFfLorpgC-ffHH8ooW0AWnmk8I6BAsolM8=.78d2c1fb-66f4-4bc5-a1e1-d698e2c84c19@github.com>

On Tue, 7 Dec 2021 13:27:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
>> thanks
>
>> @jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
>> thanks
> 
> For the CSR then you need to press "Finalize".

@AlanBateman will need to review your request.

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

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

From iklam at openjdk.java.net  Sat Dec 11 01:55:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 11 Dec 2021 01:55:50 GMT
Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime
 [v3]
In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com>
References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com>
Message-ID: <pOfPrnVSbe4SOyUeCaTXl-2dzck0EeSCa1fuarocajo=.22176dfa-d283-4891-a91d-48aae98fce09@github.com>

> **Background:**
> 
> In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this:
> 
> 
> public enum Day {  SUNDAY, MONDAY ... } 
> 
> 
> to
> 
> 
> public class Day extends java.lang.Enum {
>     public static final SUNDAY = new Day("SUNDAY");
>     public static final MONDAY = new Day("MONDAY"); ...
> }
> 
> 
> With CDS archived heap objects, `Day::<clinit>` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
> 
> **Fix:**
> 
> During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::<clinit>`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time.
> 
> This is safe as we know that `X::<clinit>` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized.
> 
> **Verification:**
> 
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
> 
> **Testing:**
> 
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.

Ioi Lam 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 branch 'master' into 8275731-heapshared-enum
 - added exclusions needed by "java -Xshare:dump -ea -esa"
 - Comments from @calvinccheung off-line
 - 8275731: CDS archived enums objects are recreated at runtime

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6653/files
  - new: https://git.openjdk.java.net/jdk/pull/6653/files/df0d3f88..6e160057

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

  Stats: 24204 lines in 951 files changed: 16523 ins; 3176 del; 4505 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653

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

From cstein at openjdk.java.net  Sat Dec 11 11:03:10 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:03:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <G_aFz6mh1ayER5hBYHF0TfGIzbxsM5rWNLMXYVRiwh0=.454b37ff-61bc-44be-bb81-4f03ff34c587@github.com>

On Fri, 10 Dec 2021 16:30:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T8271079.java line 39:
> 
>> 37: import java.util.*;
>> 38: import java.util.jar.JarEntry;
>> 39: import javax.tools.*;
> 
> You could add an explicit `import java.util.spi.ToolProvider;` to remove the need for qualified names in the code

Such an import would break line 80: `ToolProvider.getSystemJavaCompiler()` as this one refers to `ToolProvider` in package `javax.tools`.

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:22:10 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:22:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <DAlY1wqdJT-CVVzzsNP_wd73KMkl4ARJf-wguUlxHM8=.47357498-551d-40cd-942a-2ed847a10abf@github.com>

On Fri, 10 Dec 2021 16:37:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> javac changes look good. I suggest adding this bug number to the test to check that URIs are not double-encoded.

I can't find [`8134451`](https://bugs.openjdk.java.net/browse/JDK-8134451) as noted in the now removed comment directly in an existing test, but [`8131067`](https://bugs.openjdk.java.net/browse/JDK-8131067) can be found in `ZipFSTester.java`: https://github.com/openjdk/jdk/blob/6eb6ec05fd4f80e11d0b052b58190bc8b53f4b11/test/jdk/jdk/nio/zipfs/ZipFSTester.java#L666

Thus, I'll add [`8271079`](https://bugs.openjdk.java.net/browse/JDK-8271079) to the already long list in `ZipFSTester.java`. https://github.com/openjdk/jdk/blob/6eb6ec05fd4f80e11d0b052b58190bc8b53f4b11/test/jdk/jdk/nio/zipfs/ZipFSTester.java#L74-L76

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:29:50 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:29:50 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

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

  Add bug number `8271079` to ZipFS tester

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6768/files
  - new: https://git.openjdk.java.net/jdk/pull/6768/files/12e106c6..353cbd5d

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

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:29:53 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:29:53 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <-b8VPS5N4zJA2_uSs6f27yStd73jWoz3GE7aEOc3tVg=.c2a7273c-421e-44be-ac59-211039d9d9db@github.com>

On Fri, 10 Dec 2021 16:33:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T8271079.java line 58:
> 
>> 56:             testT8271079(mr);
>> 57:         } finally {
>> 58:             Files.deleteIfExists(mr);
> 
> If you generate files in the test's current directory, it's not wrong to delete them but there's no need either, and you might be deleting useful debug evidence if the test fails.

Understood.

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

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

From lancea at openjdk.java.net  Sat Dec 11 12:01:18 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 11 Dec 2021 12:01:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v24]
In-Reply-To: <XtNyi47o_x1mbYwIIvPB3N7t1QHByWqfczOTIb4-Mr8=.c9e46ddf-bb29-4977-a0b0-9db285f693af@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <XtNyi47o_x1mbYwIIvPB3N7t1QHByWqfczOTIb4-Mr8=.c9e46ddf-bb29-4977-a0b0-9db285f693af@github.com>
Message-ID: <w2DJvibUgUWlukk_jnZEniJ196UJXnXg0wyxRORuXG8=.da473c3d-d4ae-4f18-ae1a-80349cb49f51@github.com>

On Fri, 10 Dec 2021 14:09:00 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276766: Enable jar and jmod to produce deterministic timestamped content
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Hi Andrew,

The latest Mach5 runs remain clean and the updates look good so you are good to integrate when you are ready!

test/jdk/tools/jar/ReproducibleJar.java line 43:

> 41: import java.nio.file.Files;
> 42: import java.nio.file.attribute.FileTime;
> 43: import java.util.Arrays;

This can be removed I believe

test/jdk/tools/jar/ReproducibleJar.java line 113:

> 111: 
> 112:     @AfterMethod
> 113:     public void runAfter() throws Throwable {

throws clause is not needed

test/jdk/tools/jar/ReproducibleJar.java line 160:

> 158:       */
> 159:     @Test(dataProvider = "invalidSourceDates")
> 160:     public void testInvalidSourceDate(String sourceDate) throws Throwable {

throws clause is not needed

test/jdk/tools/jar/ReproducibleJar.java line 281:

> 279:       * Remove the directory and its contents
> 280:       */
> 281:     static boolean cleanup(File dir) throws Throwable {

The return type is not used and the throws clause can be removed

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

Marked as reviewed by lancea (Reviewer).

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

From aleonard at openjdk.java.net  Sat Dec 11 15:30:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Sat, 11 Dec 2021 15:30:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v24]
In-Reply-To: <w2DJvibUgUWlukk_jnZEniJ196UJXnXg0wyxRORuXG8=.da473c3d-d4ae-4f18-ae1a-80349cb49f51@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <XtNyi47o_x1mbYwIIvPB3N7t1QHByWqfczOTIb4-Mr8=.c9e46ddf-bb29-4977-a0b0-9db285f693af@github.com>
 <w2DJvibUgUWlukk_jnZEniJ196UJXnXg0wyxRORuXG8=.da473c3d-d4ae-4f18-ae1a-80349cb49f51@github.com>
Message-ID: <MhNkE-r7KXu1A5AkC2THJ9brDdSCtBcDUp2v03n_5YE=.4bbfe9d0-9b62-46e9-81cd-322813319d12@github.com>

On Sat, 11 Dec 2021 11:57:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Andrew,
> 
> The latest Mach5 runs remain clean and the updates look good so you are good to integrate when you are ready!

Thank you @LanceAndersen

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

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

From aleonard at openjdk.java.net  Sat Dec 11 15:30:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Sat, 11 Dec 2021 15:30:23 GMT
Subject: Integrated: 8276766: Enable jar and jmod to produce deterministic
 timestamped content
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <PdiTzJVqb7IkeO00asdOQ25byVi4pGsiBITWrot_vFo=.7eef7ccb-fdf1-4c52-a40b-fedbb4dae330@github.com>

On Fri, 19 Nov 2021 16:52:36 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: db68a0ce
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/db68a0ce1ce152345320e70acb7e9842d2f1ece4
Stats:     480 lines in 8 files changed: 458 ins; 0 del; 22 mod

8276766: Enable jar and jmod to produce deterministic timestamped content

Reviewed-by: ihse, lancea, alanb, jgneff

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

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

From jjg at openjdk.java.net  Sat Dec 11 16:36:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 11 Dec 2021 16:36:14 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
Message-ID: <JhwlaigpD5wQf7JYJ773wooqu0aX2T8omC_pxDEzjlw=.06d74422-ed6a-4a22-8692-8a6246dcd3fc@github.com>

On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number `8271079` to ZipFS tester

Regarding the javac workaround, as best I can tell, the `createJarUri` code goes all the way back to the original file manager code in JDK 6.  The workaround comment appeared in JDK 9, as part of the general conversion from the old File-based file manager to the new Path-based file manager.  So yes, there does not appear to be a specific test for the workaround, and it's not clear it's worth bisecting the changes in the transition from JDK 8 to JDK 9 to investigate further.

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

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

From duke at openjdk.java.net  Sun Dec 12 14:46:19 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 12 Dec 2021 14:46:19 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <AzPA2qM90ShR-IUuw_JvxC59xjHVO7VoxC2PEufDp_Q=.57e94bab-7095-4564-a10e-e34bfc191ac1@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
 <AzPA2qM90ShR-IUuw_JvxC59xjHVO7VoxC2PEufDp_Q=.57e94bab-7095-4564-a10e-e34bfc191ac1@github.com>
Message-ID: <aQuL0yGPHHgo_19E32p43nPiusZ6Il2W9XJt-ZOyIm4=.737dc841-a8a8-4163-b927-8066c8ae9225@github.com>

On Mon, 6 Dec 2021 07:07:03 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Draft: Eliminated duplicate code using lambda expressions
>>  - Draft: Use blocking mode also for target channel
>
> Please keep this PR open. More commits will follow on the next weeks.

> Looks promising, keep moving, @mkarg !

Thanks a lot, Laurent! I really appreciate! In fact, most of the work is going on in spin-off PRs, and some of it already is merged, as I explained on [Twitter](https://twitter.com/mkarg/status/1467064781978931206?s=20) and [Youtube](https://youtu.be/9Rjz3zRXoD4). :-)

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

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

From lbourges at openjdk.java.net  Sun Dec 12 18:20:16 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 12 Dec 2021 18:20:16 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v10]
In-Reply-To: <UusVxCw9X1UYx86n7K98taTQcvzwFs5CV_HI9XInYaY=.3e8b7731-1bff-486c-9fe6-af4bdebde64c@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <UusVxCw9X1UYx86n7K98taTQcvzwFs5CV_HI9XInYaY=.3e8b7731-1bff-486c-9fe6-af4bdebde64c@github.com>
Message-ID: <U9_YkKzPjsqYxgWv0ZQb42IxnGrss59rFWDaDZJQKdg=.c7f0f356-e79b-4fd4-89cb-359022dbec79@github.com>

On Mon, 29 Nov 2021 21:16:32 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Updated javadoc
>   * Optimized insertion sort threshold
>   * Refactored parallel sorting section
>   * Improved step for pivot candidates
>   * Changed condition for Radix sort

Vladimir,
I updated the benchmarking code and here are the complete test results: system vs dpqs 21.5 vs 21.11:
https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/sort-bench/results/2021/2021-12-final/DPQS-sort-1k-1M-stats.out

Full results:
https://github.com/bourgesl/nearly-optimal-mergesort-code/blob/master/sort-bench/results/2021/2021-12-final/sort-1k-1M-stats.out

All good, on 1k, 10k, 100k, 1m integer arrays.
Congratulations
??

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

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

From dholmes at openjdk.java.net  Mon Dec 13 04:32:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 04:32:42 GMT
Subject: [jdk18] RFR: 8132785:
 java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently
Message-ID: <VQSR9hudhR7tcSfstGK817Jdf9hHAj5W2hAdoITjVKw=.533ee924-6fc8-4fd9-b3a7-2e1d0696dfa5@github.com>

Investigation showed this test was experiencing interference from threads created by other tests in agentvm mode. The simple solution is to run this test isolated using othervm mode. Also added some diagnostics to the test incase we see future failures.

Testing: local and tier3.

Thanks,
David

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

Commit messages:
 - Fixed tab character
 - 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently

Changes: https://git.openjdk.java.net/jdk18/pull/14/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=14&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8132785
  Stats: 23 lines in 2 files changed: 20 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/14.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/14/head:pull/14

PR: https://git.openjdk.java.net/jdk18/pull/14

From alanb at openjdk.java.net  Mon Dec 13 07:27:16 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 13 Dec 2021 07:27:16 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
Message-ID: <gh-ORVM4yjODPzU9L_n8GxzY98J7QR3PtHpm1BEhT0s=.83c1da98-8c34-4863-b42e-bced4edc5517@github.com>

On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number `8271079` to ZipFS tester

I'll leave Jon or Lance to sponsor this.

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

Marked as reviewed by alanb (Reviewer).

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

From duke at openjdk.java.net  Mon Dec 13 09:47:36 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 13 Dec 2021 09:47:36 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() misses bounds check
 elimination
Message-ID: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>

Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor

It looks like in the following code in `String(byte[], int, int, Charset)`

while (offset < sl) {
    int b1 = bytes[offset];
    if (b1 >= 0) {
        dst[dp++] = (byte)b1;
        offset++;                                  // <---
        continue;
    }
    if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
            offset + 1 < sl) {
        int b2 = bytes[offset + 1];
        if (!isNotContinuation(b2)) {
            dst[dp++] = (byte)decode2(b1, b2);
            offset += 2;
            continue;
        }
    }
    // anything not a latin1, including the repl
    // we have to go with the utf16
    break;
}

bounds check elimination is not executed when accessing byte array via `bytes[offset].

The reason, I guess, is that offset variable is modified within the loop (marked with arrow).

Possible fix for this could be changing:

`while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`

However the best is to invest in C2 optimization to handle all such cases.

The following benchmark demonstrates good improvement:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class StringConstructorBenchmark {
  private byte[] array;
  private String str;

  @Setup
  public void setup() {
    str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
    array = str.getBytes(StandardCharsets.UTF_8);
  }

  @Benchmark
  public String newString()  {
      return new String(array, 0, array.length, StandardCharsets.UTF_8);
  }

  @Benchmark
  public String translateEscapes()  {
      return str.translateEscapes();
  }
}

Results:

//baseline
Benchmark Mode Cnt Score Error Units
StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op

//patched
Benchmark Mode Cnt Score Error Units
StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op

The same is observed in String.translateEscapes() for the same String as in the benchmark above:

//baseline
Benchmark Mode Cnt Score Error Units
StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op

//patched
Benchmark Mode Cnt Score Error Units
StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op

Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.

Here's the part of baseline assembly responsible for `while` loop: 

  3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
  2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
  2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
                  ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
  2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
                   ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                   ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
  3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
                   ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
  2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
  2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
  2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
  3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
  2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
  2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
  2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
  3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
  2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
  2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
  2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
                   ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
  3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
                   ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
  2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
                   ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
  2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
  2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                   ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
  3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
  2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                   ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
  2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
                   ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
                               ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)

and this one is for patched code:

 17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
                  ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
  0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
                   ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
  0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
                   ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
  0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
 13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
  0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
  0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
  0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
  0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
 12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
  0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
  0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                   ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
  0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
  0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}

Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.

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

Commit messages:
 - 8278518: String(byte[], int, int, Charset) constructor misses bounds check elimination

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

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

From alanb at openjdk.java.net  Mon Dec 13 09:59:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 13 Dec 2021 09:59:15 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() misses bounds check
 elimination
In-Reply-To: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
Message-ID: <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>

On Mon, 13 Dec 2021 09:39:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor

Before anyone looks at this, can you confirm that the patch does not include any code or tests/benchmarks that were taken from SO?

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

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

From duke at openjdk.java.net  Mon Dec 13 10:08:13 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 13 Dec 2021 10:08:13 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() misses bounds check
 elimination
In-Reply-To: <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
Message-ID: <8Yn2a08zp__uiDGoxo-NBpiUjZeLGUEk2OKIlXgOyjg=.2b319262-7730-4ec3-8f26-de8a8c692c76@github.com>

On Mon, 13 Dec 2021 09:55:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>> 
>> It looks like in the following code in `String(byte[], int, int, Charset)`
>> 
>> while (offset < sl) {
>>     int b1 = bytes[offset];
>>     if (b1 >= 0) {
>>         dst[dp++] = (byte)b1;
>>         offset++;                                  // <---
>>         continue;
>>     }
>>     if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
>>             offset + 1 < sl) {
>>         int b2 = bytes[offset + 1];
>>         if (!isNotContinuation(b2)) {
>>             dst[dp++] = (byte)decode2(b1, b2);
>>             offset += 2;
>>             continue;
>>         }
>>     }
>>     // anything not a latin1, including the repl
>>     // we have to go with the utf16
>>     break;
>> }
>> 
>> bounds check elimination is not executed when accessing byte array via `bytes[offset].
>> 
>> The reason, I guess, is that offset variable is modified within the loop (marked with arrow).
>> 
>> Possible fix for this could be changing:
>> 
>> `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`
>> 
>> However the best is to invest in C2 optimization to handle all such cases.
>> 
>> The following benchmark demonstrates good improvement:
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class StringConstructorBenchmark {
>>   private byte[] array;
>>   private String str;
>> 
>>   @Setup
>>   public void setup() {
>>     str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
>>     array = str.getBytes(StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String newString()  {
>>       return new String(array, 0, array.length, StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String translateEscapes()  {
>>       return str.translateEscapes();
>>   }
>> }
>> 
>> Results:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op
>> 
>> The same is observed in String.translateEscapes() for the same String as in the benchmark above:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op
>> 
>> Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.
>> 
>> Here's the part of baseline assembly responsible for `while` loop: 
>> 
>>   3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
>>   2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
>>   2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
>>                    ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
>>   3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
>>                    ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
>>   2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
>>   2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
>>   2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
>>   3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
>>   2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
>>   2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
>>   2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
>>   3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
>>   2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
>>   2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
>>   2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
>>                    ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
>>   3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
>>   2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
>>   2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
>>   2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
>>   3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
>>   2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
>>   2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
>>                    ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                                ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)
>> 
>> and this one is for patched code:
>> 
>>  17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
>>                    ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
>>   0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
>>                    ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
>>   0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
>>  13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
>>   0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
>>   0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
>>   0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
>>   0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
>>  12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
>>   0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
>>   0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
>>   0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
>>   0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>> 
>> Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.
>
>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
> 
> Before anyone looks at this, can you confirm that the patch does not include any code or tests/benchmarks that were taken from SO?

@AlanBateman the benchmark is mine along with the changes for `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is from SO.

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

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

From cstein at openjdk.java.net  Mon Dec 13 12:03:21 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 13 Dec 2021 12:03:21 GMT
Subject: Integrated: 8271079: JavaFileObject#toUri and multi-release jars
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <hgty71zmDQCH7Ew3uYzGuZcVfiP8MKNm2eSrdAlfpck=.e814995a-c860-4cfd-b56d-bf9e07bc96e4@github.com>

On Wed, 8 Dec 2021 15:26:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

This pull request has now been integrated.

Changeset: 23fd9f15
Author:    Christian Stein <cstein at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23fd9f15da40cef00231380766158bc0fa537c38
Stats:     198 lines in 6 files changed: 177 ins; 18 del; 3 mod

8271079: JavaFileObject#toUri and multi-release jars

Reviewed-by: jjg, lancea, alanb

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

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

From rriggs at openjdk.java.net  Mon Dec 13 19:11:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 13 Dec 2021 19:11:12 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <Ls7C1bPBzJZa8vwz5FZEuSODWcYoQETlIdhyu5pQaew=.ed156553-2284-4dfa-9eab-8e9162d7a416@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Can another reviewer take a look at this?  Thanks

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

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

From mchung at openjdk.java.net  Mon Dec 13 19:17:15 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 13 Dec 2021 19:17:15 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <f93hCeC6zF4FbBaDdoKDYKVQ3Hokd_bTTFDCX3xd9_U=.21c7546b-7e83-4639-b68c-b856751fa1b8@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Looks okay to me.

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

Marked as reviewed by mchung (Reviewer).

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

From naoto at openjdk.java.net  Mon Dec 13 19:22:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 13 Dec 2021 19:22:15 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <uxy-LBLE6w7tDiUcqM1SYLVPNCajMSeCijHvDIQNtq8=.1b52596a-0232-454d-a2b3-15e1e38713f3@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

LGTM. Nit: Some of the files need copyright year updates.

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

Marked as reviewed by naoto (Reviewer).

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

From lancea at openjdk.java.net  Mon Dec 13 20:32:22 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 13 Dec 2021 20:32:22 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <xiZX1XGf86fQXiJHBbuA_x8Sfw1mvdjf9ZQSPWEB6fs=.012a3461-0f30-4817-b5f5-a955db2266f3@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Marked as reviewed by lancea (Reviewer).

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

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

From rriggs at openjdk.java.net  Mon Dec 13 20:58:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 13 Dec 2021 20:58:50 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

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

 - Merge branch 'master' into 8278028-test-warning-cleanup
 - Update copyrights
 - 8278028: [test-library] Warnings cleanup of the test library

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6638/files
  - new: https://git.openjdk.java.net/jdk/pull/6638/files/0f445b4a..b1bbdfc7

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

  Stats: 30109 lines in 1016 files changed: 21851 ins; 3569 del; 4689 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

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

From mcimadamore at openjdk.java.net  Mon Dec 13 21:20:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 13 Dec 2021 21:20:40 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc
Message-ID: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>

This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.

-------------

Commit messages:
 - Misc foreign API javadoc fixes

Changes: https://git.openjdk.java.net/jdk18/pull/17/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278607
  Stats: 35 lines in 7 files changed: 3 ins; 1 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk18/pull/17

From john.r.rose at oracle.com  Mon Dec 13 21:32:59 2021
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 13 Dec 2021 13:32:59 -0800
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc
In-Reply-To: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
Message-ID: <43F6A80C-4776-48F8-85DF-6DAE9B269829@oracle.com>

Nice work.  I like this API a lot, and the doc is getting a good clear 
shine on it.

The run-on sentence at the top of `<h3>Foreign addresses</h3>` needs a 
bit more polish.  The long parenthetical comment still reads awkwardly.  
Maybe it doesn?t need parentheses any more, now that it?s part of 
(or all of) its own small sentence?

On 13 Dec 2021, at 13:20, Maurizio Cimadamore wrote:

> This patch fixes a number of issues and typos in the foreign API 
> javadoc following another internal round of reviews.
>
> -------------
>
> Commit messages:
>  - Misc foreign API javadoc fixes
>
> Changes: https://git.openjdk.java.net/jdk18/pull/17/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8278607
>   Stats: 35 lines in 7 files changed: 3 ins; 1 del; 31 mod
>   Patch: https://git.openjdk.java.net/jdk18/pull/17.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk18 
> pull/17/head:pull/17
>
> PR: https://git.openjdk.java.net/jdk18/pull/17

From mcimadamore at openjdk.java.net  Mon Dec 13 21:36:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 13 Dec 2021 21:36:04 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v2]
In-Reply-To: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
Message-ID: <F9gddQkF-Af_aSvsVTg_m5N-0yJr4YdywcR0YQa4eqE=.b9309410-39b9-4471-b871-30dcde3f90bd@github.com>

> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix capitalization in package-info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/17/files
  - new: https://git.openjdk.java.net/jdk18/pull/17/files/011f6e5f..aa74d836

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk18/pull/17

From duke at openjdk.java.net  Tue Dec 14 01:27:17 2021
From: duke at openjdk.java.net (TheMode)
Date: Tue, 14 Dec 2021 01:27:17 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v2]
In-Reply-To: <F9gddQkF-Af_aSvsVTg_m5N-0yJr4YdywcR0YQa4eqE=.b9309410-39b9-4471-b871-30dcde3f90bd@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
 <F9gddQkF-Af_aSvsVTg_m5N-0yJr4YdywcR0YQa4eqE=.b9309410-39b9-4471-b871-30dcde3f90bd@github.com>
Message-ID: <-mxSBux6dbWT8pyTLTilbjuLudeLmeOu9lCcDu3uVZk=.55200b5e-7f51-462c-b3f4-8c75c4806324@github.com>

On Mon, 13 Dec 2021 21:36:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix capitalization in package-info

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 36:

> 34: 
> 35: /**
> 36:  * A memory address models a reference into a memory location. Memory addresses are typically obtained in onw of the following ways:

Should perhaps be `one` :)

-------------

PR: https://git.openjdk.java.net/jdk18/pull/17

From jwilhelm at openjdk.java.net  Tue Dec 14 01:49:19 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 01:49:19 GMT
Subject: RFR: Merge jdk18
Message-ID: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8132785: java/lang/management/ThreadMXBean/ThreadLists.java fails intermittently
 - 8273108: RunThese24H crashes with SEGV in markWord::displaced_mark_helper() after JDK-8268276
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64
 - 8277299: STACK_OVERFLOW in Java_sun_awt_shell_Win32ShellFolder2_getIconBits

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/6824/files
  Stats: 119 lines in 6 files changed: 85 ins; 1 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6824.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6824/head:pull/6824

PR: https://git.openjdk.java.net/jdk/pull/6824

From mcimadamore at openjdk.java.net  Tue Dec 14 02:07:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 14 Dec 2021 02:07:00 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v3]
In-Reply-To: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
Message-ID: <v7FZGhMeEeJ6D-g7gagwou8DedW-UxZLJhA1mGL1nc4=.c68c0eea-6daf-4fd8-ab10-384aa4e2c3b6@github.com>

> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Clarify sentence in package-info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/17/files
  - new: https://git.openjdk.java.net/jdk18/pull/17/files/aa74d836..603df4ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk18/pull/17

From jwilhelm at openjdk.java.net  Tue Dec 14 02:21:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 02:21:17 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
References: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
Message-ID: <BpGRPdTHQBjmHRAKHcLpbqGZLQhG_0FMx0w0MVnDCs0=.e6fd03f9-40a3-45c6-a5a4-15e573328eb6@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson 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 29 additional commits since the last revision:

 - Merge
 - 8278275: Initial nroff manpage generation for JDK 19
   
   Reviewed-by: erikj, jjg, iris
 - 8278630: ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
   
   Reviewed-by: psandoz
 - 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr
   
   Reviewed-by: kevinw, sspitsyn, amenkov
 - 8259610: VectorReshapeTests are not effective due to failing to intrinsify "VectorSupport.convert"
   
   Reviewed-by: psandoz, chagedorn
 - 8276241: JVM does not flag constant class entries ending in '/'
   
   Reviewed-by: dholmes, lfoltan
 - 8277481: Obsolete seldom used CDS flags
   
   Reviewed-by: iklam, ccheung, dholmes
 - 8271079: JavaFileObject#toUri and multi-release jars
   
   Reviewed-by: jjg, lancea, alanb
 - 8278482: G1: Improve HeapRegion::block_is_obj
   
   Reviewed-by: sjohanss, tschatzl, mli
 - 8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output
   
   Reviewed-by: mdoerr, goetz, stuefe
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9d2883a1...dc02f07e

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6824/files
  - new: https://git.openjdk.java.net/jdk/pull/6824/files/dc02f07e..dc02f07e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6824&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6824&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6824.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6824/head:pull/6824

PR: https://git.openjdk.java.net/jdk/pull/6824

From jwilhelm at openjdk.java.net  Tue Dec 14 02:21:19 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Dec 2021 02:21:19 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
References: <G9smFLJnz840gwbfeIat9kynTHpPxVQtUN26NkbTmBY=.89fed81a-0251-4468-b20b-8cfd2ee8e3e1@github.com>
Message-ID: <mbtbn8MLitIqcoSif-cvbsgEYfLRe5zRyDvrwfvyGEc=.b6ad1d02-7b22-4f5e-8167-35c3633bea93@github.com>

On Tue, 14 Dec 2021 01:35:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 8401a059
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8401a059bd01b32e3532f806d3d8b60e851c468a
Stats:     119 lines in 6 files changed: 85 ins; 1 del; 33 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6824

From lmesnik at openjdk.java.net  Tue Dec 14 03:17:35 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 14 Dec 2021 03:17:35 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
Message-ID: <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>

On Mon, 13 Dec 2021 20:58:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8278028-test-warning-cleanup
>  - Update copyrights
>  - 8278028: [test-library] Warnings cleanup of the test library

Is test/micro/org/openjdk/bench/java/io/SerialFilterOverhead.java  added accidentally or by purpose?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From almatvee at openjdk.java.net  Tue Dec 14 06:17:45 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 14 Dec 2021 06:17:45 GMT
Subject: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to
 /usr/bin/osascript
Message-ID: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>

This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT instead of actual value of timeout variable. Execution of osascript was running without timeout and thus several tests timeout. Osascript hang during test execution is intermittent issue.

Also, removed IconTest.java and MultiNameTwoPhaseTest.java from ProblemList.txt.

-------------

Commit messages:
 - 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript

Changes: https://git.openjdk.java.net/jdk18/pull/18/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=18&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278233
  Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/18/head:pull/18

PR: https://git.openjdk.java.net/jdk18/pull/18

From sundar at openjdk.java.net  Tue Dec 14 08:38:23 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 14 Dec 2021 08:38:23 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v3]
In-Reply-To: <v7FZGhMeEeJ6D-g7gagwou8DedW-UxZLJhA1mGL1nc4=.c68c0eea-6daf-4fd8-ab10-384aa4e2c3b6@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
 <v7FZGhMeEeJ6D-g7gagwou8DedW-UxZLJhA1mGL1nc4=.c68c0eea-6daf-4fd8-ab10-384aa4e2c3b6@github.com>
Message-ID: <71Got8AoalUufEEJD-ai937DPgFuecsaRbuA9GeyqdM=.1c12cc00-0e34-4217-a8a3-d7953181ea8b@github.com>

On Tue, 14 Dec 2021 02:07:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify sentence in package-info

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/17

From mcimadamore at openjdk.java.net  Tue Dec 14 10:24:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 14 Dec 2021 10:24:07 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v4]
In-Reply-To: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
Message-ID: <VwKowPydc860JGzuE--63PKR7TiczNEKlBuok0XezFc=.03c69cc7-eec0-4c21-bda5-216b71484330@github.com>

> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo as per review comment. Improve javadoc for VaList.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/17/files
  - new: https://git.openjdk.java.net/jdk18/pull/17/files/603df4ec..5f1ee0ed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=17&range=02-03

  Stats: 22 lines in 2 files changed: 13 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk18/pull/17

From alanb at openjdk.java.net  Tue Dec 14 13:24:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Dec 2021 13:24:06 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
Message-ID: <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>

On Mon, 13 Dec 2021 09:55:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>> 
>> It looks like in the following code in `String(byte[], int, int, Charset)`
>> 
>> while (offset < sl) {
>>     int b1 = bytes[offset];
>>     if (b1 >= 0) {
>>         dst[dp++] = (byte)b1;
>>         offset++;                                  // <---
>>         continue;
>>     }
>>     if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
>>             offset + 1 < sl) {
>>         int b2 = bytes[offset + 1];
>>         if (!isNotContinuation(b2)) {
>>             dst[dp++] = (byte)decode2(b1, b2);
>>             offset += 2;
>>             continue;
>>         }
>>     }
>>     // anything not a latin1, including the repl
>>     // we have to go with the utf16
>>     break;
>> }
>> 
>> bounds check elimination is not executed when accessing byte array via `bytes[offset].
>> 
>> The reason, I guess, is that offset variable is modified within the loop (marked with arrow).
>> 
>> Possible fix for this could be changing:
>> 
>> `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`
>> 
>> However the best is to invest in C2 optimization to handle all such cases.
>> 
>> The following benchmark demonstrates good improvement:
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class StringConstructorBenchmark {
>>   private byte[] array;
>>   private String str;
>> 
>>   @Setup
>>   public void setup() {
>>     str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
>>     array = str.getBytes(StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String newString()  {
>>       return new String(array, 0, array.length, StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String translateEscapes()  {
>>       return str.translateEscapes();
>>   }
>> }
>> 
>> Results:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op
>> 
>> The same is observed in String.translateEscapes() for the same String as in the benchmark above:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op
>> 
>> Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.
>> 
>> Here's the part of baseline assembly responsible for `while` loop: 
>> 
>>   3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
>>   2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
>>   2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
>>                    ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
>>   3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
>>                    ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
>>   2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
>>   2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
>>   2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
>>   3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
>>   2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
>>   2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
>>   2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
>>   3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
>>   2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
>>   2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
>>   2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
>>                    ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
>>   3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
>>   2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
>>   2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
>>   2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
>>   3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
>>   2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
>>   2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
>>                    ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                                ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)
>> 
>> and this one is for patched code:
>> 
>>  17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
>>                    ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
>>   0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
>>                    ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
>>   0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
>>  13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
>>   0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
>>   0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
>>   0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
>>   0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
>>  12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
>>   0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
>>   0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
>>   0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
>>   0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>> 
>> Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.
>
>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
> 
> Before anyone looks at this, can you confirm that the patch does not include any code or tests/benchmarks that were taken from SO?

> @AlanBateman the benchmark is mine along with the changes for `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is from SO.

I don't know how we can progress this PR if the patch includes code copied from SO. Maybe the PR should be closed, the JBS issue unassigned, and leave it to someone else to start again? Maybe you could get Amit to sign the OCA and you co-contribute/author the PR? I can't look at the patch so I don't know how significant the changes, maybe there are other options.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From aleonard at openjdk.java.net  Tue Dec 14 13:34:24 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 14 Dec 2021 13:34:24 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <txzrdPiJ4m3GxdDZ1vw1DPwy8ssCVKK24Jz136mNSwU=.12f0c785-ccf3-4c00-8ae0-b662923eb580@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
 <txzrdPiJ4m3GxdDZ1vw1DPwy8ssCVKK24Jz136mNSwU=.12f0c785-ccf3-4c00-8ae0-b662923eb580@github.com>
Message-ID: <UHWBaqI3oCfpPRkM5GtpDC9bTltiXglS9796BPdyx_Y=.c20da99e-f87d-4e92-889c-1392b22dfdb4@github.com>

On Fri, 10 Dec 2021 19:40:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR
>
>> @LanceAndersen let me know if mach5 looks good please, then I think we're good to go..
> 
> As soon as  the Mach5 finishes, I will let you know

@LanceAndersen fyi.i've raised a docs enhancement for the closed repo "man" pages to be updated for this: https://bugs.openjdk.java.net/browse/JDK-8278764

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From herrick at openjdk.java.net  Tue Dec 14 14:00:16 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 14 Dec 2021 14:00:16 GMT
Subject: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to
 /usr/bin/osascript
In-Reply-To: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
References: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
Message-ID: <y1MjWaPRD5H2roTBmRTsgJwgoSwFpbpJMIHL9yw2Bao=.a908301c-d246-4a0e-aead-dd38b8906770@github.com>

On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT instead of actual value of timeout variable. Execution of osascript was running without timeout and thus several tests timeout. Osascript hang during test execution is intermittent issue.
> 
> Also, removed IconTest.java and MultiNameTwoPhaseTest.java from ProblemList.txt.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/18

From redestad at openjdk.java.net  Tue Dec 14 14:58:22 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 14 Dec 2021 14:58:22 GMT
Subject: RFR: 8278642: Refactor java.util.Formatter
Message-ID: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>

A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:

- turn `Flags` into an `int` (fewer allocations in the complex case)
- remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
- make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.

Baseline: 

Benchmark                                                           Mode  Cnt     Score     Error   Units
StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op


Patch:

Benchmark                                                           Mode  Cnt     Score    Error   Units
StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

-------------

Commit messages:
 - Fix call with null Formatter
 - 8278642: Refactor Formatter

Changes: https://git.openjdk.java.net/jdk/pull/6821/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6821&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278642
  Stats: 333 lines in 1 file changed: 0 ins; 39 del; 294 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6821.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6821/head:pull/6821

PR: https://git.openjdk.java.net/jdk/pull/6821

From duke at openjdk.java.net  Tue Dec 14 15:14:08 2021
From: duke at openjdk.java.net (amirhadadi)
Date: Tue, 14 Dec 2021 15:14:08 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
 <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>
Message-ID: <rpKNArWbEjcUoBTsMnBqJgk-dHcqEuySyReM3I5dq9s=.01c0aaf4-2ef2-42b5-b0fe-d69fed2a7635@github.com>

On Tue, 14 Dec 2021 13:20:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>> 
>> Before anyone looks at this, can you confirm that the patch does not include any code or tests/benchmarks that were taken from SO?
>
>> @AlanBateman the benchmark is mine along with the changes for `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is from SO.
> 
> I don't know how we can progress this PR if the patch includes code copied from SO. Maybe the PR should be closed, the JBS issue unassigned, and leave it to someone else to start again? Maybe you could get Amit to sign the OCA and you co-contribute/author the PR? I can't look at the patch so I don't know how significant the changes, maybe there are other options.

@AlanBateman @stsypanov I have no problem signing the OCA.
However like @stsypanov mentioned, I don't think this is the right approach.
Adding explicit check that the offset is non negative makes no semantic difference, it just helps the optimizer to figure out that no bounds checking is needed.
A better approach is to improve the optimizer so that it can apply bounds checking elimination in this case (and hopefully in many other cases).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From rriggs at openjdk.java.net  Tue Dec 14 15:23:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 15:23:47 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v3]
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove a test/micro file added by mistake.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6638/files
  - new: https://git.openjdk.java.net/jdk/pull/6638/files/b1bbdfc7..895acede

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=01-02

  Stats: 129 lines in 1 file changed: 0 ins; 129 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

PR: https://git.openjdk.java.net/jdk/pull/6638

From lmesnik at openjdk.java.net  Tue Dec 14 15:23:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 14 Dec 2021 15:23:48 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v3]
In-Reply-To: <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>
Message-ID: <NtwcOf4syrU8sHafxEq0t33YYEJOW12-TOfGXaT82EU=.77dddc0f-7536-4749-a033-b0b739048632@github.com>

On Tue, 14 Dec 2021 15:20:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove a test/micro file added by mistake.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From rriggs at openjdk.java.net  Tue Dec 14 15:23:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 15:23:50 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
 <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>
Message-ID: <2AldylG79vmQABcXw3_k6iXKj9Y0nImbOeOePJIzxw0=.f886f9cd-fc34-49af-b293-fbf326e5ce5c@github.com>

On Tue, 14 Dec 2021 03:14:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Is test/micro/org/openjdk/bench/java/io/SerialFilterOverhead.java added accidentally or by purpose?

By mistake, thanks for noticing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From robm at openjdk.java.net  Tue Dec 14 15:26:54 2021
From: robm at openjdk.java.net (Rob McKenna)
Date: Tue, 14 Dec 2021 15:26:54 GMT
Subject: RFR: JDK-8277795: ldap connection timeout not honoured under
 contention [v3]
In-Reply-To: <j0ee6XE5GEmdzHkjj7ZgOu8cqWZpGA9-1BhxjWHLffo=.d2ccaefd-9557-4b55-a8a0-8040ac4c6dff@github.com>
References: <j0ee6XE5GEmdzHkjj7ZgOu8cqWZpGA9-1BhxjWHLffo=.d2ccaefd-9557-4b55-a8a0-8040ac4c6dff@github.com>
Message-ID: <pKZrxhg0XELabQautH2Ipbx6NUF4eR2H4lZGQ49HC4g=.962420ea-0cad-42b9-be8a-6a723115f65e@github.com>

> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences.
> 
> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR.

Rob McKenna has updated the pull request incrementally with one additional commit since the last revision:

  Allow the test to pass on MacOSX

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6568/files
  - new: https://git.openjdk.java.net/jdk/pull/6568/files/1b679497..7c277622

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6568&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6568&range=01-02

  Stats: 22 lines in 1 file changed: 10 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6568/head:pull/6568

PR: https://git.openjdk.java.net/jdk/pull/6568

From naoto at openjdk.java.net  Tue Dec 14 18:34:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Dec 2021 18:34:03 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
Message-ID: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>

This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

-------------

Commit messages:
 - 8278587: StringTokenizer(String, String, boolean) documentation bug

Changes: https://git.openjdk.java.net/jdk/pull/6836/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6836&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278587
  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6836.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6836/head:pull/6836

PR: https://git.openjdk.java.net/jdk/pull/6836

From iris at openjdk.java.net  Tue Dec 14 18:43:43 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 14 Dec 2021 18:43:43 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
In-Reply-To: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
Message-ID: <Y2aflJpFiTLP0zZvkmWTGEJ7xJKp7YlvKTu9vK_R__o=.3a0a25ce-1fb0-46ae-93af-44ac33d3df30@github.com>

On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

Corresponding CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6836

From joehw at openjdk.java.net  Tue Dec 14 18:52:33 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 14 Dec 2021 18:52:33 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
In-Reply-To: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
Message-ID: <Vqmzban2_1lD7zzfp-cTMFs1dKFdOrsGsJFZ-utZfZ8=.97d774d4-515d-4afb-bb85-c26ec989b4b1@github.com>

On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From lancea at openjdk.java.net  Tue Dec 14 19:08:37 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 14 Dec 2021 19:08:37 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
In-Reply-To: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
Message-ID: <P7sUkEiwgTDJ0HyRS3XYxEsGfjtBCjXHD2iKd19w6h0=.57c22a72-94be-4607-8026-1d90c7b86730@github.com>

On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From duke at openjdk.java.net  Tue Dec 14 19:16:36 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Tue, 14 Dec 2021 19:16:36 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
Message-ID: <5X0M-QCo6D0PWvW5sodKaXUpC8h2dMuONL1BV9Z2eMo=.d0d7af1a-65d5-48d4-b559-2e1f9a492655@github.com>

On Mon, 13 Dec 2021 09:39:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
> 
> It looks like in the following code in `String(byte[], int, int, Charset)`
> 
> while (offset < sl) {
>     int b1 = bytes[offset];
>     if (b1 >= 0) {
>         dst[dp++] = (byte)b1;
>         offset++;                                  // <---
>         continue;
>     }
>     if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
>             offset + 1 < sl) {
>         int b2 = bytes[offset + 1];
>         if (!isNotContinuation(b2)) {
>             dst[dp++] = (byte)decode2(b1, b2);
>             offset += 2;
>             continue;
>         }
>     }
>     // anything not a latin1, including the repl
>     // we have to go with the utf16
>     break;
> }
> 
> bounds check elimination is not executed when accessing byte array via `bytes[offset].
> 
> The reason, I guess, is that offset variable is modified within the loop (marked with arrow).
> 
> Possible fix for this could be changing:
> 
> `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`
> 
> However the best is to invest in C2 optimization to handle all such cases.
> 
> The following benchmark demonstrates good improvement:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class StringConstructorBenchmark {
>   private byte[] array;
>   private String str;
> 
>   @Setup
>   public void setup() {
>     str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
>     array = str.getBytes(StandardCharsets.UTF_8);
>   }
> 
>   @Benchmark
>   public String newString()  {
>       return new String(array, 0, array.length, StandardCharsets.UTF_8);
>   }
> 
>   @Benchmark
>   public String translateEscapes()  {
>       return str.translateEscapes();
>   }
> }
> 
> Results:
> 
> //baseline
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op
> 
> //patched
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op
> 
> The same is observed in String.translateEscapes() for the same String as in the benchmark above:
> 
> //baseline
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op
> 
> //patched
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op
> 
> Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.
> 
> Here's the part of baseline assembly responsible for `while` loop: 
> 
>   3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
>   2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
>   2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>                   ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>   2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
>                    ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
>   3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
>                    ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
>   2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
>   2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
>   2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
>   3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
>   2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
>   2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
>   2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
>   3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
>   2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
>   2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
>   2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
>                    ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
>   3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
>   2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
>   2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
>   2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
>   3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
>   2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
>   2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
>                    ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>                                ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)
> 
> and this one is for patched code:
> 
>  17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>                   ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>   0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
>                    ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
>   0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
>                    ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
>   0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
>  13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
>   0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
>   0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
>   0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
>   0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
>  12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
>   0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
>   0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
>   0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
>   0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
> 
> Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.

Hi, the problem here does not seem to lie in the bound check eliminations, as the patched version still contains the bound checks in these lines:

    13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
     0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671

The problem, at first glance, seems to be that our compiled code is trying to compute this mysterious number

    long temp = sl;
    loop {
        long newTemp = (long)((int)((temp - (long)offset + 1) & (-2L)) + offset) - 2L;
        if (newTemp u>= temp) jump;
        temp = newTemp;
    }

I think further investigation is needed, maybe our compiler is trying too hard to deal with various appearance of `offset` in the loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From asemenyuk at openjdk.java.net  Tue Dec 14 19:50:23 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 14 Dec 2021 19:50:23 GMT
Subject: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to
 /usr/bin/osascript
In-Reply-To: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
References: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
Message-ID: <df-_LJAJIw1LlQdPmp_MNOZMo-VsYiOMJwTvC5CRnbY=.31fa539d-d5ae-4316-9554-6c6276a58607@github.com>

On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT instead of actual value of timeout variable. Execution of osascript was running without timeout and thus several tests timeout. Osascript hang during test execution is intermittent issue.
> 
> Also, removed IconTest.java and MultiNameTwoPhaseTest.java from ProblemList.txt.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/18

From rriggs at openjdk.java.net  Tue Dec 14 19:58:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 19:58:35 GMT
Subject: Integrated: 8278028: [test-library] Warnings cleanup of the test
 library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <w1VrX5JcIghP67qCkL0KR-IKADo6GDNrz318MXWaX7c=.20d3978d-043a-4492-a4dd-11b278555745@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

This pull request has now been integrated.

Changeset: 03f647f4
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03f647f4bb640bf5df1c461eec9860c7ac3eb076
Stats:     28 lines in 14 files changed: 10 ins; 1 del; 17 mod

8278028: [test-library] Warnings cleanup of the test library

Reviewed-by: dfuchs, mchung, naoto, lancea, lmesnik

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From duke at openjdk.java.net  Tue Dec 14 21:00:58 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 14 Dec 2021 21:00:58 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <5X0M-QCo6D0PWvW5sodKaXUpC8h2dMuONL1BV9Z2eMo=.d0d7af1a-65d5-48d4-b559-2e1f9a492655@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <5X0M-QCo6D0PWvW5sodKaXUpC8h2dMuONL1BV9Z2eMo=.d0d7af1a-65d5-48d4-b559-2e1f9a492655@github.com>
Message-ID: <nhmc5N7QEp9SZhu2cSryk9YKZMFxopPGseWc7ugyOoA=.4adfef04-a758-4a2c-a295-0783d771aaf1@github.com>

On Tue, 14 Dec 2021 19:12:29 GMT, Mai ??ng Qu?n Anh <duke at openjdk.java.net> wrote:

> The problem, at first glance, seems to be that our compiled code is trying to compute this mysterious number

@merykitty how do you view it? ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From duke at openjdk.java.net  Tue Dec 14 22:52:57 2021
From: duke at openjdk.java.net (liach)
Date: Tue, 14 Dec 2021 22:52:57 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap
In-Reply-To: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
Message-ID: <-Hyo2Wvwi4GTj80RM1lJKWDSUVLAKaPSd5VI8n0FwDw=.eb7e3eb8-a2cc-435c-8753-5542cfd90d3b@github.com>

On Wed, 24 Nov 2021 05:16:40 GMT, liach <duke at openjdk.java.net> wrote:

> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.

Just curious, what else is recommended for such additions? Is there any recommended tests (though previous additions of `forEach` and `replaceAll` did not add any)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6532

From almatvee at openjdk.java.net  Wed Dec 15 00:03:01 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 15 Dec 2021 00:03:01 GMT
Subject: [jdk18] Integrated: 8278233: [macos] tools/jpackage tests timeout due
 to /usr/bin/osascript
In-Reply-To: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
References: <U99vy6NiU_a2WqvqZ1bGD7YodlGcDMBy3cXMsOgev5U=.0c6b6a58-054f-4167-a0fa-bfa3cde37c39@github.com>
Message-ID: <-ZphOZDdXDpXfQN0QglMGkgPOx0OLBlS6reKrqHZ840=.8cf51edb-fd1d-46bc-8f2d-e993678a90e3@github.com>

On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT instead of actual value of timeout variable. Execution of osascript was running without timeout and thus several tests timeout. Osascript hang during test execution is intermittent issue.
> 
> Also, removed IconTest.java and MultiNameTwoPhaseTest.java from ProblemList.txt.

This pull request has now been integrated.

Changeset: 918e3397
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/918e3397858c425e9c3b82c9a918b7626603a59c
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk18/pull/18

From kvn at openjdk.java.net  Wed Dec 15 06:08:28 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 06:08:28 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is thrown
 with -Xcomp in method handle invocation
Message-ID: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>

A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 

It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.

Added new regression test. Tested tier1-3.

-------------

Commit messages:
 - 8277964: ClassCastException with no stack trace is thrown with -Xcomp in method handle invocation

Changes: https://git.openjdk.java.net/jdk18/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=27&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277964
  Stats: 151 lines in 7 files changed: 149 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/27/head:pull/27

PR: https://git.openjdk.java.net/jdk18/pull/27

From dholmes at openjdk.java.net  Wed Dec 15 07:02:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 07:02:59 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
Message-ID: <2Kb5Q961w7Kw69AeNYu840nXSIoTi2lAlsZyKZk3mis=.9f063cd0-f593-48f6-bdb2-f99c52529cf0@github.com>

On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
> 
> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
> 
> Added new regression test. Tested tier1-3.

src/hotspot/share/oops/method.cpp line 827:

> 825:  */
> 826: bool Method::can_omit_stack_trace() {
> 827:   if (method_holder()->class_loader_data()->is_boot_class_loader_data()) {

Do you actually need to check this?

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From duke at openjdk.java.net  Wed Dec 15 07:57:01 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 07:57:01 GMT
Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2]
In-Reply-To: <SZkMZL-hkyqG_JeJ_1LRmKHIhcH3Dqw9dPOc97x5bdc=.589c1329-fc9b-44cd-8d32-85053e9d2834@github.com>
References: <YOPQ14TqFLOfPSNmXkVOwGQuPCgDssYeVQoIOULKnSU=.1e46116c-6c49-43e8-b30a-273a06226b8c@github.com>
 <SZkMZL-hkyqG_JeJ_1LRmKHIhcH3Dqw9dPOc97x5bdc=.589c1329-fc9b-44cd-8d32-85053e9d2834@github.com>
Message-ID: <6WEwCF5qe80pfWftiha8ugA6dEVQwF7Di_B79IxyjdU=.9420898d-63cd-4cd3-941c-348d6a9dc817@github.com>

On Tue, 16 Nov 2021 20:53:26 GMT, kabutz <duke at openjdk.java.net> wrote:

>> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. 
>> 
>> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored empty stream implementations to reduce duplicate code and improved unordered()
>   Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream()

Add another comment to keep this active.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6275

From duke at openjdk.java.net  Wed Dec 15 08:06:59 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 08:06:59 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <qbDcI26dCLarF1u7hxjm4X96NTejnoe-cQuixnqp0PU=.d9fe2aee-f277-46bf-b84f-0968d1004826@github.com>

On Tue, 30 Nov 2021 23:03:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 1878:
> 
>> 1876: 
>> 1877:         @Serial
>> 1878:         private static final long serialVersionUID = 0L;
> 
> I don't think you need to declare these, the instances are never intended to support serialization e.g. in the stream implementation for `AbstractTask` that extends `CountedCompleter` we state:
> 
>  * <p>Serialization is not supported as there is no intention to serialize
>  * tasks managed by stream ops.

Thanks, I see now that it is common for the ForkJoinTasks to be annotated with `@SuppressWarnings("serial")`

Changed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From dlong at openjdk.java.net  Wed Dec 15 08:10:00 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 15 Dec 2021 08:10:00 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
Message-ID: <nIYk0qUesSCimYZWsGHzdKBV4uMMTfABwf7qjGQSa2A=.1c5e7a27-712c-4c28-a1ef-8f6add8d520a@github.com>

On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
> 
> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
> 
> Added new regression test. Tested tier1-3.

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From duke at openjdk.java.net  Wed Dec 15 08:31:58 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 15 Dec 2021 08:31:58 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
 <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>
Message-ID: <gwp7gsMpRM7o9Tv8KhFAIb47TAdiFYbqxebMC8PEB2Q=.8d8f4674-3227-4dfa-8bf8-fe9b04007c6a@github.com>

On Tue, 14 Dec 2021 13:20:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>> 
>> Before anyone looks at this, can you confirm that the patch does not include any code or tests/benchmarks that were taken from SO?
>
>> @AlanBateman the benchmark is mine along with the changes for `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is from SO.
> 
> I don't know how we can progress this PR if the patch includes code copied from SO. Maybe the PR should be closed, the JBS issue unassigned, and leave it to someone else to start again? Maybe you could get Amit to sign the OCA and you co-contribute/author the PR? I can't look at the patch so I don't know how significant the changes, maybe there are other options.

@AlanBateman I suggest to decide first whether this should be fixed on HotSpot level (which is the best option to me) or on Java level.

If we choose HotSpot then the issue should be reassigned, because I cannot do the fix myself.

If we choose Java then I would revert the change for String constructor and Amir would commit it into this branch having OCA signed.

What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From duke at openjdk.java.net  Wed Dec 15 08:50:02 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 08:50:02 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <0kdhmvPL0uw6SEwxs0qw_fMpYx9nD1gVNyny88zwBDo=.955d3341-945b-4fb0-ac3a-6542942cb512@github.com>

On Tue, 30 Nov 2021 23:10:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 1874:
> 
>> 1872:          */
>> 1873:         private static final int PARALLEL_FORK_THRESHOLD = Integer.getInteger(
>> 1874:                 "java.math.BigInteger.parallelForkThreshold",
> 
> I suspect we don't need this system property, there is no such property for streams. We use `ForkJoinPool.getCommonPoolParallelism()`, which is configurable as an escape hatch.

Agreed. It is easier to add something in if we need it, than to take it out once we have offered it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Wed Dec 15 08:53:59 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 08:53:59 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <-zrGmluSiK4mEyP5TZ3QYrKhXjc5M7t4_JXhuRPBuJY=.e1dd5f35-1603-4b34-bd82-2a88c15387d9@github.com>

On Tue, 30 Nov 2021 23:16:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 1875:
> 
>> 1873:         private static final int PARALLEL_FORK_THRESHOLD = Integer.getInteger(
>> 1874:                 "java.math.BigInteger.parallelForkThreshold",
>> 1875:                 (int) Math.ceil(Math.log(Runtime.getRuntime().availableProcessors()) / Math.log(2)));
> 
> We can simplify to `32 - Integer.numberOfLeadingZeros(ForkJoinPool.getCommonPoolParallelism() - 1))`.
> 
> `ForkJoinPool.getCommonPoolParallelism()` is guaranteed to return a value `> 0`

`ForkJoinPool.getCommonPoolParallelism() ` cannot distinguish between 0, 1, and 2 active processors.  In the `java.util.stream.AbstractTask` class they calculate the number of leaves based on this with << 2. However, there is always the possibility that someone launches the parallel stream inside another FJP, so they check for that as well. It does complicate things a bit, but at the same time, means we have one less environment variable. And if it becomes an issue (which I doubt), then we can always add it later. Will work on this a bit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From sundar at openjdk.java.net  Wed Dec 15 12:23:15 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 15 Dec 2021 12:23:15 GMT
Subject: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc [v4]
In-Reply-To: <VwKowPydc860JGzuE--63PKR7TiczNEKlBuok0XezFc=.03c69cc7-eec0-4c21-bda5-216b71484330@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
 <VwKowPydc860JGzuE--63PKR7TiczNEKlBuok0XezFc=.03c69cc7-eec0-4c21-bda5-216b71484330@github.com>
Message-ID: <dYEhmBVWq5XBAxIfoxzA0y9Cq_1ODtjZm_EZ8fgBVxY=.a9fec1dd-5563-4429-831d-efb1f86515b9@github.com>

On Tue, 14 Dec 2021 10:24:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo as per review comment. Improve javadoc for VaList.

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/17

From mcimadamore at openjdk.java.net  Wed Dec 15 12:29:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Dec 2021 12:29:00 GMT
Subject: [jdk18] Integrated: 8278607: Misc issues in foreign API javadoc
In-Reply-To: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
References: <IOCrobrAvZLnD9yRtE4FPyb-cTYUwlw9mv6Hl3RFujo=.058abeed-ebcf-46a9-b3bb-9ca60582c558@github.com>
Message-ID: <CV7AGNtghUCrkdkE9ctrVZ23gCPcWuxWfD1DGvyiIcQ=.e3d740e9-2149-4c03-ad8c-5239ac2669d8@github.com>

On Mon, 13 Dec 2021 21:13:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a number of issues and typos in the foreign API javadoc following another internal round of reviews.

This pull request has now been integrated.

Changeset: d6b5544e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/d6b5544e74d46c1ca464a1994e73ddd323ef5c2b
Stats:     56 lines in 7 files changed: 16 ins; 1 del; 39 mod

8278607: Misc issues in foreign API javadoc

Reviewed-by: sundar

-------------

PR: https://git.openjdk.java.net/jdk18/pull/17

From duke at openjdk.java.net  Wed Dec 15 14:28:02 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 14:28:02 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <bw-4As6ZchoXUsXyKs5ITauqeVb012rzj0EsxIn1FYQ=.a79dcca9-b440-43e2-9c97-393dc5c7832e@github.com>

On Tue, 30 Nov 2021 23:45:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 1930:
> 
>> 1928:         }
>> 1929: 
>> 1930:         private static RecursiveTask<BigInteger> exec(RecursiveOp op) {
> 
> Unused.

Well spotted, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Wed Dec 15 14:35:00 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 14:35:00 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <xG5P7prYgRwQHWu4dWmDu5d_8KEeQf9Kftehh14tK7U=.66a896bb-a43e-4568-9f30-59f1bd3d3a78@github.com>

On Tue, 30 Nov 2021 23:19:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 2000:
> 
>> 1998:         da1 = a2.add(a0);
>> 1999:         db1 = b2.add(b0);
>> 2000:         var vm1_task = RecursiveOp.multiply(da1.subtract(a1), db1.subtract(b1), parallel, depth + 1);
> 
> I recommend incrementing the depth in the `RecursiveOp` constructor, thereby reducing the repetition.

Inside the constructor would not work, since we do not construct RecursiveOp for all the tasks. However, I have incremented the parameter depth. I don't like changing parameters inside methods, but since I'm doing it where it is being used, I feel that the code is now better than before. Thanks for the suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Wed Dec 15 14:44:01 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 14:44:01 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
Message-ID: <4BR0c-8xLtLnf1c2eYTIIqHnq2AEifwb301KZ25RSV4=.a0c008ab-8872-40ae-b57c-8b3f97c1ccf7@github.com>

On Tue, 30 Nov 2021 23:18:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> kabutz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java line 1909:
> 
>> 1907:             @Override
>> 1908:             public BigInteger compute() {
>> 1909:                 return a.multiply(b, true, super.parallel, super.depth);
> 
> Using `super.` is a little unusual, it's not wrong :-) but not really idiomatic in the source code base.

I cannot remember ever using `super.` like this before either :-) I have a static inner class, which in turn has two static inner classes, which are its subclasses. The inner inner classes want to access the fields of their outer static super class. Since the fields are private, we need to use `super` otherwise we get this compiler error:

error: non-static variable parallel cannot be referenced from a static context
                return a.multiply(b, true, parallel, depth);

And if we move the inner inner class up one level, then we also get an error:

error: parallel has private access in RecursiveOp
            return a.multiply(b, true, parallel, super.depth);

A solution of course is to make the fields non-private. Then the compiler is happy and we can get rid of the `super`. Since the classes are private anyway, making the fields private does not increase the encapsulation. I will do that to get rid of the `super` FWIW.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From mchung at openjdk.java.net  Wed Dec 15 17:19:00 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 15 Dec 2021 17:19:00 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
Message-ID: <cSRf2LB3QMnKFvRXvMSMw6o8QxF6lz4xhdzuDglRHcs=.4910c95b-24c1-457b-9ab4-8ff36c38e43e@github.com>

On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
> 
> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
> 
> Added new regression test. Tested tier1-3.

Looks good.   Thanks for taking this on.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/27

From kvn at openjdk.java.net  Wed Dec 15 17:19:02 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 17:19:02 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <2Kb5Q961w7Kw69AeNYu840nXSIoTi2lAlsZyKZk3mis=.9f063cd0-f593-48f6-bdb2-f99c52529cf0@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <2Kb5Q961w7Kw69AeNYu840nXSIoTi2lAlsZyKZk3mis=.9f063cd0-f593-48f6-bdb2-f99c52529cf0@github.com>
Message-ID: <WnTGwZ_JRp9ouVUE4LCD31ppWDWJrt5FjL9jj0XiAiU=.e60c69ce-8835-4908-8c34-9cd1bc1692b7@github.com>

On Wed, 15 Dec 2021 07:00:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
>> 
>> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
>> 
>> Added new regression test. Tested tier1-3.
>
> src/hotspot/share/oops/method.cpp line 827:
> 
>> 825:  */
>> 826: bool Method::can_omit_stack_trace() {
>> 827:   if (method_holder()->class_loader_data()->is_boot_class_loader_data()) {
> 
> Do you actually need to check this?

@dholmes-ora, thank you for looking on it.
I discussed it with Mandy and agreed that we need to narrow down this workaround as much as possible. That is why it is done only for system class loaded by null loader.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From mchung at openjdk.java.net  Wed Dec 15 17:22:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 15 Dec 2021 17:22:55 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <WnTGwZ_JRp9ouVUE4LCD31ppWDWJrt5FjL9jj0XiAiU=.e60c69ce-8835-4908-8c34-9cd1bc1692b7@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <2Kb5Q961w7Kw69AeNYu840nXSIoTi2lAlsZyKZk3mis=.9f063cd0-f593-48f6-bdb2-f99c52529cf0@github.com>
 <WnTGwZ_JRp9ouVUE4LCD31ppWDWJrt5FjL9jj0XiAiU=.e60c69ce-8835-4908-8c34-9cd1bc1692b7@github.com>
Message-ID: <UZs_SKnVeFJdkYtLIWd3Yb4r6O5_ScWwdAjM81Je48w=.35643697-a0e6-4d41-9777-9c8eea6d350b@github.com>

On Wed, 15 Dec 2021 17:15:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 827:
>> 
>>> 825:  */
>>> 826: bool Method::can_omit_stack_trace() {
>>> 827:   if (method_holder()->class_loader_data()->is_boot_class_loader_data()) {
>> 
>> Do you actually need to check this?
>
> @dholmes-ora, thank you for looking on it.
> I discussed it with Mandy and agreed that we need to narrow down this workaround as much as possible. That is why it is done only for system class loaded by null loader.

David has a good observation.   There will be no split package for modules.  So sun.invoke.util classes will only be loaded from java.base.  The boot loader is not needed.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From kvn at openjdk.java.net  Wed Dec 15 17:48:00 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 17:48:00 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <UZs_SKnVeFJdkYtLIWd3Yb4r6O5_ScWwdAjM81Je48w=.35643697-a0e6-4d41-9777-9c8eea6d350b@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <2Kb5Q961w7Kw69AeNYu840nXSIoTi2lAlsZyKZk3mis=.9f063cd0-f593-48f6-bdb2-f99c52529cf0@github.com>
 <WnTGwZ_JRp9ouVUE4LCD31ppWDWJrt5FjL9jj0XiAiU=.e60c69ce-8835-4908-8c34-9cd1bc1692b7@github.com>
 <UZs_SKnVeFJdkYtLIWd3Yb4r6O5_ScWwdAjM81Je48w=.35643697-a0e6-4d41-9777-9c8eea6d350b@github.com>
Message-ID: <3OyMsiLC_WdcDg3mFI_rJN1m-_ahV2uB6mzzXriQ1Lg=.dd9eaa23-ebb0-4a0a-9aaf-6c384582fcba@github.com>

On Wed, 15 Dec 2021 17:19:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @dholmes-ora, thank you for looking on it.
>> I discussed it with Mandy and agreed that we need to narrow down this workaround as much as possible. That is why it is done only for system class loaded by null loader.
>
> David has a good observation.   There will be no split package for modules.  So sun.invoke.util classes will only be loaded from java.base.  The boot loader is not needed.

Okay, I will remove it.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From duke at openjdk.java.net  Wed Dec 15 17:54:54 2021
From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh)
Date: Wed, 15 Dec 2021 17:54:54 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <gwp7gsMpRM7o9Tv8KhFAIb47TAdiFYbqxebMC8PEB2Q=.8d8f4674-3227-4dfa-8bf8-fe9b04007c6a@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <69S2uK2lSsNcZLnAwqJApxjRxbaTmvqyIeRkgcNGjBU=.f1665049-87fe-4f7a-b943-d75a2c4c5fa1@github.com>
 <a5G_GvE-btH8DrBj-Vol8bs5bG4tB3vuuZFvOEl5zY4=.eebf1cc8-d270-44e7-b9f1-be695595cc25@github.com>
 <gwp7gsMpRM7o9Tv8KhFAIb47TAdiFYbqxebMC8PEB2Q=.8d8f4674-3227-4dfa-8bf8-fe9b04007c6a@github.com>
Message-ID: <vzOrxU-632kjul2T2Gc4yWW6SbIz0cl0NiaPVuxTOPM=.3a855334-8095-44bc-a14f-bdbe9895559d@github.com>

On Wed, 15 Dec 2021 08:29:20 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>>> @AlanBateman the benchmark is mine along with the changes for `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is from SO.
>> 
>> I don't know how we can progress this PR if the patch includes code copied from SO. Maybe the PR should be closed, the JBS issue unassigned, and leave it to someone else to start again? Maybe you could get Amit to sign the OCA and you co-contribute/author the PR? I can't look at the patch so I don't know how significant the changes, maybe there are other options.
>
> @AlanBateman I suggest to decide first whether this should be fixed on HotSpot level (which is the best option to me) or on Java level.
> 
> If we choose HotSpot then the issue should be reassigned, because I cannot do the fix myself.
> 
> If we choose Java then I would revert the change for String constructor and Amir would commit it into this branch having OCA signed.
> 
> What do you think?

@stsypanov I just looked at the generated code and make a guess, which may be not entirely true though. I think you could ask hotspot compiler mailing list for more profound analysis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From kvn at openjdk.java.net  Wed Dec 15 17:56:23 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 17:56:23 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation [v2]
In-Reply-To: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
Message-ID: <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>

> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
> 
> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
> 
> Added new regression test. Tested tier1-3.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Removed boot classloader check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/27/files
  - new: https://git.openjdk.java.net/jdk18/pull/27/files/3c23350d..5b6805b6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=27&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=27&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/27/head:pull/27

PR: https://git.openjdk.java.net/jdk18/pull/27

From mchung at openjdk.java.net  Wed Dec 15 19:17:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 15 Dec 2021 19:17:53 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation [v2]
In-Reply-To: <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
Message-ID: <x05CSMOgrrO7Nd94cVGGqFIwb8u5krRcsLuQY7_yMrI=.1cef2d33-e522-4da5-93d0-77dd5b2e10e8@github.com>

On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
>> 
>> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
>> 
>> Added new regression test. Tested tier1-3.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed boot classloader check

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From rriggs at openjdk.java.net  Wed Dec 15 20:12:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 15 Dec 2021 20:12:55 GMT
Subject: RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

Looks good to me.  Not a big improvement, but as much as it gets used.  ??

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6821

From duke at openjdk.java.net  Wed Dec 15 20:15:01 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 20:15:01 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
Message-ID: <IvthzznVO-k9K7ddfB5iQIFMQc-gtqlmgOBrCL9M3tc=.4e7c54a4-9caa-4cbf-a149-d935d5847bec@github.com>

On Wed, 24 Nov 2021 15:20:42 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> Some benchmark results, run on my 1-6-2 server:
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
>> 
>> 
>> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made forkOrInvoke() method protected to avoid strange compiler error

> IIRC you are not overly concerned about the additional object creation of `RecursiveOp` instances?
> 
> If that changes the operation method could return `Object` and choose to perform the operation directly returning the `BigInteger` result or returning the particular `RecursiveOp`.
> 
> ```java
> private static Object multiply(BigInteger a, BigInteger b, boolean parallel, int depth) {
>     if (isParallel(parallel, depth)) {
>         return new RecursiveMultiply(a, b, parallel, depth).fork();
>     } else {
>         // Also called by RecursiveMultiply.compute()
>         return RecursiveMultiply.compute(a, b, false, depth);
>     }
> }
> ```
> 
> Then we could have another method on `RecursiveOp` that pattern matches e.g.:
> 
> ```java
>   static BigInteger join(Object o) {
>     // replace with pattern match switch when it exits preview
>     if (o instanceof BigInteger b) {
>         return b;
>     } else if (o instanceof RecursiveOp r) {
>         return r.join();
>     } else {
>         throw new InternalError("Cannot reach here);
>     }
>   }
> ```
> 
> That seems simple enough it might be worth doing anyway.

If we need a demonstration as to why pattern matching switch is necessary, then I guess we could do this. Each RecursiveOp instance is 40 bytes. To calculate Fibonacci (1_000_000_000) we create 7_324_218 tasks, thus we are allocating an additional 292_968_720 bytes of memory. In addition, I believe that calling invoke() allocates some more bytes. According to the GC logs, we allocate an additional 2.33 GB of memory. That might sound like a lot, but it takes 2.25 TB to calculate Fibonacci of 1 billion using our algorithm. The additional memory allocated is thus roughly 0.1%. The performance of the old sequential multiply and the new one, with the additional object creation, seems equivalent.

I would thus recommend that we keep it the way it is at the moment, with the new RecursiveOp task creation. Considering the volume of objects that we will be allocating once we get to Toom Cook 3, a 0.1% reduction in object allocation will not be noticed.


Old BigInteger#multiply()
Fibonacci   memory          bytes 
      100   11.5KB          11808
       1k  119.0KB         121856
      10k    1.2MB        1238552
     100k   13.0MB       13634608
       1m  177.5MB      186104688
      10m    3.3GB     3574666840
     100m   85.6GB    91866740256
    1000m    2.3TB  2475468459952

New BigInteger#multiply()
Fibonacci   memory          bytes  increase %
      100   11.5KB          11808  0.0
       1k  119.0KB         121856  0.0
      10k    1.2MB        1238552  0.0
     100k   13.0MB       13649176  0.1067
       1m  177.6MB      186197472  0.0498
      10m    3.3GB     3577835016  0.088
     100m   85.6GB    91960170576  0.1017
    1000m    2.3TB  2477979788992  0.1014

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Wed Dec 15 20:18:39 2021
From: duke at openjdk.java.net (kabutz)
Date: Wed, 15 Dec 2021 20:18:39 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
Message-ID: <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> Some benchmark results, run on my 1-6-2 server:
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
> 
> 
> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.

kabutz has updated the pull request incrementally with four additional commits since the last revision:

 - Made RecursiveOp fields package-private so that we do not need super. qualifiers in subclasses
 - Incremented depth once instead of on every call
 - Simplified depth calculation to rely on common pool parallelism or the current fork join pool executing the code.
 - Removed serialVersionUID and annotated class with @SuppressWarning("serial") instead

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6409/files
  - new: https://git.openjdk.java.net/jdk/pull/6409/files/59de5298..3cd16443

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=04-05

  Stats: 54 lines in 1 file changed: 17 ins; 16 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6409.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409

PR: https://git.openjdk.java.net/jdk/pull/6409

From dholmes at openjdk.java.net  Wed Dec 15 21:31:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 21:31:02 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation [v2]
In-Reply-To: <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
Message-ID: <LN9x_WrPjH4bjEUU0a48T3LJfyflZT-iW-sHS1dOnOE=.046982b5-8c9d-4a95-a92f-5e90ad9e9d7b@github.com>

On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
>> 
>> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
>> 
>> Added new regression test. Tested tier1-3.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed boot classloader check

Looks good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/27

From naoto at openjdk.java.net  Wed Dec 15 21:39:01 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 15 Dec 2021 21:39:01 GMT
Subject: RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <ncuWrX9JcktmM8Lg5yGXHzMs2Gb4PysShqpV0nhVNSM=.c757c636-7e63-43cd-ae58-8f1a50e4804f@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

LGTM. I'd be tempted to replace those `instanceof`s with pattern-match to get rid of castings, but that's not inherent to this issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6821

From kvn at openjdk.java.net  Wed Dec 15 21:49:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 21:49:04 GMT
Subject: [jdk18] RFR: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation [v2]
In-Reply-To: <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
 <vHcvg0dR3hSwhZwVn1nu7xFIeyS4JcbyT_6o9Bbtvao=.a8245ffa-0ef2-4156-97c1-133e4b0d5091@github.com>
Message-ID: <SmGzuVnFtrPrufb2vq1wxtpCSfsoPJVka-0eMwL-kk8=.77d6e883-fcd8-402b-9247-0a83a323c0b1@github.com>

On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
>> 
>> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
>> 
>> Added new regression test. Tested tier1-3.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed boot classloader check

Thank you, David, Dean and Mandy for reviews.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From kvn at openjdk.java.net  Wed Dec 15 21:49:06 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Dec 2021 21:49:06 GMT
Subject: [jdk18] Integrated: 8277964: ClassCastException with no stack trace is
 thrown with -Xcomp in method handle invocation
In-Reply-To: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
References: <lR6KNDVxpYmIXWPiM4DAvM-9kZp9plnZhzWzw0-yTNE=.0c1c3a2b-8e99-47fa-85e3-2869f47a5ef6@github.com>
Message-ID: <qneUQj3fE3_VQ9soeCZwWW_mfnT9Jmk8SdGUtzw3rn8=.97eff3f9-8d76-43fb-afdc-f873b4def7f4@github.com>

On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> A proper fix for this is to use the catchException combination. However, that introduces significant cold startup performance regression. JDK-8278447 tracks the work to address the performance regression using catchException and asSpreader combinator. It may require significant work and refactoring which is risky for JDK 18. 
> 
> It is proposed to implement a workaround in C2 to white list the relevant methods (all methods in sun.invoke.util.ValueConversions class) not to omit stack trace when exception is thrown in them.
> 
> Added new regression test. Tested tier1-3.

This pull request has now been integrated.

Changeset: d3408a46
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/d3408a46b7c8c2f8b5e41f3e286a497064a2c104
Stats:     149 lines in 7 files changed: 147 ins; 1 del; 1 mod

8277964: ClassCastException with no stack trace is thrown with -Xcomp in method handle invocation

Reviewed-by: dlong, mchung, dholmes

-------------

PR: https://git.openjdk.java.net/jdk18/pull/27

From redestad at openjdk.java.net  Wed Dec 15 23:03:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 15 Dec 2021 23:03:58 GMT
Subject: RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
 <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>
Message-ID: <ZYcS8UOuNxL3K7C8iTw3a6Eu7nUOLQg7VJYmnWGoowE=.bfb90dcc-66f1-4e1c-9ba2-749b65c2bf38@github.com>

On Wed, 15 Dec 2021 20:09:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
>> 
>> - turn `Flags` into an `int` (fewer allocations in the complex case)
>> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
>> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
>> 
>> Baseline: 
>> 
>> Benchmark                                                           Mode  Cnt     Score     Error   Units
>> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
>> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
>> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
>> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
>> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
>> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
>> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
>> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                                           Mode  Cnt     Score    Error   Units
>> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
>> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
>> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
>> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
>> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
>> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
>> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
>> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op
>
> Looks good to me.  Not a big improvement, but as much as it gets used.  ??

Thanks for reviews, @RogerRiggs and @naotoj ! 

Yes, the speed-up is a bit underwhelming. I had to dial back some more promising optimizations I was exploring (#6792) after realizing they'd be breaking semantics in case of an illegal format string. These are the cleanups and pile-on optimizations I could salvage from that experiment, along with some harmonization with changes @JimLaskey is doing for TemplatedStrings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6821

From jwilhelm at openjdk.java.net  Wed Dec 15 23:29:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 15 Dec 2021 23:29:07 GMT
Subject: RFR: Merge jdk18
Message-ID: <qKJ_aLS34-nMhp9K8Tf3CzC2mNzRkqPK-S7-4F7TXR0=.fb4ea675-ae5c-4697-8dbb-1f91b1d4631d@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8277964: ClassCastException with no stack trace is thrown with -Xcomp in method handle invocation
 - 8272064: test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java needs update for JEP 416
 - 8278607: Misc issues in foreign API javadoc
 - 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript
 - 8278758: runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after JDK-8262134
 - 8278744: KeyStore:getAttributes() not returning unmodifiable Set
 - 8277919: OldObjectSample event causing bloat in the class constant pool in JFR recording
 - 8262134: compiler/uncommontrap/TestDeoptOOM.java failed with "guarantee(false) failed: wrong number of expression stack elements during deopt"

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/6856/files
  Stats: 341 lines in 27 files changed: 269 ins; 12 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6856/head:pull/6856

PR: https://git.openjdk.java.net/jdk/pull/6856

From jwilhelm at openjdk.java.net  Thu Dec 16 00:31:05 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Dec 2021 00:31:05 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <qKJ_aLS34-nMhp9K8Tf3CzC2mNzRkqPK-S7-4F7TXR0=.fb4ea675-ae5c-4697-8dbb-1f91b1d4631d@github.com>
References: <qKJ_aLS34-nMhp9K8Tf3CzC2mNzRkqPK-S7-4F7TXR0=.fb4ea675-ae5c-4697-8dbb-1f91b1d4631d@github.com>
Message-ID: <y7WKIhY7achDv7Sv5kNbRhrTVdbcRbhoTSaTP8k5pWI=.e6150fe3-5235-4ce3-add7-214f43744230@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson 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 53 additional commits since the last revision:

 - Merge
 - 8278020: ~13% variation in Renaissance-Scrabble
   
   Reviewed-by: dholmes, stuefe, kvn
 - 8274898: Cleanup usages of StringBuffer in jdk tools modules
   
   Reviewed-by: sspitsyn, lmesnik
 - 8269838: BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified
   
   Reviewed-by: kevinw, sspitsyn
 - 8278186: org.jcp.xml.dsig.internal.dom.Utils.parseIdFromSameDocumentURI throws StringIndexOutOfBoundsException when calling substring method
   
   Reviewed-by: mullan
 - 8278241: Implement JVM SpinPause on linux-aarch64
   
   Reviewed-by: aph, phh
 - 8278842: Parallel: Remove unused VerifyObjectStartArrayClosure::_old_gen
   
   Reviewed-by: tschatzl
 - 8278548: G1: Remove unnecessary check in forward_to_block_containing_addr
   
   Reviewed-by: tschatzl, mli, sjohanss
 - 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation
   
   Reviewed-by: dholmes, hseigel
 - 8278351: Add function to retrieve worker_id from any context
   
   Reviewed-by: eosterlund, kbarrett, ayang
 - ... and 43 more: https://git.openjdk.java.net/jdk/compare/6d63c6dd...fa3d80e6

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6856/files
  - new: https://git.openjdk.java.net/jdk/pull/6856/files/fa3d80e6..fa3d80e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6856&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6856&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6856/head:pull/6856

PR: https://git.openjdk.java.net/jdk/pull/6856

From jwilhelm at openjdk.java.net  Thu Dec 16 00:31:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Dec 2021 00:31:08 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <qKJ_aLS34-nMhp9K8Tf3CzC2mNzRkqPK-S7-4F7TXR0=.fb4ea675-ae5c-4697-8dbb-1f91b1d4631d@github.com>
References: <qKJ_aLS34-nMhp9K8Tf3CzC2mNzRkqPK-S7-4F7TXR0=.fb4ea675-ae5c-4697-8dbb-1f91b1d4631d@github.com>
Message-ID: <NW6w84HCdZDaJgGYmNne-G48bXyhaS9J1DTcRSYO3Hs=.ae992a0d-6391-408e-9abe-ed37d2e7374e@github.com>

On Wed, 15 Dec 2021 23:18:45 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: e6b28e05
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6b28e05c6f7698f230b04199932d4fc81f41a89
Stats:     341 lines in 27 files changed: 269 ins; 12 del; 60 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6856

From psandoz at openjdk.java.net  Thu Dec 16 00:54:58 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 00:54:58 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <4BR0c-8xLtLnf1c2eYTIIqHnq2AEifwb301KZ25RSV4=.a0c008ab-8872-40ae-b57c-8b3f97c1ccf7@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
 <4BR0c-8xLtLnf1c2eYTIIqHnq2AEifwb301KZ25RSV4=.a0c008ab-8872-40ae-b57c-8b3f97c1ccf7@github.com>
Message-ID: <eTooPjOHD5vcoxBF9ltV2zmWOMfoHuvQuOM4WGGxF54=.e908f48a-dd2d-481e-8093-d92775a7869d@github.com>

On Wed, 15 Dec 2021 14:40:34 GMT, kabutz <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 1909:
>> 
>>> 1907:             @Override
>>> 1908:             public BigInteger compute() {
>>> 1909:                 return a.multiply(b, true, super.parallel, super.depth);
>> 
>> Using `super.` is a little unusual, it's not wrong :-) but not really idiomatic in the source code base.
>
> I cannot remember ever using `super.` like this before either :-) I have a static inner class, which in turn has two static inner classes, which are its subclasses. The inner inner classes want to access the fields of their outer static super class. Since the fields are private, we need to use `super` otherwise we get this compiler error:
> 
> error: non-static variable parallel cannot be referenced from a static context
>                 return a.multiply(b, true, parallel, depth);
> 
> And if we move the inner inner class up one level, then we also get an error:
> 
> error: parallel has private access in RecursiveOp
>             return a.multiply(b, true, parallel, super.depth);
> 
> A solution of course is to make the fields non-private. Then the compiler is happy and we can get rid of the `super`. Since the classes are private anyway, making the fields private does not increase the encapsulation. I will do that to get rid of the `super` FWIW.

Oh, i did not realize that was a forced move.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From psandoz at openjdk.java.net  Thu Dec 16 01:05:01 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 01:05:01 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <xG5P7prYgRwQHWu4dWmDu5d_8KEeQf9Kftehh14tK7U=.66a896bb-a43e-4568-9f30-59f1bd3d3a78@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
 <xG5P7prYgRwQHWu4dWmDu5d_8KEeQf9Kftehh14tK7U=.66a896bb-a43e-4568-9f30-59f1bd3d3a78@github.com>
Message-ID: <LIXvjch-RaHOqQNFyWEosFh_-z5sD81OuLijkb3wty8=.7261f8f7-d336-41e8-bc8b-6862e9b9ffaf@github.com>

On Wed, 15 Dec 2021 14:31:26 GMT, kabutz <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2000:
>> 
>>> 1998:         da1 = a2.add(a0);
>>> 1999:         db1 = b2.add(b0);
>>> 2000:         var vm1_task = RecursiveOp.multiply(da1.subtract(a1), db1.subtract(b1), parallel, depth + 1);
>> 
>> I recommend incrementing the depth in the `RecursiveOp` constructor, thereby reducing the repetition.
>
> Inside the constructor would not work, since we do not construct RecursiveOp for all the tasks. However, I have incremented the parameter depth. I don't like changing parameters inside methods, but since I'm doing it where it is being used, I feel that the code is now better than before. Thanks for the suggestion.

I am confused by "we do not construct RecursiveOp for all the tasks", since each call to `RecursiveOp.multiply/square` constructs a new object that is an instance of `RecursiveOp`. 

Your approach looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From mbalao at openjdk.java.net  Thu Dec 16 01:26:03 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 16 Dec 2021 01:26:03 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <lhMb3bMFD4zYUWctYIERO3QAQ9qkJRj0vVDoNvn5rPs=.1d8f2d64-187f-48ae-8b1c-180cfb2feb13@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
 <Zh9_zXLEKBICwX17eHY1XM2VtMuOISsHF2Fnwctbkqw=.19a5709e-5b59-4917-92c8-3bb0ab16d20a@github.com>
 <lhMb3bMFD4zYUWctYIERO3QAQ9qkJRj0vVDoNvn5rPs=.1d8f2d64-187f-48ae-8b1c-180cfb2feb13@github.com>
Message-ID: <jOAUBxJyj3Ql5Ymz_8ZlEIdIQWJ8ehOXPDXfM8skOPs=.c55d842c-c02b-4443-b383-64e71b24e800@github.com>

On Wed, 17 Nov 2021 20:04:50 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi Martin,
>> 
>> The change looks reasonable to me.
>> I would suggest having a CSR logged for this change due to the following [behavioral incompatibility](https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility):
>> Before the change - all available endpoints/URLs are tried to create an LDAP context.  
>> With the proposed change - incorrect credentials will prevent other endpoints to be exercised to create an LDAP context.  
>> 
>> Having a CSR will also help to document difference in handling `AuthenticationException` and `NamingException` during construction of an LDAP context from the list of endpoints acquired from a LDAP DNS provider.
>
> Hi @AlekseiEfimov 
> 
> Can you please review the CSR [1]?
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959

> @martinuy 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!

Please do not close, waiting for CSR approval.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From psandoz at openjdk.java.net  Thu Dec 16 01:37:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 01:37:03 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
Message-ID: <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>

On Wed, 15 Dec 2021 20:18:39 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> Some benchmark results, run on my 1-6-2 server:
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
>> 
>> 
>> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.
>
> kabutz has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Made RecursiveOp fields package-private so that we do not need super. qualifiers in subclasses
>  - Incremented depth once instead of on every call
>  - Simplified depth calculation to rely on common pool parallelism or the current fork join pool executing the code.
>  - Removed serialVersionUID and annotated class with @SuppressWarning("serial") instead

This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 05:07:55 2021
From: duke at openjdk.java.net (Suminda Sirinath Salpitikorala Dharmasena)
Date: Thu, 16 Dec 2021 05:07:55 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v5]
In-Reply-To: <wKbyRXuoLkfX-PpTaicz5Ysdxcw-DNKm_64ZgF789iQ=.320e0550-555d-41d6-9043-2e9492dd8187@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <wKbyRXuoLkfX-PpTaicz5Ysdxcw-DNKm_64ZgF789iQ=.320e0550-555d-41d6-9043-2e9492dd8187@github.com>
Message-ID: <saSPxsj6THmg4XQ-horDnqkEsJLJvEvfTvJqSIviQxA=.97e0d61c-7071-42fa-b6b0-6c4f589afa44@github.com>

On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results
>   
>   Enhanced intervals in MathUtils.
>   Updated references to Schubfach v4.

Has the paper been published?

What is holding this back from merging?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Thu Dec 16 05:57:55 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 05:57:55 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
 <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
Message-ID: <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>

On Thu, 16 Dec 2021 01:33:46 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.

Thank you so much Paul.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 06:00:57 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 06:00:57 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v5]
In-Reply-To: <LIXvjch-RaHOqQNFyWEosFh_-z5sD81OuLijkb3wty8=.7261f8f7-d336-41e8-bc8b-6862e9b9ffaf@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <w0w5YYpPAYhuyAUy23i9tJgYr8sE3EwF0c9po-wSELk=.be0bb45f-8e79-468c-90cf-e861ee76d7e2@github.com>
 <lHSH2zXcTY3nvm2zIzxkJi_GE0kh_MGn2HwT1Gj0Nmg=.c47ed090-2e4c-4f95-90ae-acc42dbd029c@github.com>
 <xG5P7prYgRwQHWu4dWmDu5d_8KEeQf9Kftehh14tK7U=.66a896bb-a43e-4568-9f30-59f1bd3d3a78@github.com>
 <LIXvjch-RaHOqQNFyWEosFh_-z5sD81OuLijkb3wty8=.7261f8f7-d336-41e8-bc8b-6862e9b9ffaf@github.com>
Message-ID: <wlu8F5CaHTQm2oxrqeFz9-9T8TjWQ4N_WfsYrFUP48Q=.ad85ed75-6e8d-49f7-9d6c-0276644ca1a0@github.com>

On Thu, 16 Dec 2021 01:01:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Inside the constructor would not work, since we do not construct RecursiveOp for all the tasks. However, I have incremented the parameter depth. I don't like changing parameters inside methods, but since I'm doing it where it is being used, I feel that the code is now better than before. Thanks for the suggestion.
>
> I am confused by "we do not construct RecursiveOp for all the tasks", since each call to `RecursiveOp.multiply/square` constructs a new object that is an instance of `RecursiveOp`. 
> 
> Your approach looks good.

var v0_task = RecursiveOp.multiply(a0, b0, parallel, depth); // Here we make a new RecursiveOp for the multiply
        da1 = a2.add(a0);
        db1 = b2.add(b0);
        var vm1_task = RecursiveOp.multiply(da1.subtract(a1), db1.subtract(b1), parallel, depth); // Here also
        da1 = da1.add(a1);
        db1 = db1.add(b1);
        var v1_task = RecursiveOp.multiply(da1, db1, parallel, depth); // And here
        v2 = da1.add(a2).shiftLeft(1).subtract(a0).multiply( // Here we call multiply() directly, without the RecursiveOp
             db1.add(b2).shiftLeft(1).subtract(b0), true, parallel, depth);
        vinf = a2.multiply(b2, true, parallel, depth); // Again, we call multiply() directly
        v0 = v0_task.join();
        vm1 = vm1_task.join();
        v1 = v1_task.join();

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 06:07:29 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 06:07:29 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
Message-ID: <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>

> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
> 
> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
> 
> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
> 
> Some benchmark results, run on my 1-6-2 server:
> 
> 
> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
> 
> 
> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.

kabutz has updated the pull request incrementally with one additional commit since the last revision:

  Changed depth type to byte to save 8 bytes on each RecursiveSquare instance

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6409/files
  - new: https://git.openjdk.java.net/jdk/pull/6409/files/3cd16443..94c2d665

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6409.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409

PR: https://git.openjdk.java.net/jdk/pull/6409

From smarks at openjdk.java.net  Thu Dec 16 06:40:24 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 16 Dec 2021 06:40:24 GMT
Subject: [jdk18] RFR: 8278574: update --help-extra message to include default
 value of --finalization option
Message-ID: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>

A small modification to the Launcher's help text.

-------------

Commit messages:
 - Update launcher usage message to mention finalization default

Changes: https://git.openjdk.java.net/jdk18/pull/34/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=34&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278574
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/34/head:pull/34

PR: https://git.openjdk.java.net/jdk18/pull/34

From sundar at openjdk.java.net  Thu Dec 16 06:59:56 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 16 Dec 2021 06:59:56 GMT
Subject: [jdk18] RFR: 8278574: update --help-extra message to include
 default value of --finalization option
In-Reply-To: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
References: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
Message-ID: <td9vjgwv69j-6feJ3IGAiXA4ubnuGrYZlIyRnxFPHc8=.aca294fd-37cc-47f4-8664-c01dd3617872@github.com>

On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A small modification to the Launcher's help text.

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/34

From alanb at openjdk.java.net  Thu Dec 16 10:06:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 16 Dec 2021 10:06:57 GMT
Subject: [jdk18] RFR: 8278574: update --help-extra message to include
 default value of --finalization option
In-Reply-To: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
References: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
Message-ID: <mzfMi1RI4V21CzsDfW4E5i3C2CmLY0_RDwTrTu7-928=.fc9bdd6f-6f44-49b0-96cb-e8656001d2b0@github.com>

On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A small modification to the Launcher's help text.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/34

From redestad at openjdk.java.net  Thu Dec 16 10:17:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 16 Dec 2021 10:17:21 GMT
Subject: RFR: 8278831: Use table lookup for the last two bytes in
 Integer.getChars
Message-ID: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com>

During TemplatedStrings work Jim has noticed that we could probably profit from reusing the lookup tables also for the 1 or 2 leftmost bytes:

        // We know there are at most two digits left at this point.
        buf[--charPos] = DigitOnes[-i];
        if (i < -9) {
            buf[--charPos] = DigitTens[-i];
        }

This avoids some arithmetic, and on average achieves a small speed-up since the lookup tables are likely cached are likely to be in cache. Small improvements on a few affected microbenchmarks, including the new Integers.toStringTiny, can be observed. 

Baseline:

Benchmark              (size)  Mode  Cnt   Score   Error  Units
Integers.toStringTiny     500  avgt   50  21.862 ? 0.211  us/op


Patch:

Benchmark              (size)  Mode  Cnt   Score   Error  Units
Integers.toStringTiny     500  avgt   50  20.619 ? 0.330  us/op

-------------

Commit messages:
 - 8278831: Use table lookup for the last two bytes in Integer.getChars

Changes: https://git.openjdk.java.net/jdk/pull/6854/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6854&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278831
  Stats: 42 lines in 4 files changed: 11 ins; 16 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6854.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6854/head:pull/6854

PR: https://git.openjdk.java.net/jdk/pull/6854

From jlaskey at openjdk.java.net  Thu Dec 16 10:42:54 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 16 Dec 2021 10:42:54 GMT
Subject: RFR: 8278831: Use table lookup for the last two bytes in
 Integer.getChars
In-Reply-To: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com>
References: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com>
Message-ID: <OdRuyuUys1hEBwcVgwo6Fj0rVGSBllL0Kkf7eE1oqf4=.f7db9ef2-2367-4ba7-802b-617440995b18@github.com>

On Wed, 15 Dec 2021 23:04:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During TemplatedStrings work Jim has noticed that we could probably profit from reusing the lookup tables also for the 1 or 2 leftmost bytes:
> 
>         // We know there are at most two digits left at this point.
>         buf[--charPos] = DigitOnes[-i];
>         if (i < -9) {
>             buf[--charPos] = DigitTens[-i];
>         }
> 
> This avoids some arithmetic, and on average achieves a small speed-up since the lookup tables are likely cached are likely to be in cache. Small improvements on a few affected microbenchmarks, including the new Integers.toStringTiny, can be observed. 
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt   Score   Error  Units
> Integers.toStringTiny     500  avgt   50  21.862 ? 0.211  us/op
> 
> 
> Patch:
> 
> Benchmark              (size)  Mode  Cnt   Score   Error  Units
> Integers.toStringTiny     500  avgt   50  20.619 ? 0.330  us/op

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6854

From redestad at openjdk.java.net  Thu Dec 16 11:49:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 16 Dec 2021 11:49:59 GMT
Subject: RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <uu4PU0ezVUE7Qy7-aLBU6aEnT7xrFpwncLtFm9jVwCY=.235db977-f507-4c54-80f9-8f1fe5cc9138@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

Re-ran tier1+2 in our CI due to the mystery error in GHA testing. All passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6821

From redestad at openjdk.java.net  Thu Dec 16 11:49:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 16 Dec 2021 11:49:59 GMT
Subject: Integrated: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <qaJKA2VauCqOAoKCB_D_uiagh93BK0AMCEnbdVeVTHQ=.98aa989c-a0b6-44c9-bcf8-96345ff215cf@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

This pull request has now been integrated.

Changeset: aae56398
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aae563981c89d922c51005626b39c31e377cadc5
Stats:     333 lines in 1 file changed: 0 ins; 39 del; 294 mod

8278642: Refactor java.util.Formatter

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6821

From lancea at openjdk.java.net  Thu Dec 16 11:51:02 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 16 Dec 2021 11:51:02 GMT
Subject: [jdk18] RFR: 8278574: update --help-extra message to include
 default value of --finalization option
In-Reply-To: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
References: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
Message-ID: <_-lqMr3qcyCpC_tgF0Hgoq7Sbf2pWUjRMye_miETahg=.dba59770-f4f2-4eab-8ba7-623ad8b078e0@github.com>

On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A small modification to the Launcher's help text.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/34

From mcimadamore at openjdk.java.net  Thu Dec 16 12:39:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 16 Dec 2021 12:39:24 GMT
Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced
 correctly
Message-ID: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>

This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used.

For more details about the problem and the solution please refer to:
https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.java.net/jdk18/pull/37/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=37&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278897
  Stats: 600 lines in 20 files changed: 566 ins; 0 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk18/pull/37

From mcimadamore at openjdk.java.net  Thu Dec 16 12:39:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 16 Dec 2021 12:39:24 GMT
Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced
 correctly
In-Reply-To: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
References: <w1NvVtFnNkz2Bnj0FYsM9Ik7ESaRR6t6c-RzF9LPBAY=.789bd653-1d6b-4a85-86db-1fb35b3bf6b2@github.com>
Message-ID: <M761pO98FZkyV6ENtCe7ylk1sDnnwsOU8Ifi58-Dx_o=.3fe7d9c1-cf28-4381-bd66-cc859e808ad4@github.com>

On Thu, 16 Dec 2021 12:31:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used.
> 
> For more details about the problem and the solution please refer to:
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html

Javadoc: http://cr.openjdk.java.net/~mcimadamore/8278897/v1/javadoc/jdk/incubator/foreign/package-summary.html
Specdiff: http://cr.openjdk.java.net/~mcimadamore/8278897/v1/specdiff_out/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk18/pull/37

From mchung at openjdk.java.net  Thu Dec 16 17:29:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 16 Dec 2021 17:29:55 GMT
Subject: [jdk18] RFR: 8278574: update --help-extra message to include
 default value of --finalization option
In-Reply-To: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
References: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
Message-ID: <1OwFOq11DtZGKuinsQmPnl92EHP8tBDeOoquM3XyXj8=.44946584-6c51-480c-bafd-58518ee3088e@github.com>

On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A small modification to the Launcher's help text.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/34

From psandoz at openjdk.java.net  Thu Dec 16 17:36:00 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 17:36:00 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
 <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
 <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
Message-ID: <bWncss8LDtk0apr5KZxf283hotmn61QDbbkEag0FDnk=.1d84e3a7-d9a5-4fbb-9884-e9c56720aff9@github.com>

On Thu, 16 Dec 2021 05:55:14 GMT, kabutz <duke at openjdk.java.net> wrote:

>> This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.
>
>> This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.
> 
> Thank you so much Paul.

@kabutz @bplb CSR is created, can you please review?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From smarks at openjdk.java.net  Thu Dec 16 17:39:12 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 16 Dec 2021 17:39:12 GMT
Subject: [jdk18] Integrated: 8278574: update --help-extra message to include
 default value of --finalization option
In-Reply-To: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
References: <-OoAx4nPTjJuJS2U9djj2QGCXwh9Hwo7dYuCHQq0Yqc=.1f370d17-ade3-4305-b76c-c1f49c83abf3@github.com>
Message-ID: <gFw5AV_HLTQn3cxGObt8P5YiORd83KB9D2izSl1840I=.430cf088-8e5f-43ac-ada9-96c41755ef64@github.com>

On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A small modification to the Launcher's help text.

This pull request has now been integrated.

Changeset: be6b90d9
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/be6b90d90b54883ff17f9f5ac0f271de37df7e2a
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8278574: update --help-extra message to include default value of --finalization option

Reviewed-by: sundar, alanb, lancea, mchung

-------------

PR: https://git.openjdk.java.net/jdk18/pull/34

From vromero at openjdk.java.net  Thu Dec 16 17:52:24 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 16 Dec 2021 17:52:24 GMT
Subject: RFR: 8213905: reflection not working for type annotations applied to
 exception types in the inner class constructor
Message-ID: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>

Hi,

Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors it is always working on type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example.

TIA

-------------

Commit messages:
 - 8213905: Reflection, TYPE_USE annotation on THROWS on inner class constructor, Java 9+

Changes: https://git.openjdk.java.net/jdk/pull/6869/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6869&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8213905
  Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6869.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6869/head:pull/6869

PR: https://git.openjdk.java.net/jdk/pull/6869

From darcy at openjdk.java.net  Thu Dec 16 18:05:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 16 Dec 2021 18:05:03 GMT
Subject: RFR: 8213905: reflection not working for type annotations applied
 to exception types in the inner class constructor
In-Reply-To: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>
References: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>
Message-ID: <00jzdkBojXcuE-HYsvrNv4GMyLvoj4LGw9athZSU3Nw=.4931c7b1-b14b-46ee-9740-bdaaf1f10b10@github.com>

On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors it is always working on type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example.
> 
> TIA

Hi Vicente.

Please file a CSR for the behavioral change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6869

From naoto at openjdk.java.net  Thu Dec 16 18:41:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 16 Dec 2021 18:41:32 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug [v2]
In-Reply-To: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
Message-ID: <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>

> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects CSR comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6836/files
  - new: https://git.openjdk.java.net/jdk/pull/6836/files/1fcb399d..45bb8396

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6836&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6836&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6836.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6836/head:pull/6836

PR: https://git.openjdk.java.net/jdk/pull/6836

From duke at openjdk.java.net  Thu Dec 16 19:43:00 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 19:43:00 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
 <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
 <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
Message-ID: <lKbKMteCHXWi96AzbpjO2mENMQFRAyUHyabjkyvNYh8=.b23e98df-f975-4c72-96b4-06325da8da36@github.com>

On Thu, 16 Dec 2021 05:55:14 GMT, kabutz <duke at openjdk.java.net> wrote:

>> This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.
>
>> This is looking good. I will create the CSR and propose it. Since the holiday season is imminent it's likely no approval of the CSR will happen on until the new year.
> 
> Thank you so much Paul.

> @kabutz @bplb CSR is created, can you please review?

Terribly sorry to ask this, but where would I see the CSR? I don't have access to the JIRA in the backend.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From rriggs at openjdk.java.net  Thu Dec 16 19:45:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 16 Dec 2021 19:45:53 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug [v2]
In-Reply-To: <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
 <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
Message-ID: <g3scKZtOnDge6ir0wOb1Eo-1bk2aSGLiGp6pk_h80P4=.015062ad-8500-45f6-b740-f18c03423034@github.com>

On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects CSR comments.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From psandoz at openjdk.java.net  Thu Dec 16 19:49:00 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 19:49:00 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <lKbKMteCHXWi96AzbpjO2mENMQFRAyUHyabjkyvNYh8=.b23e98df-f975-4c72-96b4-06325da8da36@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
 <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
 <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
 <lKbKMteCHXWi96AzbpjO2mENMQFRAyUHyabjkyvNYh8=.b23e98df-f975-4c72-96b4-06325da8da36@github.com>
Message-ID: <Xx4RQtIoPAR6A-8oT5DQY1UZuAdhHXsd12ygrScZrRg=.d828b3cd-be11-4005-a868-f558713ef042@github.com>

On Thu, 16 Dec 2021 19:39:59 GMT, kabutz <duke at openjdk.java.net> wrote:

> Terribly sorry to ask this, but where would I see the CSR? I don't have access to the JIRA in the backend.

You should be able to view it but not edit:

  https://bugs.openjdk.java.net/browse/JDK-8278886

(To get creation/update access rights you need to become an OpenJDK author.)
 
If you have comments/edits the easier approach is to comment on this PR and I can update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From naoto at openjdk.java.net  Thu Dec 16 19:56:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 16 Dec 2021 19:56:20 GMT
Subject: RFR: 8278434: timeouts in test
 java/time/test/java/time/format/TestZoneTextPrinterParser.java
Message-ID: <TQOaPuDzIsAzUX5MjisR5RgnyIbE9fKQ4lWMfpCbLTA=.55e5ef68-ff89-4060-87fd-1ddef592987a@github.com>

The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions.
I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales.
In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result:

Before the fix to JDK-8275721:

Benchmark                    Mode  Cnt  Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  6.865 ? 0.696   s/op

Before the proposed fix:

Benchmark                    Mode  Cnt   Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  15.741 ? 4.300   s/op

After the proposed fix:

Benchmark                    Mode  Cnt  Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  9.756 ? 3.685   s/op

-------------

Commit messages:
 - Added a microbenchmark for zone strings
 - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java

Changes: https://git.openjdk.java.net/jdk/pull/6790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278434
  Stats: 72 lines in 3 files changed: 59 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6790/head:pull/6790

PR: https://git.openjdk.java.net/jdk/pull/6790

From darcy at openjdk.java.net  Thu Dec 16 19:58:57 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 16 Dec 2021 19:58:57 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug [v2]
In-Reply-To: <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
 <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
Message-ID: <kIJtsq3xFhOnIVhn8vutFwUziOwcSfI0hzWx1wBL1a4=.06922741-4985-47b8-96f2-3faa4009c80b@github.com>

On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects CSR comments.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From iris at openjdk.java.net  Thu Dec 16 19:58:58 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 16 Dec 2021 19:58:58 GMT
Subject: RFR: 8278587: StringTokenizer(String, String,
 boolean) documentation bug [v2]
In-Reply-To: <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
 <JjKpo_6SpDG1T7_b91VdAqfRjnqm0cdNi5BjLq74ns4=.f0e3afe7-deef-4f67-a357-ce042d35b6dd@github.com>
Message-ID: <szY2texFzLTkUzmzSNJsPtAdU6KuufW0m_U6i1n3_zY=.4267f9cb-95dc-4038-a3da-b7a878cef00b@github.com>

On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects CSR comments.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From duke at openjdk.java.net  Thu Dec 16 20:13:04 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 20:13:04 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
Message-ID: <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>

On Thu, 16 Dec 2021 06:07:29 GMT, kabutz <duke at openjdk.java.net> wrote:

>> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel.
>> 
>> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number.
>> 
>> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential.
>> 
>> Some benchmark results, run on my 1-6-2 server:
>> 
>> 
>> Benchmark                                          (n)  Mode  Cnt      Score      Error  Units
>> BigIntegerParallelMultiply.multiply            1000000    ss    4     51.707 ?   11.194  ms/op
>> BigIntegerParallelMultiply.multiply           10000000    ss    4    988.302 ?  235.977  ms/op
>> BigIntegerParallelMultiply.multiply          100000000    ss    4  24662.063 ? 1123.329  ms/op
>> BigIntegerParallelMultiply.parallelMultiply    1000000    ss    4     49.337 ?   26.611  ms/op
>> BigIntegerParallelMultiply.parallelMultiply   10000000    ss    4    527.560 ?  268.903  ms/op
>> BigIntegerParallelMultiply.parallelMultiply  100000000    ss    4   9076.551 ? 1899.444  ms/op
>> 
>> 
>> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed depth type to byte to save 8 bytes on each RecursiveSquare instance

"parallel multiple" -> "parallel multiply"

"embarrassingly parallel when employing recursive" -> "embarrassingly non-parallel when employing recursive" (?)

Even though it is technically bound by number of threads in the common pool (or whichever pool is executing the parallelMultiply()), I think that "bounded by the number of runtime processors" is close enough :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 20:19:01 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 20:19:01 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v6]
In-Reply-To: <Xx4RQtIoPAR6A-8oT5DQY1UZuAdhHXsd12ygrScZrRg=.d828b3cd-be11-4005-a868-f558713ef042@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <LZeaF3-e0JEXiXOKXwnSXWpdPk_69noiu8VzVKF-UVw=.792bf882-95a4-4a49-8eae-c5f19e6e4480@github.com>
 <IBO3A11LH8dppkKQ2HQzmsFH1kPdup-aqaF9CqTouIQ=.f810ae3a-032e-4834-bb48-d88173bfd9fa@github.com>
 <7_QBDQQ-vV786GawQv_bDHDZUhT88gjYLOQcpQafWw4=.e8c8fa87-567e-4a7c-9275-dddaefc61329@github.com>
 <lKbKMteCHXWi96AzbpjO2mENMQFRAyUHyabjkyvNYh8=.b23e98df-f975-4c72-96b4-06325da8da36@github.com>
 <Xx4RQtIoPAR6A-8oT5DQY1UZuAdhHXsd12ygrScZrRg=.d828b3cd-be11-4005-a868-f558713ef042@github.com>
Message-ID: <UHW0myefp596ARf1qREeFLkt7SR5JzAz_D-ZyXBnGMQ=.70b7ae58-0493-4dfd-a347-e3da5bd7c3f0@github.com>

On Thu, 16 Dec 2021 19:46:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Terribly sorry to ask this, but where would I see the CSR? I don't have access to the JIRA in the backend.
> 
> You should be able to view it but not edit:
> 
> https://bugs.openjdk.java.net/browse/JDK-8278886
> 
> (To get creation/update access rights you need to become an OpenJDK author.)
> 
> If you have comments/edits the easier approach is to comment on this PR and I can update.

And thank you very much, @PaulSandoz, @jddarcy, @dholmes-ora, @cl4es, @fisk, @bplb, and others on the mailing list for taking the time to review this proposal and to help improve on my original idea :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 20:48:39 2021
From: duke at openjdk.java.net (liach)
Date: Thu, 16 Dec 2021 20:48:39 GMT
Subject: RFR: JDK-8277520: Implement JDK-8 default methods for
 IdentityHashMap [v2]
In-Reply-To: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
References: <pz8KnSyGIbC_5FThfEKEeVxNarwKan2d0_2DNQamip8=.84a9487e-69b8-40d4-a018-6b9e45162e75@github.com>
Message-ID: <Lppaa2nCSXWrvbbbWyQw1eatqqEJDcKguCZFc020lxo=.93ec26cb-fd9f-4897-be64-b22afb1520c0@github.com>

> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes.

liach has updated the pull request 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://git.openjdk.java.net/jdk into identityhashmap-default
 - update dates
 - Also test cme for identity hash map
 - Fix putIfAbsent
 - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6532/files
  - new: https://git.openjdk.java.net/jdk/pull/6532/files/e492cb7b..d853ab34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=00-01

  Stats: 57223 lines in 1494 files changed: 36387 ins; 12123 del; 8713 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6532.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6532/head:pull/6532

PR: https://git.openjdk.java.net/jdk/pull/6532

From lancea at openjdk.java.net  Thu Dec 16 20:48:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 16 Dec 2021 20:48:59 GMT
Subject: RFR: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases. [v2]
In-Reply-To: <3oSKuAouBjDZ4sRQ0u_v3lroJ_jqdy2B9bhfs4W4t0k=.d58ef637-bd84-4826-9008-aee04449aaa4@github.com>
References: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
 <3oSKuAouBjDZ4sRQ0u_v3lroJ_jqdy2B9bhfs4W4t0k=.d58ef637-bd84-4826-9008-aee04449aaa4@github.com>
Message-ID: <gQ_p27PO1H1t5QGGaztK7xLkELVUUo-W0O42rcR9Btk=.856600ca-b709-4000-8260-6ecdea3373ae@github.com>

On Mon, 6 Dec 2021 16:01:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.
>> 
>> In both constructors, add the following to the paragraph the describes invoking the factory:
>> 
>>      * When the filter factory {@code apply} method is invoked it may throw a runtime exception
>>      * preventing the {@code ObjectInputStream} from being constructed.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified that a runtime exception may be thrown by the filter factory returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
>   not by the `getSerialFilterFactory` method.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6704

From lancea at openjdk.java.net  Thu Dec 16 20:51:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 16 Dec 2021 20:51:59 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified [v2]
In-Reply-To: <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
Message-ID: <I92T8GHkFPOU9_8Vh-X7OveGXcpuqpSQ1k4luZOuQck=.c1ecde55-5946-429a-9e3e-ce973297edbf@github.com>

On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments to consistently identify security property names
>   and use the correct bug number in the test.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6645

From duke at openjdk.java.net  Thu Dec 16 21:13:12 2021
From: duke at openjdk.java.net (liach)
Date: Thu, 16 Dec 2021 21:13:12 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe
Message-ID: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>

Simply changes this to only read the static field once to prevent `null` on second read.

-------------

Commit messages:
 - 8261404: Class.getReflectionFactory() is not thread-safe

Changes: https://git.openjdk.java.net/jdk/pull/6870/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6870&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261404
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6870.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6870/head:pull/6870

PR: https://git.openjdk.java.net/jdk/pull/6870

From rriggs at openjdk.java.net  Thu Dec 16 21:24:57 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 16 Dec 2021 21:24:57 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe
In-Reply-To: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
Message-ID: <QUGk05Pcfk4YShQQl6GHnhLxCgOmbZuLPCJOK9bHqjg=.39c63ecd-82d5-475a-81bd-a46ff6e6fc48@github.com>

On Thu, 16 Dec 2021 21:04:58 GMT, liach <duke at openjdk.java.net> wrote:

> Simply changes this to only read the static field once to prevent `null` on second read.

It would be easier to read and clearer if the local was not named the same as the static.

-------------

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6870

From psandoz at openjdk.java.net  Thu Dec 16 21:25:01 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 21:25:01 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
 <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
Message-ID: <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>

On Thu, 16 Dec 2021 20:09:59 GMT, kabutz <duke at openjdk.java.net> wrote:

> "embarrassingly parallel when employing recursive" -> "embarrassingly non-parallel when employing recursive" (?)

I corrected to "embarrassingly parallelizable" (i believe that is a common phrase we as software engineers use in these cases).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 21:34:03 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 21:34:03 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
 <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
 <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>
Message-ID: <bsKbooooUK8CjUzEAF28HAZGPsgL3QlS_C_0cxxzvug=.62b61b9f-2520-48af-ac9d-c725c0df6019@github.com>

On Thu, 16 Dec 2021 21:22:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > "embarrassingly parallel when employing recursive" -> "embarrassingly non-parallel when employing recursive" (?)
> 
> I corrected to "embarrassingly parallelizable" (i believe that is a common phrase we as software engineers use in these cases).

Makes more sense that way. Should we add something about it not being computationally worthwhile doing for the Karatsuba calculation, which is even easier to parallelize, but which has a lower threshold and thus does not give performance advantages?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From rriggs at openjdk.java.net  Thu Dec 16 21:34:58 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 16 Dec 2021 21:34:58 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe
In-Reply-To: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
Message-ID: <mSjUfgSgDNnJRXP6APywMK2QCqiXTYpEMOVRchnRcOI=.eda51bf1-53d8-40ef-904f-af261e64b8cc@github.com>

On Thu, 16 Dec 2021 21:04:58 GMT, liach <duke at openjdk.java.net> wrote:

> Simply changes this to only read the static field once to prevent `null` on second read.

src/java.base/share/classes/java/lang/Class.java line 3828:

> 3826:                 java.security.AccessController.doPrivileged
> 3827:                     (new ReflectionFactory.GetReflectionFactoryAction());
> 3828:         }

p.s.  If using an early return, I'd have it return early in the case reflectionFactory was not-null.
then fall through to compute and assign the factory and return it.

        var factory = reflectionFactory;
        if (factory != null) {
            return factory;
        }
        return reflectionFactory =
            java.security.AccessController.doPrivileged
                (new ReflectionFactory.GetReflectionFactoryAction());

-------------

PR: https://git.openjdk.java.net/jdk/pull/6870

From duke at openjdk.java.net  Thu Dec 16 21:38:30 2021
From: duke at openjdk.java.net (liach)
Date: Thu, 16 Dec 2021 21:38:30 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
In-Reply-To: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
Message-ID: <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>

> Simply changes this to only read the static field once to prevent `null` on second read.

liach has updated the pull request incrementally with two additional commits since the last revision:

 - sorry, reintroduced the bug in last patch
 - choose a concise name for the local var

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6870/files
  - new: https://git.openjdk.java.net/jdk/pull/6870/files/2f7c84a1..acc043ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6870&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6870&range=00-01

  Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6870.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6870/head:pull/6870

PR: https://git.openjdk.java.net/jdk/pull/6870

From duke at openjdk.java.net  Thu Dec 16 21:41:07 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 21:41:07 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <bsKbooooUK8CjUzEAF28HAZGPsgL3QlS_C_0cxxzvug=.62b61b9f-2520-48af-ac9d-c725c0df6019@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
 <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
 <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>
 <bsKbooooUK8CjUzEAF28HAZGPsgL3QlS_C_0cxxzvug=.62b61b9f-2520-48af-ac9d-c725c0df6019@github.com>
Message-ID: <WbEUYelHNz31mZOUkRBVe9EQbg1qlNGLZVwwMbnLuvI=.03eab4b7-5381-464b-be31-5cfac7a4c3be@github.com>

On Thu, 16 Dec 2021 21:30:21 GMT, kabutz <duke at openjdk.java.net> wrote:

> embarrassingly parallelizable

Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From duke at openjdk.java.net  Thu Dec 16 21:42:05 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 16 Dec 2021 21:42:05 GMT
Subject: Integrated: 8277868: Use Comparable.compare() instead of surrogate
 code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <5ZOhPiacNs5fjMH_6weWYlaPWVSqPMvRAXY2iT_6T68=.3e2499b4-45e6-497c-b5c0-d549d7c324e2@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

This pull request has now been integrated.

Changeset: 20db7800
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/20db7800a657b311eeac504a2bbae4adbc209dbf
Stats:     77 lines in 12 files changed: 2 ins; 54 del; 21 mod

8277868: Use Comparable.compare() instead of surrogate code

Reviewed-by: rriggs, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575

From naoto at openjdk.java.net  Thu Dec 16 21:45:02 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 16 Dec 2021 21:45:02 GMT
Subject: Integrated: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
In-Reply-To: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
References: <udF_JjM1X8ZLeSDYuIoFLMr8e-Yqiqgq7Rf3_xIPtww=.efd26458-3af1-4c0a-9d35-c22e97299e10@github.com>
Message-ID: <7E5Z1AROEuM4WuT9jbv6Y6bqWllk8It-Lci000aVoDc=.9168feb0-ba4e-4e95-a54e-7a12d3ca6bce@github.com>

On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc fix to `StringTokenizer`, where the original spec does not account for the delimiter's length in the case of a supplementary character. Corresponding CSR has been drafted: https://bugs.openjdk.java.net/browse/JDK-8278814

This pull request has now been integrated.

Changeset: 8f5fdd86
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8f5fdd864b6f1cf4a2d9d961d8d4118960f0751e
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8278587: StringTokenizer(String, String, boolean) documentation bug

Reviewed-by: iris, joehw, lancea, rriggs, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/6836

From duke at openjdk.java.net  Thu Dec 16 21:51:04 2021
From: duke at openjdk.java.net (kabutz)
Date: Thu, 16 Dec 2021 21:51:04 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <WbEUYelHNz31mZOUkRBVe9EQbg1qlNGLZVwwMbnLuvI=.03eab4b7-5381-464b-be31-5cfac7a4c3be@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
 <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
 <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>
 <bsKbooooUK8CjUzEAF28HAZGPsgL3QlS_C_0cxxzvug=.62b61b9f-2520-48af-ac9d-c725c0df6019@github.com>
 <WbEUYelHNz31mZOUkRBVe9EQbg1qlNGLZVwwMbnLuvI=.03eab4b7-5381-464b-be31-5cfac7a4c3be@github.com>
Message-ID: <IOufNOv6qkINBOXoKAi5TUehs_Zfq89wcYzJfgNFKF0=.4681f095-cf37-485d-8ba9-9f58b169c1e3@github.com>

On Thu, 16 Dec 2021 21:37:26 GMT, kabutz <duke at openjdk.java.net> wrote:

> > embarrassingly parallelizable
> 
> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that.

I ran fibonacci(100_000_000) with multiply() and parallelMultiply(). For multiply() we had:


real	0m25.627s
user	0m26.767s
sys	0m1.197s


and for parallelMultiply() we had


real	0m10.030s
user	1m2.205s
sys	0m2.489s


Thus we are 2.5 times faster on a 1-6-2 machine, but use more than 2x the user time. If it were perfectly parallel, shouldn't we expect to see the parallelMultiply() be close to user time of 26s and real time 4.3s?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From bpb at openjdk.java.net  Thu Dec 16 21:52:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 16 Dec 2021 21:52:02 GMT
Subject: RFR: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases. [v2]
In-Reply-To: <3oSKuAouBjDZ4sRQ0u_v3lroJ_jqdy2B9bhfs4W4t0k=.d58ef637-bd84-4826-9008-aee04449aaa4@github.com>
References: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
 <3oSKuAouBjDZ4sRQ0u_v3lroJ_jqdy2B9bhfs4W4t0k=.d58ef637-bd84-4826-9008-aee04449aaa4@github.com>
Message-ID: <3OPSyXIySbKmXhzKoHhlRpAeHIAlw9c1T-YvVjaa1es=.ae7d97c0-1538-4839-bed1-d1848d31ea9c@github.com>

On Mon, 6 Dec 2021 16:01:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.
>> 
>> In both constructors, add the following to the paragraph the describes invoking the factory:
>> 
>>      * When the filter factory {@code apply} method is invoked it may throw a runtime exception
>>      * preventing the {@code ObjectInputStream} from being constructed.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified that a runtime exception may be thrown by the filter factory returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
>   not by the `getSerialFilterFactory` method.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6704

From psandoz at openjdk.java.net  Thu Dec 16 21:58:00 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 16 Dec 2021 21:58:00 GMT
Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
 [v7]
In-Reply-To: <IOufNOv6qkINBOXoKAi5TUehs_Zfq89wcYzJfgNFKF0=.4681f095-cf37-485d-8ba9-9f58b169c1e3@github.com>
References: <nkxTdYyIuKJq1uedATWVxvkygrZYbNM_dZm3uz1y_8g=.62f59b7c-cd6d-483d-ba6c-07a1e870eac5@github.com>
 <L4pKktt-SggFl92iDTjBuKxnIDNfbMSC53_ztrSBqKY=.98c9cce4-6cc9-41b0-bbd5-0a942a407cf3@github.com>
 <P4LX0ZjLFLLVDvt14Y4OZuuMXuDu0LFqOHDIi-DIjE0=.6ec5eaf8-b36c-4741-86f1-21ebe6f9d449@github.com>
 <pT4MbQ2kvssqYjh09sUdZP0e0Xp92GEHWRpCmGIY7qU=.986c1841-17d3-4982-8a63-5de7492d66f6@github.com>
 <bsKbooooUK8CjUzEAF28HAZGPsgL3QlS_C_0cxxzvug=.62b61b9f-2520-48af-ac9d-c725c0df6019@github.com>
 <WbEUYelHNz31mZOUkRBVe9EQbg1qlNGLZVwwMbnLuvI=.03eab4b7-5381-464b-be31-5cfac7a4c3be@github.com>
 <IOufNOv6qkINBOXoKAi5TUehs_Zfq89wcYzJfgNFKF0=.4681f095-cf37-485d-8ba9-9f58b169c1e3@github.com>
Message-ID: <HIqAYMSj8Uv12IklHFfLvPSPHXw9bMzLI9lDc5hysrs=.03dad017-8107-4feb-8767-eac1b49221a6@github.com>

On Thu, 16 Dec 2021 21:48:14 GMT, kabutz <duke at openjdk.java.net> wrote:

> > embarrassingly parallelizable
> 
> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that.

Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6409

From mr at openjdk.java.net  Thu Dec 16 22:27:29 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 16 Dec 2021 22:27:29 GMT
Subject: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version
 =?UTF-8?B?c3BlY2lmaWNhdGlvbuKAmXM=?= treatment of repeated punctuation
 characters
Message-ID: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>

Please review this tiny specification clarification.

-------------

Commit messages:
 - 8278465: Clarify the ModuleDescriptor.Version specification?s treatment of repeated punctuation characters

Changes: https://git.openjdk.java.net/jdk18/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=39&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276826
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/39/head:pull/39

PR: https://git.openjdk.java.net/jdk18/pull/39

From mr at openjdk.java.net  Thu Dec 16 22:27:33 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 16 Dec 2021 22:27:33 GMT
Subject: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version
 =?UTF-8?B?c3BlY2lmaWNhdGlvbuKAmXM=?= treatment of repeated punctuation
 characters
In-Reply-To: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
References: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
Message-ID: <Xghss9xbMo3K3wYaUEVUk0GtwTXytidm6cA25DFG3OM=.45add7c5-4225-4f4d-9f45-b288ac817112@github.com>

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please review this tiny specification clarification.

Drat, used the wrong bug id.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/39

From vromero at openjdk.java.net  Thu Dec 16 22:39:23 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 16 Dec 2021 22:39:23 GMT
Subject: RFR: 8213905: reflection not working for type annotations applied
 to exception types in the inner class constructor
In-Reply-To: <00jzdkBojXcuE-HYsvrNv4GMyLvoj4LGw9athZSU3Nw=.4931c7b1-b14b-46ee-9740-bdaaf1f10b10@github.com>
References: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>
 <00jzdkBojXcuE-HYsvrNv4GMyLvoj4LGw9athZSU3Nw=.4931c7b1-b14b-46ee-9740-bdaaf1f10b10@github.com>
Message-ID: <efoOQuh9HBSSd1hu4ySkMwlfBydLFyDGLICSUbAzK5o=.1842237a-293b-4ce6-b810-734475d783d1@github.com>

On Thu, 16 Dec 2021 18:01:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hi Vicente.
> 
> Please file a CSR for the behavioral change.

sure, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6869

From bpb at openjdk.java.net  Thu Dec 16 22:48:37 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 16 Dec 2021 22:48:37 GMT
Subject: RFR: 8278087: Deserialization filter and filter factory property
 error reporting under specified [v2]
In-Reply-To: <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
 <Zptqp3YmBScAE5Et6xP5Z9tNGhr6VFI9Z9okjM59pm8=.0a2a462d-de26-4bf2-81c5-aab65f7f37ea@github.com>
Message-ID: <Q6VAbV9kvaaGhEq2t_3Jqcn4ZlJyLCvBB9YoXvE7Rzg=.3aab11c2-a614-4c5c-9db2-e4af2e756a92@github.com>

On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
>> incompletely specified. The behavior for invalid values of the properties is different and
>> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
>> uninitialized. 
>> 
>> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
>> either by system properties supplied on the command line or security properties are logged.
>> The `Config` class marks either or both the filter and filter factory values as unusable
>> and remembers the exception message.
>> 
>> Subsequent calls to the methods that get or set the filter or filter factory or create 
>> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
>> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
>> The nature of the invalid property is reported as an `IllegalStateException` on first use.
>> 
>> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments to consistently identify security property names
>   and use the correct bug number in the test.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6645

From mchung at openjdk.java.net  Thu Dec 16 22:54:28 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 16 Dec 2021 22:54:28 GMT
Subject: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version
 =?UTF-8?B?c3BlY2lmaWNhdGlvbuKAmXM=?= treatment of repeated punctuation
 characters
In-Reply-To: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
References: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
Message-ID: <safzLvpueVc-LZv4SLUJJoNTifSw5COMAFMJz60dINk=.8409c997-cd43-430f-9f70-0ac5a159183b@github.com>

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please review this tiny specification clarification.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/39

From darcy at openjdk.java.net  Thu Dec 16 22:54:28 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 16 Dec 2021 22:54:28 GMT
Subject: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version
 =?UTF-8?B?c3BlY2lmaWNhdGlvbuKAmXM=?= treatment of repeated punctuation
 characters
In-Reply-To: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
References: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
Message-ID: <WVkffdpVfvNL8OhWShurHx3-HNYpLD15bdIhGzPYCyI=.46fe6007-ba43-44fb-8e96-e227a6bfe844@github.com>

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please review this tiny specification clarification.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/39

From mchung at openjdk.java.net  Thu Dec 16 22:56:13 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 16 Dec 2021 22:56:13 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
In-Reply-To: <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
 <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
Message-ID: <DH7DpqGOY3yOriWfNdVzuGT3M7UQSe6ubV83CLfq-7s=.73e244eb-0360-4a53-9c26-83a0aa582a50@github.com>

On Thu, 16 Dec 2021 21:38:30 GMT, liach <duke at openjdk.java.net> wrote:

>> Simply changes this to only read the static field once to prevent `null` on second read.
>
> liach has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - sorry, reintroduced the bug in last patch
>  - choose a concise name for the local var

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6870

From jwilhelm at openjdk.java.net  Fri Dec 17 00:15:11 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 17 Dec 2021 00:15:11 GMT
Subject: RFR: Merge jdk18
Message-ID: <DREYsHaqGfaQInC9SN9rUYoK5oBm-xpsK9cQiT2rKyU=.e4f9f165-3dda-4200-b7dc-e280a86dcb5d@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8278574: update --help-extra message to include default value of --finalization option
 - 8278389: SuspendibleThreadSet::_suspend_all should be volatile/atomic
 - 8278575: update jcmd GC.finalizer_info to list finalization status

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6873&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6873&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6873/files
  Stats: 29 lines in 4 files changed: 12 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6873.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6873/head:pull/6873

PR: https://git.openjdk.java.net/jdk/pull/6873

From mr at openjdk.java.net  Fri Dec 17 00:37:31 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Fri, 17 Dec 2021 00:37:31 GMT
Subject: [jdk18] Integrated: 8276826: Clarify the ModuleDescriptor.Version
 =?UTF-8?B?c3BlY2lmaWNhdGlvbuKAmXM=?= treatment of repeated punctuation
 characters
In-Reply-To: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
References: <H4_pxkxj_Uemv_VhRK47ZvTQ5OXRm-dW_yVW2lHqPOU=.9223d022-971f-48a9-b667-9217deda9510@github.com>
Message-ID: <cbJQNPkY3dWST37yw5wA8n3_QsRfKSX5GAQtIaZSioc=.70a0cce2-cf9d-4285-8b45-9dfbb9ac97f6@github.com>

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please review this tiny specification clarification.

This pull request has now been integrated.

Changeset: f5d7c777
Author:    Mark Reinhold <mr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/f5d7c777bc516fa2e711c19d5281ebf32384b543
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8276826: Clarify the ModuleDescriptor.Version specification?s treatment of repeated punctuation characters

Reviewed-by: mchung, darcy

-------------

PR: https://git.openjdk.java.net/jdk18/pull/39

From jwilhelm at openjdk.java.net  Fri Dec 17 01:11:29 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 17 Dec 2021 01:11:29 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <DREYsHaqGfaQInC9SN9rUYoK5oBm-xpsK9cQiT2rKyU=.e4f9f165-3dda-4200-b7dc-e280a86dcb5d@github.com>
References: <DREYsHaqGfaQInC9SN9rUYoK5oBm-xpsK9cQiT2rKyU=.e4f9f165-3dda-4200-b7dc-e280a86dcb5d@github.com>
Message-ID: <aGuff5ADnmjEsVZ2AL2Mo1hno4780mcw-LKo0J0AIfM=.d0baabe6-0827-40b9-add6-6691a3a32354@github.com>

On Fri, 17 Dec 2021 00:05:41 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 634afe8c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/634afe8c5c0855eafb1639f54ecc8e9c9e568814
Stats:     29 lines in 4 files changed: 12 ins; 1 del; 16 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6873

From duke at openjdk.java.net  Fri Dec 17 03:11:31 2021
From: duke at openjdk.java.net (liach)
Date: Fri, 17 Dec 2021 03:11:31 GMT
Subject: RFR: 8213905: reflection not working for type annotations applied
 to exception types in the inner class constructor
In-Reply-To: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>
References: <EZuUPGNz_2P6C-6zblfjUXPBLvO4UlEhRTDL9pYUWS8=.1620a021-42bd-4c68-9d32-873bf86c8465@github.com>
Message-ID: <hOA9dn2bCuVnBtlARo_UJRc7zItAVahnICxJikvHoFo=.a43a28b0-955a-4365-a69b-cae105a0adad@github.com>

On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors it is always working on type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example. This bug affects the behavior of method: `java.lang.reflect.Executable::getAnnotatedExceptionTypes` which is not behaving according to its specification. Given that this fix affects the behavior of a method belonging to our API a CSR has been filed too. Please review it at [JDK-8278926](https://bugs.openjdk.java.net/browse/JDK-8278926).
> 
> TIA

src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java line 137:

> 135:                  (declaringClass.getModifiers() & Modifier.STATIC) == 0) &&
> 136:                  filter == TypeAnnotation.TypeAnnotationTarget.METHOD_FORMAL_PARAMETER) {
> 137:                 offset = true;

Currently, we have a few parallel systems for determining if certain parameters are synthetic. This guessing by being inner classes or enums is one, and detecting the flags from `MethodParameters` attribute (used for handling signatures) is another. (In fact, both are present in `Executable` in `handleParameterNumberMismatch` and `getAllGenericParameterTypes`)

Detecting `MethodParameters` attribute should be more reliable, especially for other code that may include methods with any number of synthetic or mandated parameters (presumably in the beginning of the parameter list). However, javac will not produce that attribute without `-parameters` flag, so most class files compiled to be missing this attribute.

IMO a longer-term solution is to opt-in Javac to emit critical method parameter information by default (ex. emit the parameter flags without names) whenever it emits parameter signatures or annotations. And then the system for skipping synthetic/mandated parameters in the two places may possibly be unified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6869

From almatvee at openjdk.java.net  Fri Dec 17 03:34:50 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 17 Dec 2021 03:34:50 GMT
Subject: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed
 with runtime exception
Message-ID: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>

This is regression from JDK-8263155. MacHelper.java is now calling test verification callback with all content in DMG root. SigningPackageTest expects only path with app name in it and thus it fails when trying to verify app inside ".background" folder. Fixed by checking that provided path for verification is actually an application we expecting. All other paths are ignored.

-------------

Commit messages:
 - 8278907: JPackage test - SigningPackageTest is failed with runtime exception

Changes: https://git.openjdk.java.net/jdk18/pull/42/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=42&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278907
  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/42/head:pull/42

PR: https://git.openjdk.java.net/jdk18/pull/42

From naoto at openjdk.java.net  Fri Dec 17 13:52:44 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 17 Dec 2021 13:52:44 GMT
Subject: [jdk18] Integrated: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
Message-ID: <l7fL8ijn2Eh_EMaEPn5rodqfwbf7p-ScmjnS_6Ak1JU=.a2067050-9b96-4691-9080-5f4280d2f4fb@github.com>

8278587: StringTokenizer(String, String, boolean) documentation bug

-------------

Commit messages:
 - Backport 8f5fdd864b6f1cf4a2d9d961d8d4118960f0751e

Changes: https://git.openjdk.java.net/jdk18/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=43&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278587
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/43/head:pull/43

PR: https://git.openjdk.java.net/jdk18/pull/43

From naoto at openjdk.java.net  Fri Dec 17 13:52:44 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 17 Dec 2021 13:52:44 GMT
Subject: [jdk18] Integrated: 8278587: StringTokenizer(String, String,
 boolean) documentation bug
In-Reply-To: <l7fL8ijn2Eh_EMaEPn5rodqfwbf7p-ScmjnS_6Ak1JU=.a2067050-9b96-4691-9080-5f4280d2f4fb@github.com>
References: <l7fL8ijn2Eh_EMaEPn5rodqfwbf7p-ScmjnS_6Ak1JU=.a2067050-9b96-4691-9080-5f4280d2f4fb@github.com>
Message-ID: <AHqJM3u45R_2aAmD9ieco457SC9nAid8oo7D2VMwNfE=.527412d6-f952-485d-8b4d-0701fc4c794b@github.com>

On Fri, 17 Dec 2021 13:41:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8278587: StringTokenizer(String, String, boolean) documentation bug

This pull request has now been integrated.

Changeset: 9cd70906
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/9cd709060cf0244ddb71225b55ea4e3e7f41860e
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8278587: StringTokenizer(String, String, boolean) documentation bug

Backport-of: 8f5fdd864b6f1cf4a2d9d961d8d4118960f0751e

-------------

PR: https://git.openjdk.java.net/jdk18/pull/43

From herrick at openjdk.java.net  Fri Dec 17 14:45:29 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 17 Dec 2021 14:45:29 GMT
Subject: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed
 with runtime exception
In-Reply-To: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
References: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
Message-ID: <yQ7ytr6jyr6Z34bri1mTo7xl_2woo8HYk0ePodEPBnQ=.7f032eb3-4621-4a62-9107-72edd3b59439@github.com>

On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8263155. MacHelper.java is now calling test verification callback with all content in DMG root. SigningPackageTest expects only path with app name in it and thus it fails when trying to verify app inside ".background" folder. Fixed by checking that provided path for verification is actually an application we expecting. All other paths are ignored.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/42

From rriggs at openjdk.java.net  Fri Dec 17 15:06:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 15:06:27 GMT
Subject: RFR: 8277868: Use Comparable.compare() instead of surrogate code
 [v6]
In-Reply-To: <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
Message-ID: <GxSLYrrtSHkak2yRopMZZvKVbrsN7qFo-2BmNFUANt8=.aff00657-cdd8-4d5c-b57a-096d3fa68d08@github.com>

On Thu, 9 Dec 2021 13:03:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8277868: Use Long.compare() for mostSigBits as well
>  - Revert "8277868: Adjust JavaDoc of UUID"
>    
>    This reverts commit f3b95d0e247cf6452955f4f24684fd60d5cb8902.

As it turns out replacing the code was not 100% equivalent and a test failure resulted.
See https://bugs.openjdk.java.net/browse/JDK-8278937

Double.compare and the original code handle the non-numeric forms of Double differently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575

From rriggs at openjdk.java.net  Fri Dec 17 15:26:29 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 15:26:29 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
In-Reply-To: <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
 <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
Message-ID: <Xu2FOjtRh1rLgj5P0of4l_gowp6EzJO8yD8e8c8Tfps=.367fc65d-3495-415a-a122-bef50aa8a6ec@github.com>

On Thu, 16 Dec 2021 21:38:30 GMT, liach <duke at openjdk.java.net> wrote:

>> Simply changes this to only read the static field once to prevent `null` on second read.
>
> liach has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - sorry, reintroduced the bug in last patch
>  - choose a concise name for the local var

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6870

From duke at openjdk.java.net  Fri Dec 17 15:54:32 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Fri, 17 Dec 2021 15:54:32 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <HyWOGpuovaVKmHSo1ZyndcWQ1QqEwWdLO9OU29i3HLQ=.816f5e43-64f2-4ef7-b5f5-791e5b90099d@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
 <HyWOGpuovaVKmHSo1ZyndcWQ1QqEwWdLO9OU29i3HLQ=.816f5e43-64f2-4ef7-b5f5-791e5b90099d@github.com>
Message-ID: <Nw_BsUrCPK4FBeQ9oQYjGoEnyV72rXShBL6tUUe9mk8=.03ef2f9e-1454-427a-87ea-4a91844f2f68@github.com>

On Thu, 12 Aug 2021 01:04:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Draft: Eliminated duplicate code using lambda expressions
>>  - Draft: Use blocking mode also for target channel
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 249:
> 
>> 247:     }
>> 248: 
>> 249:     private static long transfer(ReadableByteChannel src, WritableByteChannel dst) throws IOException {
> 
> Does this method have a measurable improvement in performance over `InputStream.transferTo()`?

Measured it today, here are the actual results:

Sandbox.transferTo  thrpt   25  0,091 ? 0,011  ops/s -- using byte[] (original implementation)
Sandbox.transferTo  thrpt   25  0,095 ? 0,012  ops/s -- using utility temporary buffer (my contribution)
Sandbox.transferTo  thrpt   23  0,099 ? 0,012  ops/s -- FileChannel.transferTo(FileChannel)


The improvement of this method actually is approx. 4% on my Windows laptop, which I would say is worth to do it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From asemenyuk at openjdk.java.net  Fri Dec 17 19:01:28 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 17 Dec 2021 19:01:28 GMT
Subject: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed
 with runtime exception
In-Reply-To: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
References: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
Message-ID: <9ahqwxvU465aAbGnGXecIOKaXU-Am6cCUCvCFTZgGKU=.efdd5889-3b78-4a20-af91-78855b82943c@github.com>

On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8263155. MacHelper.java is now calling test verification callback with all content in DMG root. SigningPackageTest expects only path with app name in it and thus it fails when trying to verify app inside ".background" folder. Fixed by checking that provided path for verification is actually an application we expecting. All other paths are ignored.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/42

From duke at openjdk.java.net  Fri Dec 17 19:18:25 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 17 Dec 2021 19:18:25 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <jOAUBxJyj3Ql5Ymz_8ZlEIdIQWJ8ehOXPDXfM8skOPs=.c55d842c-c02b-4443-b383-64e71b24e800@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
 <Zh9_zXLEKBICwX17eHY1XM2VtMuOISsHF2Fnwctbkqw=.19a5709e-5b59-4917-92c8-3bb0ab16d20a@github.com>
 <lhMb3bMFD4zYUWctYIERO3QAQ9qkJRj0vVDoNvn5rPs=.1d8f2d64-187f-48ae-8b1c-180cfb2feb13@github.com>
 <jOAUBxJyj3Ql5Ymz_8ZlEIdIQWJ8ehOXPDXfM8skOPs=.c55d842c-c02b-4443-b383-64e71b24e800@github.com>
Message-ID: <o-j1ZVaInqMB-lelkiF1jwlaq5S9Kl1R5OE--TaBHB4=.8d65a122-dbef-47e9-b43e-eb482ad49d30@github.com>

On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi @AlekseiEfimov 
>> 
>> Can you please review the CSR [1]?
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959
>
>> @martinuy 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!
> 
> Please do not close, waiting for CSR approval.

@martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened?

The purpose of JDK-8160768 was to discover LDAP servers and connect to the first one reachable. BTW, this code has been running for years now at work: https://github.com/michael-o/activedirectory-dns-locator

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From duke at openjdk.java.net  Fri Dec 17 19:31:32 2021
From: duke at openjdk.java.net (Michael Osipov)
Date: Fri, 17 Dec 2021 19:31:32 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <jOAUBxJyj3Ql5Ymz_8ZlEIdIQWJ8ehOXPDXfM8skOPs=.c55d842c-c02b-4443-b383-64e71b24e800@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
 <Zh9_zXLEKBICwX17eHY1XM2VtMuOISsHF2Fnwctbkqw=.19a5709e-5b59-4917-92c8-3bb0ab16d20a@github.com>
 <lhMb3bMFD4zYUWctYIERO3QAQ9qkJRj0vVDoNvn5rPs=.1d8f2d64-187f-48ae-8b1c-180cfb2feb13@github.com>
 <jOAUBxJyj3Ql5Ymz_8ZlEIdIQWJ8ehOXPDXfM8skOPs=.c55d842c-c02b-4443-b383-64e71b24e800@github.com>
Message-ID: <t8Jvgd3dNGxAB5Uo3X2XvabIKb_wFvsURlpUJlIBQZc=.780b83e6-e875-41e8-a229-c1536f5287a5@github.com>

On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi @AlekseiEfimov 
>> 
>> Can you please review the CSR [1]?
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959
>
>> @martinuy 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!
> 
> Please do not close, waiting for CSR approval.

@martinuy Also your Compatibility Risk talks about KDCs, but this is about directory servers. Not sure how this relates here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From rriggs at openjdk.java.net  Fri Dec 17 20:45:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 20:45:25 GMT
Subject: RFR: 8278831: Use table lookup for the last two bytes in
 Integer.getChars
In-Reply-To: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com>
References: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com>
Message-ID: <vmXOVyMH6HkE0HUi2r-fe-JmRcwP0rPFBCuY-Jz3yNI=.25ed455d-5b45-4b1f-ac26-6a20e1334377@github.com>

On Wed, 15 Dec 2021 23:04:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During TemplatedStrings work Jim has noticed that we could probably profit from reusing the lookup tables also for the 1 or 2 leftmost bytes:
> 
>         // We know there are at most two digits left at this point.
>         buf[--charPos] = DigitOnes[-i];
>         if (i < -9) {
>             buf[--charPos] = DigitTens[-i];
>         }
> 
> This avoids some arithmetic, and on average achieves a small speed-up since the lookup tables are likely cached are likely to be in cache. Small improvements on a few affected microbenchmarks, including the new Integers.toStringTiny, can be observed. 
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt   Score   Error  Units
> Integers.toStringTiny     500  avgt   50  21.862 ? 0.211  us/op
> 
> 
> Patch:
> 
> Benchmark              (size)  Mode  Cnt   Score   Error  Units
> Integers.toStringTiny     500  avgt   50  20.619 ? 0.330  us/op

LGTM.

test/micro/org/openjdk/bench/java/lang/Integers.java line 66:

> 64:         intsTiny  = new int[size];
> 65:         intsSmall = new int[size];
> 66:         intsBig   = new int[size];

Stray extra space.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6854

From duke at openjdk.java.net  Fri Dec 17 21:14:28 2021
From: duke at openjdk.java.net (liach)
Date: Fri, 17 Dec 2021 21:14:28 GMT
Subject: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
In-Reply-To: <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
 <669eUlQHEKEymsWicj2FHRYHybj62mJk5pcp9QN-xDw=.a133f6e9-bdc7-4a24-9e84-b196692851d0@github.com>
Message-ID: <ByIwBofMB1cfHBjoOXH6KJSfdANVR_hr-dG1_cMyFBc=.bdfb88ca-48a2-4a2d-84a6-2c76f314f336@github.com>

On Thu, 16 Dec 2021 21:38:30 GMT, liach <duke at openjdk.java.net> wrote:

>> Simply changes this to only read the static field once to prevent `null` on second read.
>
> liach has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - sorry, reintroduced the bug in last patch
>  - choose a concise name for the local var

Should've been 24 hours for people in different time zones to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6870

From almatvee at openjdk.java.net  Fri Dec 17 22:00:38 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 17 Dec 2021 22:00:38 GMT
Subject: [jdk18] Integrated: 8278970: [macos] SigningPackageTest is failed with
 runtime exception
In-Reply-To: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
References: <odjQbE4Plv9I4QYKOuDzl6PM2fX8aUhBTyyoiCUERL4=.35756e7e-1c81-4685-be11-46a8871c715a@github.com>
Message-ID: <Ewl9NO2kMYcgYZPrfSZnBUuC6oDBXQDd1D7eeQrG6-E=.b8f44fb6-7b42-47f6-88b9-c4ef555295ff@github.com>

On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8263155. MacHelper.java is now calling test verification callback with all content in DMG root. SigningPackageTest expects only path with app name in it and thus it fails when trying to verify app inside ".background" folder. Fixed by checking that provided path for verification is actually an application we expecting. All other paths are ignored.

This pull request has now been integrated.

Changeset: 36676db2
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/36676db2fdb810f6d9fe7be8a81b86244dbdbf71
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8278970: [macos] SigningPackageTest is failed with runtime exception

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk18/pull/42

From duke at openjdk.java.net  Fri Dec 17 22:26:27 2021
From: duke at openjdk.java.net (liach)
Date: Fri, 17 Dec 2021 22:26:27 GMT
Subject: Integrated: 8261404: Class.getReflectionFactory() is not thread-safe
In-Reply-To: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
References: <sUr_K2ls3p0lOb3Mz1K3apOm-XjdVdIUmRQrYEZMF2g=.46016e48-506d-48d8-b993-6f15e7ea6725@github.com>
Message-ID: <d6n1VzqjxDW3Hju-ySF_LCWRuj_r9trsXNnXhg80Lsk=.26dc2954-f840-4cd2-8dca-6887e2166f2d@github.com>

On Thu, 16 Dec 2021 21:04:58 GMT, liach <duke at openjdk.java.net> wrote:

> Simply changes this to only read the static field once to prevent `null` on second read.

This pull request has now been integrated.

Changeset: 905b7639
Author:    liach <liach at users.noreply.github.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/905b7639424a0fa80f81f734f6fdae1b5018a14a
Stats:     7 lines in 1 file changed: 2 ins; 1 del; 4 mod

8261404: Class.getReflectionFactory() is not thread-safe

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/6870

From dlong at openjdk.java.net  Fri Dec 17 22:36:33 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 17 Dec 2021 22:36:33 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
Message-ID: <ArLWV3AldnAQRPGn46-DQATjBZ3fec4N23PZKkQU0lQ=.9a29b27d-b0ab-4b98-99b3-039c20a943e6@github.com>

On Mon, 13 Dec 2021 09:39:55 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
> 
> It looks like in the following code in `String(byte[], int, int, Charset)`
> 
> while (offset < sl) {
>     int b1 = bytes[offset];
>     if (b1 >= 0) {
>         dst[dp++] = (byte)b1;
>         offset++;                                  // <---
>         continue;
>     }
>     if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
>             offset + 1 < sl) {
>         int b2 = bytes[offset + 1];
>         if (!isNotContinuation(b2)) {
>             dst[dp++] = (byte)decode2(b1, b2);
>             offset += 2;
>             continue;
>         }
>     }
>     // anything not a latin1, including the repl
>     // we have to go with the utf16
>     break;
> }
> 
> bounds check elimination is not executed when accessing byte array via `bytes[offset].
> 
> The reason, I guess, is that offset variable is modified within the loop (marked with arrow).
> 
> Possible fix for this could be changing:
> 
> `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`
> 
> However the best is to invest in C2 optimization to handle all such cases.
> 
> The following benchmark demonstrates good improvement:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class StringConstructorBenchmark {
>   private byte[] array;
>   private String str;
> 
>   @Setup
>   public void setup() {
>     str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
>     array = str.getBytes(StandardCharsets.UTF_8);
>   }
> 
>   @Benchmark
>   public String newString()  {
>       return new String(array, 0, array.length, StandardCharsets.UTF_8);
>   }
> 
>   @Benchmark
>   public String translateEscapes()  {
>       return str.translateEscapes();
>   }
> }
> 
> Results:
> 
> //baseline
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op
> 
> //patched
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op
> 
> The same is observed in String.translateEscapes() for the same String as in the benchmark above:
> 
> //baseline
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op
> 
> //patched
> Benchmark Mode Cnt Score Error Units
> StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op
> 
> Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.
> 
> Here's the part of baseline assembly responsible for `while` loop: 
> 
>   3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
>   2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
>   2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>                   ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>   2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
>                    ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
>   3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
>                    ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
>   2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
>   2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
>   2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
>   3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
>   2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
>   2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
>   2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
>   3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
>   2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
>   2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
>   2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
>                    ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
>   3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
>   2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
>   2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
>   2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
>   3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
>   2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
>   2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
>                    ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>                                ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)
> 
> and this one is for patched code:
> 
>  17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>                   ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>   0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
>                    ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
>   0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
>                    ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
>   0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
>  13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
>   0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
>   0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
>   0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
>   0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
>  12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
>   0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
>   0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>                    ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
>   0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
>   0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
> 
> Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.

This does look like a HotSpot JIT compiler issue to me.  My guess is that it is related to how checkBoundsOffCount() checks for offset < 0:

396          if ((length | fromIndex | size) < 0 || size > length - fromIndex)

using | to combine three values.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From jai.forums2013 at gmail.com  Sat Dec 18 06:00:45 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 18 Dec 2021 11:30:45 +0530
Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR
 file with FILE_SHARE_DELETE sharing mode on Windows
In-Reply-To: <e6527894-d274-f573-a2f4-ca4542430ebe@gmail.com>
References: <e6527894-d274-f573-a2f4-ca4542430ebe@gmail.com>
Message-ID: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com>

Would there be interest in moving this forward? Enabling that 
FILE_SHARE_DELETE option has opened up some questions that I noted in my 
previous mail below. So in order to move forward I would need some 
inputs. If we don't want to do this at this time, I'll close the draft 
PR that's currently open https://github.com/openjdk/jdk/pull/6477.

-Jaikiran

On 19/11/21 5:10 pm, Jaikiran Pai wrote:
> I have been experimenting with 
> https://bugs.openjdk.java.net/browse/JDK-8224794 and have reached a 
> stage with my changes where I would like some inputs before I move 
> ahead or raise a PR for review.
>
> As noted in that JBS issue, the idea is to open the underlying file 
> using FILE_SHARE_DELETE when using java.uitl.zip.ZipFile and 
> java.util.jar.JarFile. From what I can infer from that JBS issue, the 
> motivation behind this seems to be to allow deleting that underlying 
> file when that file is currently opened and in use by the 
> ZipFile/JarFile instance. The linked github issues seem to suggest the 
> same. IMO, it's a reasonable expectation, given that such a deletion 
> works on *nix platform. It's on Windows where such a deletion fails 
> with "The process cannot access the file because it is being used by 
> another process" (the other process in many cases will be the current 
> JVM instance itself). So trying to get this to work on Windows by 
> setting the FILE_SHARE_DELETE share access mode seems reasonable.
>
> Coming to the implementation part, I've an initial draft version here 
> https://github.com/openjdk/jdk/pull/6477. It sets the 
> FILE_SHARE_DELETE share access mode on the file when constructed by 
> ZipFile/JarFile. It "works", in the sense that if you issue a delete 
> against this underlying file (path) after its been opened by 
> ZipFile/JarFile instance, you no longer see the error mentioned above 
> and the delete completes without any exception. However, my 
> experiments with this change have raised a bunch of questions related 
> to this:
>
> The crucial part of the "DeleteFile" API in Windows is that, as stated 
> in its documentation[1]:
>
> "The DeleteFile function marks a file for deletion on close. 
> Therefore, the file deletion does not occur until the last handle to 
> the file is closed. Subsequent calls to CreateFile to open the file 
> fail with ERROR_ACCESS_DENIED."
>
> So imagine the following pseudo-code:
>
> String path = "C:/foo.jar"
> 1. JarFile jar = new JarFile(path); // create a jar instance
> 2. var deleted = new File(path).delete(); // delete the underlying file
> 3. var exists = new File(path).exists(); // check file existence
> 4. FileOutputStream fos = new FileOutputStream(new File(path)); // 
> open a FileOutputStream for /tmp/foo.jar
> 5. java.nio.file.Files.deleteIfExists(Path.of(path));
>
> When this is run (on Windows) *without* the change that introduces 
> FILE_SHARE_DELETE, I notice that line#2 returns "false" for 
> File.delete() (since the file is in use by the JarFile instance) and 
> then line#3 returns "true" since it still exists and line#4 succeeds 
> and creates a new FileOutputStream and line#5 fails with an exception 
> stating "java.nio.file.FileSystemException: foo.jar: The process 
> cannot access the file because it is being used by another process
> "
>
> Now when the same code is run (on Windows) *with* the proposed 
> FILE_SHARE_DELETE changes, I notice that line#2 returns "true" (i.e. 
> the file is considered deleted) and line#3 returns "true" (i.e. it's 
> considered the file still exists). So essentially the file is only 
> marked for deletion and hasn't been deleted at the OS level, since the 
> JarFile instance still has an handle open. Then line#4 unlike 
> previously, now throws an exception and fails to create the 
> FileOutputStream instance. The failure says 
> "java.nio.file.AccessDeniedException: foo.jar". This exception matches 
> the documentation from that Windows DeleteFile API. line#5 too fails 
> with this same AccessDeniedException.
>
> So what this means is, although we have managed to allow the deletion 
> to happen (i.e. the first call to delete does mark it for deletion at 
> OS level), IMO, it still doesn't improve much and raises other 
> difference in behaviour of APIs as seen above, unless the underlying 
> file handle held by ZipFile/JarFile is closed. So that brings me to 
> the next related issue.
>
> For this change to be really useful, the file handle (which is an 
> instance of RandomAccessFile) held by ZipFile/JarFile needs to be 
> closed. If a user application explicitly creates an instance of 
> ZipFile/JarFile, it is expected that they close it themselves. 
> However, the most prominent use of the JarFile creation is within the 
> JDK code where it uses the sun.net.www.protocol.jar.JarURLConnection 
> to construct the JarFile instances, typically from the URLClassLoader. 
> By default these JarFile instances that are created by the 
> sun.net.www.protocol.jar.JarURLConnection are cached and the close() 
> on those instances is called only when the URLClassLoader is 
> close()ed. That in itself doesn't guarantee that the underlying file 
> descriptor corresponding to the JarFile instance gets closed, because 
> there's one more level of reference counting "cache" in use in 
> java.util.zip.ZipFile$Source class where the same underlying file 
> descriptor (corresponding to the jar file) gets used by multiple 
> JarFile instances (irrespective of who created those). So in short, 
> the underlying file descriptor of a JarFile only gets closed when 
> every single instance of a JarFile pointing to the same jar file has 
> been close()ed within the JVM. Which effectively means that 
> introducing the FILE_SHARE_DELETE semantics/changes for Windows will 
> only allow the first delete() attempt to succeed (since that one marks 
> it for deletion), but any subsequent operations like the one noted in 
> the examples, that rely on that file being deleted will continue to 
> fail with Access Denied errors. Given all this caching of JarFile and 
> the reference count cache for the underlying jar file, is this change 
> of FILE_SHARE_DELETE adding much value and should I pursue it further?
>
> [1] 
> https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew
>
> -Jaikiran
>

From duke at openjdk.java.net  Sat Dec 18 21:51:28 2021
From: duke at openjdk.java.net (amirhadadi)
Date: Sat, 18 Dec 2021 21:51:28 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <ArLWV3AldnAQRPGn46-DQATjBZ3fec4N23PZKkQU0lQ=.9a29b27d-b0ab-4b98-99b3-039c20a943e6@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <ArLWV3AldnAQRPGn46-DQATjBZ3fec4N23PZKkQU0lQ=.9a29b27d-b0ab-4b98-99b3-039c20a943e6@github.com>
Message-ID: <RHrlUP_vYtB1WVKsd0GFKIanvvncbKiMcHCv8seP1Cs=.48e38264-bce3-4800-a08c-3941085b89ad@github.com>

On Fri, 17 Dec 2021 22:33:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>> 
>> It looks like in the following code in `String(byte[], int, int, Charset)`
>> 
>> while (offset < sl) {
>>     int b1 = bytes[offset];
>>     if (b1 >= 0) {
>>         dst[dp++] = (byte)b1;
>>         offset++;                                  // <---
>>         continue;
>>     }
>>     if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) &&
>>             offset + 1 < sl) {
>>         int b2 = bytes[offset + 1];
>>         if (!isNotContinuation(b2)) {
>>             dst[dp++] = (byte)decode2(b1, b2);
>>             offset += 2;
>>             continue;
>>         }
>>     }
>>     // anything not a latin1, including the repl
>>     // we have to go with the utf16
>>     break;
>> }
>> 
>> bounds check elimination is not executed when accessing byte array via `bytes[offset].
>> 
>> The reason, I guess, is that offset variable is modified within the loop (marked with arrow).
>> 
>> Possible fix for this could be changing:
>> 
>> `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)`
>> 
>> However the best is to invest in C2 optimization to handle all such cases.
>> 
>> The following benchmark demonstrates good improvement:
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class StringConstructorBenchmark {
>>   private byte[] array;
>>   private String str;
>> 
>>   @Setup
>>   public void setup() {
>>     str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian
>>     array = str.getBytes(StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String newString()  {
>>       return new String(array, 0, array.length, StandardCharsets.UTF_8);
>>   }
>> 
>>   @Benchmark
>>   public String translateEscapes()  {
>>       return str.translateEscapes();
>>   }
>> }
>> 
>> Results:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op
>> 
>> The same is observed in String.translateEscapes() for the same String as in the benchmark above:
>> 
>> //baseline
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op
>> 
>> //patched
>> Benchmark Mode Cnt Score Error Units
>> StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op
>> 
>> Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7.
>> 
>> Here's the part of baseline assembly responsible for `while` loop: 
>> 
>>   3.62%           ??            ?  0x00007fed70eb4c1c:   mov    %ebx,%ecx
>>   2.29%           ??            ?  0x00007fed70eb4c1e:   mov    %edx,%r9d
>>   2.22%           ??            ?  0x00007fed70eb4c21:   mov    (%rsp),%r8                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??            ?                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   2.32%           ??            ?  0x00007fed70eb4c25:   cmp    %r13d,%ecx
>>                    ?            ?  0x00007fed70eb4c28:   jge    0x00007fed70eb5388           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@110 (line 537)
>>   3.05%            ?            ?  0x00007fed70eb4c2e:   cmp    0x8(%rsp),%ecx
>>                    ?            ?  0x00007fed70eb4c32:   jae    0x00007fed70eb5319
>>   2.38%            ?            ?  0x00007fed70eb4c38:   mov    %r8,(%rsp)
>>   2.64%            ?            ?  0x00007fed70eb4c3c:   movslq %ecx,%r8
>>   2.46%            ?            ?  0x00007fed70eb4c3f:   mov    %rax,%rbx
>>   3.44%            ?            ?  0x00007fed70eb4c42:   sub    %r8,%rbx
>>   2.62%            ?            ?  0x00007fed70eb4c45:   add    $0x1,%rbx
>>   2.64%            ?            ?  0x00007fed70eb4c49:   and    $0xfffffffffffffffe,%rbx
>>   2.30%            ?            ?  0x00007fed70eb4c4d:   mov    %ebx,%r8d
>>   3.08%            ?            ?  0x00007fed70eb4c50:   add    %ecx,%r8d
>>   2.55%            ?            ?  0x00007fed70eb4c53:   movslq %r8d,%r8
>>   2.45%            ?            ?  0x00007fed70eb4c56:   add    $0xfffffffffffffffe,%r8
>>   2.13%            ?            ?  0x00007fed70eb4c5a:   cmp    (%rsp),%r8
>>                    ?            ?  0x00007fed70eb4c5e:   jae    0x00007fed70eb5319
>>   3.36%            ?            ?  0x00007fed70eb4c64:   mov    %ecx,%edi                    ;*aload_1 {reexecute=0 rethrow=0 return_oop=0}
>>                    ?            ?                                                            ; - java.lang.String::&lt;init&gt;@113 (line 538)
>>   2.86%            ?           ??  0x00007fed70eb4c66:   movsbl 0x10(%r14,%rdi,1),%r8d       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@115 (line 538)
>>   2.48%            ?           ??  0x00007fed70eb4c6c:   mov    %r9d,%edx
>>   2.26%            ?           ??  0x00007fed70eb4c6f:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@127 (line 540)
>>   3.28%            ?           ??  0x00007fed70eb4c71:   mov    %edi,%ebx
>>   2.44%            ?           ??  0x00007fed70eb4c73:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?           ??                                                            ; - java.lang.String::&lt;init&gt;@134 (line 541)
>>   2.35%            ?           ??  0x00007fed70eb4c75:   test   %r8d,%r8d
>>                    ?           ??  0x00007fed70eb4c78:   jge    0x00007fed70eb4c04           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                                ??                                                            ; - java.lang.String::&lt;init&gt;@120 (line 539)
>> 
>> and this one is for patched code:
>> 
>>  17.28%           ??  0x00007f6b88eb6061:   mov    %edx,%r10d                   ;*iload_2 {reexecute=0 rethrow=0 return_oop=0}
>>                   ??                                                            ; - java.lang.String::&lt;init&gt;@107 (line 537)
>>   0.11%           ??  0x00007f6b88eb6064:   test   %r10d,%r10d
>>                    ?  0x00007f6b88eb6067:   jl     0x00007f6b88eb669c           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@108 (line 537)
>>   0.39%            ?  0x00007f6b88eb606d:   cmp    %r13d,%r10d
>>                    ?  0x00007f6b88eb6070:   jge    0x00007f6b88eb66d0           ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@114 (line 537)
>>   0.66%            ?  0x00007f6b88eb6076:   mov    %ebx,%r9d
>>  13.70%            ?  0x00007f6b88eb6079:   cmp    0x8(%rsp),%r10d
>>   0.01%            ?  0x00007f6b88eb607e:   jae    0x00007f6b88eb6671
>>   0.14%            ?  0x00007f6b88eb6084:   movsbl 0x10(%r14,%r10,1),%edi       ;*baload {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@119 (line 538)
>>   0.37%            ?  0x00007f6b88eb608a:   mov    %r9d,%ebx
>>   0.99%            ?  0x00007f6b88eb608d:   inc    %ebx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@131 (line 540)
>>  12.88%            ?  0x00007f6b88eb608f:   movslq %r9d,%rsi                    ;*bastore {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@196 (line 548)
>>   0.17%            ?  0x00007f6b88eb6092:   mov    %r10d,%edx
>>   0.39%            ?  0x00007f6b88eb6095:   inc    %edx                         ;*iinc {reexecute=0 rethrow=0 return_oop=0}
>>                    ?                                                            ; - java.lang.String::&lt;init&gt;@138 (line 541)
>>   0.96%            ?  0x00007f6b88eb6097:   test   %edi,%edi
>>   0.02%            ?  0x00007f6b88eb6099:   jl     0x00007f6b88eb60dc           ;*iflt {reexecute=0 rethrow=0 return_oop=0}
>> 
>> Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code.
>
> This does look like a HotSpot JIT compiler issue to me.  My guess is that it is related to how checkBoundsOffCount() checks for offset < 0:
> 
> 396          if ((length | fromIndex | size) < 0 || size > length - fromIndex)
> 
> using | to combine three values.

@dean-long actually the issue reproduces with Java 17 where `checkBoundsOffCount` was implemented in a more straight forward way:


    static void checkBoundsOffCount(int offset, int count, int length) {
        if (offset < 0 || count < 0 || offset > length - count) {
            throw new StringIndexOutOfBoundsException(
                "offset " + offset + ", count " + count + ", length " + length);
        }
    }



Here's a [gist](https://gist.github.com/amirhadadi/9505c3f5d9ad68cad2fbfd1b9e01f0b8) with a benchmark you can run. In this benchmark I'm comparing safe and unsafe reads from the byte array  (I didn't modify the code to add the offset >= 0 condition).

Here are the results:


Benchmark                       Mode  Cnt    Score    Error  Units
StringBenchmark.safeDecoding    avgt   20  120.312 ? 11.674  ns/op
StringBenchmark.unsafeDecoding  avgt   20   72.628 ?  0.479  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From duke at openjdk.java.net  Sun Dec 19 03:29:48 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 19 Dec 2021 03:29:48 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
Message-ID: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>

Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.

This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)

-------------

Commit messages:
 - 8261407: ReflectionFactory.checkInitted() is not thread-safe

Changes: https://git.openjdk.java.net/jdk/pull/6889/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261407
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6889.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889

PR: https://git.openjdk.java.net/jdk/pull/6889

From raymond.auge at liferay.com  Sun Dec 19 03:47:40 2021
From: raymond.auge at liferay.com (=?UTF-8?Q?Raymond_Aug=C3=A9?=)
Date: Sat, 18 Dec 2021 22:47:40 -0500
Subject: possible bug in jdeps as ToolProvider
Message-ID: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>

Hello everyone,

At Alan's request [3] I'm posting this here. Alan mentions this is likely a
manifestation of JDK-8277681 [4]. From the description I would agree.

Here is a copy of the original message for posterity.
-------------------
I believe I have found a small bug in jdeps tool when used as ToolProvider.

I am invoking the jdeps impl via the ToolProvider API as follows (this code
is also available here [2]):

  try (final StringWriter stdout = new StringWriter();
      final StringWriter stderr = new StringWriter();
      final PrintWriter pwout = new PrintWriter(stdout);
      final PrintWriter pwerr = new PrintWriter(stderr)) {

    return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
args) == 0) ?
      stdout.toString() :
      "Error: ".concat(stderr.toString());
  }
  catch (Throwable t) {
    t.printStackTrace();
    return "Error: " + t.getMessage();
  }

However repeat invocations result in the following exception:

java.lang.Error: java.util.concurrent.ExecutionException:
com.sun.tools.jdeps.MultiReleaseException
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
at
jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
at
jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
  [snip]
Caused by: java.util.concurrent.ExecutionException:
com.sun.tools.jdeps.MultiReleaseException
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
... 24 more
Caused by: com.sun.tools.jdeps.MultiReleaseException
at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
at
jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
at
jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

In order to get around the error I do the following:

public static final Field field;
public static final Map<?,?> map;

static {
  try {
    Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
    field = clazz.getDeclaredField("nameToVersion");
    field.setAccessible(true);
    map = (Map<?,?>)field.get(null);
  }
  catch (ReflectiveOperationException e) {
    throw new RuntimeException(e);
  }
}

and tack a finally to the end of the try above:

finally {
  map.clear();
}

Now, additionally to be able to do that, I need to add an `--add-opens`:

--add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED

I believe the solution is to clear the map in [1] when jdeps finishes.

Finally, I would send a PR myself except I do not (yet) have an OCA and the
solution seems simple enough if someone can confirm that this is indeed a
bug.

Ray

[1]
https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java
[2] https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852
[3]
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
[4] https://bugs.openjdk.java.net/browse/JDK-8277681

From dholmes at openjdk.java.net  Sun Dec 19 06:00:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Dec 2021 06:00:22 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
In-Reply-To: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
Message-ID: <LpgJqkPaYEKrl_CfK2_JSLIA_tmmd2vc7mkoGF2mcuY=.131d8a8c-3507-4765-8f2f-884396b63c39@github.com>

On Sun, 19 Dec 2021 03:21:55 GMT, liach <duke at openjdk.java.net> wrote:

> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.
> 
> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)

Changes requested by dholmes (Reviewer).

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 695:

> 693: 
> 694:         // ensure previous fields are visible before initted is
> 695:         Unsafe.getUnsafe().storeStoreFence();

Ensuring ordering on the writer side, without also ensuring ordering on the reader side, doesn't solve an ordering problem. Just make `initted` volatile and this should be safe from a Java Memory Model perspective.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From duke at openjdk.java.net  Sun Dec 19 06:51:45 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 19 Dec 2021 06:51:45 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
Message-ID: <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>

> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.
> 
> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)

liach has updated the pull request incrementally with one additional commit since the last revision:

  Just use volatile directly to ensure read order

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6889/files
  - new: https://git.openjdk.java.net/jdk/pull/6889/files/73581dd3..1deb5207

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6889.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889

PR: https://git.openjdk.java.net/jdk/pull/6889

From duke at openjdk.java.net  Sun Dec 19 07:08:26 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 19 Dec 2021 07:08:26 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <LpgJqkPaYEKrl_CfK2_JSLIA_tmmd2vc7mkoGF2mcuY=.131d8a8c-3507-4765-8f2f-884396b63c39@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <LpgJqkPaYEKrl_CfK2_JSLIA_tmmd2vc7mkoGF2mcuY=.131d8a8c-3507-4765-8f2f-884396b63c39@github.com>
Message-ID: <MwEKiDTJ5s64FlLWf9MOATFRfT67v-zqiuT-b9GAzGo=.0d57b619-8f8d-4866-bcfa-7920209393e0@github.com>

On Sun, 19 Dec 2021 05:56:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Just use volatile directly to ensure read order
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 695:
> 
>> 693: 
>> 694:         // ensure previous fields are visible before initted is
>> 695:         Unsafe.getUnsafe().storeStoreFence();
> 
> Ensuring ordering on the writer side, without also ensuring ordering on the reader side, doesn't solve an ordering problem. Just make `initted` volatile and this should be safe from a Java Memory Model perspective.

On a side note, would a store load fence (like `VarHandle.storeFence`) after the write be a valid alternative, so the field itself can be get plain?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From alanb at openjdk.java.net  Sun Dec 19 07:40:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 19 Dec 2021 07:40:29 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set.

The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/45

From alanb at openjdk.java.net  Sun Dec 19 08:48:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 19 Dec 2021 08:48:25 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
Message-ID: <9172UD9gD8dwN7VODwNI_W6nt55F7SW_v0pjvrcCgPo=.0c5e27d7-1979-47ff-9a22-884912972402@github.com>

On Sun, 19 Dec 2021 06:51:45 GMT, liach <duke at openjdk.java.net> wrote:

>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.
>> 
>> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Just use volatile directly to ensure read order

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 65:

> 63: 
> 64:     // volatile ensures static fields set before are published
> 65:     private static volatile boolean initted = false;

I assume you can avoid the volatile write by not explicitly initialising it to false. The other thing to try here is making it a @Stable field.

There are issues with noInflation inflationThreshold too but since they are no longer used by default then I think we can leave them, that code will eventually be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From dholmes at openjdk.java.net  Sun Dec 19 12:42:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Dec 2021 12:42:18 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <MwEKiDTJ5s64FlLWf9MOATFRfT67v-zqiuT-b9GAzGo=.0d57b619-8f8d-4866-bcfa-7920209393e0@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <LpgJqkPaYEKrl_CfK2_JSLIA_tmmd2vc7mkoGF2mcuY=.131d8a8c-3507-4765-8f2f-884396b63c39@github.com>
 <MwEKiDTJ5s64FlLWf9MOATFRfT67v-zqiuT-b9GAzGo=.0d57b619-8f8d-4866-bcfa-7920209393e0@github.com>
Message-ID: <oAKhjXdz7UCJifmXPAusX05fmremXXkeRc1Rd_hA5l8=.4770ded9-1ce5-4c07-8297-e38b6036eda0@github.com>

On Sun, 19 Dec 2021 07:05:31 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 695:
>> 
>>> 693: 
>>> 694:         // ensure previous fields are visible before initted is
>>> 695:         Unsafe.getUnsafe().storeStoreFence();
>> 
>> Ensuring ordering on the writer side, without also ensuring ordering on the reader side, doesn't solve an ordering problem. Just make `initted` volatile and this should be safe from a Java Memory Model perspective.
>
> On a side note, would a store load fence (like `VarHandle.storeFence`) after the write be a valid alternative, so the field itself can be get plain?

I don't see such a "fence" in the VarHandle API. ?? The `VarHandle.storeStoreFence()` is no different in memory ordering properties to the `Unsafe.storeStoreFence()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From dholmes at openjdk.java.net  Sun Dec 19 12:46:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Dec 2021 12:46:25 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
Message-ID: <rF33EhdW5i57mb6JtIClpstBa5slChXd9IpOrJI2OIs=.44aec3d1-772b-4043-a09b-c0bbc43fc76c@github.com>

On Sun, 19 Dec 2021 06:51:45 GMT, liach <duke at openjdk.java.net> wrote:

>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses.
>> 
>> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Just use volatile directly to ensure read order

As Alan notes there is no need for explicit initialization to the default value, so a volatile write can be saved. Otherwise this seems to address the problem of safe publication.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6889

From duke at openjdk.java.net  Sun Dec 19 20:37:26 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 19 Dec 2021 20:37:26 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <9172UD9gD8dwN7VODwNI_W6nt55F7SW_v0pjvrcCgPo=.0c5e27d7-1979-47ff-9a22-884912972402@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
 <9172UD9gD8dwN7VODwNI_W6nt55F7SW_v0pjvrcCgPo=.0c5e27d7-1979-47ff-9a22-884912972402@github.com>
Message-ID: <mMTTFr5gZqgVueqqQ2Jqhx5oRqzlBruUs8Un58pD_ik=.eb00511a-8c75-4156-a6c0-6f858ce610b9@github.com>

On Sun, 19 Dec 2021 08:45:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Just use volatile directly to ensure read order
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 65:
> 
>> 63: 
>> 64:     // volatile ensures static fields set before are published
>> 65:     private static volatile boolean initted = false;
> 
> I assume you can avoid the volatile write by not explicitly initialising it to false. The other thing to try here is making it a @Stable field.
> 
> There are issues with noInflation inflationThreshold too but since they are no longer used by default then I think we can leave them, that code will eventually be removed.

Hmm, one of my original draft was like:

    @Stable
    private static boolean initted;


        // ensure previous fields are visible before initted is
        var unsafe = Unsafe.getUnsafe();
        unsafe.storeStoreFence();
        initted = true;
        unsafe.fullFence(); // Serves as the store-load fence
        // May this simply be a store-store fence like in ConstantCallSite?

The store-load fence is described by [shipilev's article](https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_model) as inserted after volatile writes.

I doubt if simply marking it `@Stable` can make it safe: in [`ConstantCallSite`'s constructor](https://github.com/openjdk/jdk/blob/63e43030ed1260d14df950342c39a377231a3f40/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java#L52), a store-store fence is used to publish a stable field (note the super constructor calls a store-store fence at its end as well).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From duke at openjdk.java.net  Mon Dec 20 02:49:41 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Mon, 20 Dec 2021 02:49:41 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight when
 matching "*" (as if it is 1)
Message-ID: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>

Locale.filterTags methods ignore actual weight when matching "*" (as if
it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.

Fix the bug and add regression test cases for it as well as existing
behavior.

-------------

Commit messages:
 - Locale.filterTags must respect the weight of "*"

Changes: https://git.openjdk.java.net/jdk/pull/6789/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6789&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276302
  Stats: 121 lines in 2 files changed: 59 ins; 54 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6789/head:pull/6789

PR: https://git.openjdk.java.net/jdk/pull/6789

From alanb at openjdk.java.net  Mon Dec 20 07:49:23 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 20 Dec 2021 07:49:23 GMT
Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
 [v2]
In-Reply-To: <mMTTFr5gZqgVueqqQ2Jqhx5oRqzlBruUs8Un58pD_ik=.eb00511a-8c75-4156-a6c0-6f858ce610b9@github.com>
References: <Bax6c_FpTSSmN1nCgD1DrPBppYvglOnfSKLb0hVj4eU=.d396f3c5-337b-4997-872c-e3cd98a283bd@github.com>
 <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com>
 <9172UD9gD8dwN7VODwNI_W6nt55F7SW_v0pjvrcCgPo=.0c5e27d7-1979-47ff-9a22-884912972402@github.com>
 <mMTTFr5gZqgVueqqQ2Jqhx5oRqzlBruUs8Un58pD_ik=.eb00511a-8c75-4156-a6c0-6f858ce610b9@github.com>
Message-ID: <CtDcQwu5ct_aZnwHzccE3T7qVHUtneS_8KxGloOV0gM=.24a851db-aeaf-4591-9f14-aca0364d446a@github.com>

On Sun, 19 Dec 2021 20:34:22 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 65:
>> 
>>> 63: 
>>> 64:     // volatile ensures static fields set before are published
>>> 65:     private static volatile boolean initted = false;
>> 
>> I assume you can avoid the volatile write by not explicitly initialising it to false. The other thing to try here is making it a @Stable field.
>> 
>> There are issues with noInflation inflationThreshold too but since they are no longer used by default then I think we can leave them, that code will eventually be removed.
>
> Hmm, one of my original draft was like:
> 
>     @Stable
>     private static boolean initted;
> 
> 
>         // ensure previous fields are visible before initted is
>         var unsafe = Unsafe.getUnsafe();
>         unsafe.storeStoreFence();
>         initted = true;
>         unsafe.fullFence(); // Serves as the store-load fence
>         // May this simply be a store-store fence like in ConstantCallSite?
> 
> The store-load fence is described by [shipilev's article](https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_model) as inserted after volatile writes.
> 
> I doubt if simply marking it `@Stable` can make it safe: in [`ConstantCallSite`'s constructor](https://github.com/openjdk/jdk/blob/63e43030ed1260d14df950342c39a377231a3f40/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java#L52), a store-store fence is used to publish a stable field (note the super constructor calls a store-store fence at its end as well).

> Hmm, one of my original draft was like:
> 
> ```java
>     @Stable
>     private static boolean initted;
> ```

The suggestion was to try `@Stable private static volatile boolean inited` to see if the volatile read is elided from the generated code. It does can be looked at later too as what you have is okay (assuming the explicitly initialisation to false is removed).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6889

From myano at openjdk.java.net  Mon Dec 20 10:05:51 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 20 Dec 2021 10:05:51 GMT
Subject: RFR: 8276694: Pattern trailing unescaped backslash causes internal
 error
Message-ID: <TYs97R7wsal7NB3xA2SGibFT5XHKfFMOAiT5px4Rw-k=.5e83fdd6-79a7-4d41-9e3d-d01bcd8dfa11@github.com>

Could you please review the 8276694 bug fixes?

A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression.

-------------

Commit messages:
 - 8276694: Pattern trailing unescaped backslash causes internal error

Changes: https://git.openjdk.java.net/jdk/pull/6891/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6891&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276694
  Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6891.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6891/head:pull/6891

PR: https://git.openjdk.java.net/jdk/pull/6891

From jbhateja at openjdk.java.net  Mon Dec 20 13:39:45 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 20 Dec 2021 13:39:45 GMT
Subject: RFR: 8273322: Enhance macro logic optimization for masked logic
 operations.
Message-ID: <I0IGGMFQ-TxYIwRF2oDiv9MHAhaxhSZ-9GeJSqWoFss=.4556a217-049b-45cb-8258-0349039d5561@github.com>

Patch extends existing macrologic inferencing algorithm to handle masked logic operations.

Existing algorithm:

1. Identify logic cone roots.
2. Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met.
i.e. maximum number of inputs which a macro logic node can have.
3. Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column
to each input.
4. Inputs along with encoded function together represents a macro logic node which mimics a truth table.

Modification:
Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following
rules define the criteria under which nodes gets packed into a macro logic node:-

1. Parent and both child nodes are all unmasked or masked with same predicates.
2. Masked parent can be packed with left child if it is predicated and both have same prediates.
3. Masked parent can be packed with right child if its un-predicated or has matching predication condition.
4. An unmasked parent can be packed with an unmasked child.

New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and
child nodes.

Following are the performance number for JMH benchmark included with the patch.

Machine Configuration:  Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (40C 2S Icelake Server)

Benchmark | ARRAYLEN | Baseline (ops/s) | Withopt (ops/s) | Gain ( withopt/baseline)
-- | -- | -- | -- | --
o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 64 | 2365.421 | 5136.283 | 2.171403315
o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 128 | 2034.1 | 4073.381 | 2.002547072
o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 256 | 1568.694 | 2811.975 | 1.792558013
o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 512 | 883.261 | 1662.771 | 1.882536419
o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 1024 | 469.513 | 732.81 | 1.560787454
o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 64 | 273.049 | 552.106 | 2.022003377
o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 128 | 219.624 | 359.775 | 1.63814064
o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 256 | 131.649 | 182.23 | 1.384211046
o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 512 | 71.452 | 81.522 | 1.140933774
o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 1024 | 37.427 | 41.966 | 1.121276084
o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 64 | 2805.759 | 3383.16 | 1.205791374
o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 128 | 2069.012 | 2250.37 | 1.087654397
o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 256 | 1098.766 | 1101.996 | 1.002939661
o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 512 | 470.035 | 484.732 | 1.031267884
o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 1024 | 202.827 | 209.073 | 1.030794717
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 256 | 3435.989 | 4418.09 | 1.285827749
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 512 | 1524.803 | 1678.201 | 1.100601848
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 1024 | 972.501 | 1166.734 | 1.199725244
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 256 | 5980.85 | 7584.17 | 1.268075608
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 512 | 3258.108 | 3939.23 | 1.209054457
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 1024 | 1475.365 | 1511.159 | 1.024261115
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 256 | 4208.766 | 4220.678 | 1.002830283
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 512 | 2056.651 | 2049.489 | 0.99651764
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 1024 | 1110.461 | 1116.448 | 1.005391455
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 256 | 3259.348 | 3947.94 | 1.211266793
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 512 | 1515.147 | 1536.647 | 1.014190042
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 1024 | 911.58 | 1030.54 | 1.130498695
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 256 | 2034.611 | 2073.764 | 1.019243482
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 512 | 1110.659 | 1116.093 | 1.004892591
o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 1024 | 559.269 | 559.651 | 1.000683034
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 256 | 3636.141 | 4446.505 | 1.222863745
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 512 | 1433.145 | 1681.261 | 1.173126934
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 1024 | 1000.107 | 1172.866 | 1.172740517
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 256 | 5568.313 | 7670.259 | 1.37748345
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 512 | 3350.108 | 3927.803 | 1.172440709
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 1024 | 1495.966 | 1541.56 | 1.030477965
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 256 | 4230.379 | 4282.154 | 1.012238856
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 512 | 2029.801 | 2049.638 | 1.009772879
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 1024 | 1108.738 | 1118.897 | 1.00916267
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 256 | 3802.801 | 3783.537 | 0.99493426
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 512 | 1546.244 | 1552.691 | 1.004169458
o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 1024 | 1017.512 | 1020.075 | 1.002518889
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 256 | 4159.835 | 4527.676 | 1.088426825
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 512 | 1665.335 | 1733.04 | 1.040655484
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 1024 | 1150.319 | 1181.935 | 1.02748455
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 256 | 6989.791 | 7382.883 | 1.056238019
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 512 | 3711.362 | 3911.921 | 1.054039191
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 1024 | 1540.341 | 1554.175 | 1.008981128
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 256 | 4164.559 | 4213.546 | 1.01176283
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 512 | 2072.91 | 2079.105 | 1.002988552
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 1024 | 1112.678 | 1116.675 | 1.003592234
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 256 | 3702.998 | 3906.093 | 1.0548461
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 512 | 1536.571 | 1546.043 | 1.006164375
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 1024 | 996.906 | 1013.649 | 1.016794964
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 256 | 2045.594 | 2048.966 | 1.001648421
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 512 | 1111.933 | 1117.689 | 1.005176571
o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 1024 | 559.971 | 561.144 | 1.002094751


Kindly review and share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - 8273322: Enhance macro logic optimization for masked logic operations.

Changes: https://git.openjdk.java.net/jdk/pull/6893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273322
  Stats: 1413 lines in 12 files changed: 1370 ins; 6 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6893/head:pull/6893

PR: https://git.openjdk.java.net/jdk/pull/6893

From mandy.chung at oracle.com  Mon Dec 20 18:19:20 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 20 Dec 2021 10:19:20 -0800
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
Message-ID: <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>

Yes this bug is known and tracked by JDK-8277681.? The proper solution 
should make each JdepsTask to maintain its own map of multi-versioned 
entries rather than a global nameToVersion map for the running VM as 
described in
JDK-8277681.

Mandy

On 12/18/21 7:47 PM, Raymond Aug? wrote:
> Hello everyone,
>
> At Alan's request [3] I'm posting this here. Alan mentions this is likely a
> manifestation of JDK-8277681 [4]. From the description I would agree.
>
> Here is a copy of the original message for posterity.
> -------------------
> I believe I have found a small bug in jdeps tool when used as ToolProvider.
>
> I am invoking the jdeps impl via the ToolProvider API as follows (this code
> is also available here [2]):
>
>    try (final StringWriter stdout = new StringWriter();
>        final StringWriter stderr = new StringWriter();
>        final PrintWriter pwout = new PrintWriter(stdout);
>        final PrintWriter pwerr = new PrintWriter(stderr)) {
>
>      return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
> args) == 0) ?
>        stdout.toString() :
>        "Error: ".concat(stderr.toString());
>    }
>    catch (Throwable t) {
>      t.printStackTrace();
>      return "Error: " + t.getMessage();
>    }
>
> However repeat invocations result in the following exception:
>
> java.lang.Error: java.util.concurrent.ExecutionException:
> com.sun.tools.jdeps.MultiReleaseException
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
> at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
> at
> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
> at
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
> at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
> at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>    [snip]
> Caused by: java.util.concurrent.ExecutionException:
> com.sun.tools.jdeps.MultiReleaseException
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
> ... 24 more
> Caused by: com.sun.tools.jdeps.MultiReleaseException
> at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
> at
> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
> at
> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
> In order to get around the error I do the following:
>
> public static final Field field;
> public static final Map<?,?> map;
>
> static {
>    try {
>      Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>      field = clazz.getDeclaredField("nameToVersion");
>      field.setAccessible(true);
>      map = (Map<?,?>)field.get(null);
>    }
>    catch (ReflectiveOperationException e) {
>      throw new RuntimeException(e);
>    }
> }
>
> and tack a finally to the end of the try above:
>
> finally {
>    map.clear();
> }
>
> Now, additionally to be able to do that, I need to add an `--add-opens`:
>
> --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>
> I believe the solution is to clear the map in [1] when jdeps finishes.
>
> Finally, I would send a PR myself except I do not (yet) have an OCA and the
> solution seems simple enough if someone can confirm that this is indeed a
> bug.
>
> Ray
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java
> [2]https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852
> [3]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
> [4]https://bugs.openjdk.java.net/browse/JDK-8277681

From naoto at openjdk.java.net  Mon Dec 20 18:33:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 20 Dec 2021 18:33:11 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight
 when matching "*" (as if it is 1)
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>

On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le <duke at openjdk.java.net> wrote:

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

Thanks for the fix. Looks good overall. Some minor comments follow. Also for the test case,
- add the bug id `8276302` to the `@bug` tag.
- modify the copyright year to 2021.

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 131:

> 129: 
> 130:                     if (!caseInsensitiveMatch(list, lowerCaseTag)
> 131:                             && !shouldIgnoreFilterBasicMatch(zeroRanges, lowerCaseTag)) {

Is there any reason to flip the evaluation order of the `if` statement?

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 157:

> 155:      * returning all the tags, remove those which are matching the range with
> 156:      * quality weight q=0.
> 157:      */

Please keep the comments in the modified code (except the `*` part). Although it's OK to remove this method as it eliminates extra `ArrayList` allocation, please keep the comments in the modified code (except the `*` part).

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 161:

> 159:             List<LanguageRange> zeroRange, Collection<String> tags) {
> 160:         if (zeroRange.isEmpty()) {
> 161:             tags = removeDuplicates(tags);

Can `removeDuplicates()` now be removed? There seems to be no usage.

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 167:

> 165:         List<String> matchingTags = new ArrayList<>();
> 166:         for (String tag : tags) {
> 167:             // change to lowercase for case-insensitive matching

Applies to this comment.

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 171:

> 169:             if (!shouldIgnoreFilterBasicMatch(zeroRange, lowerCaseTag)
> 170:                     && !caseInsensitiveMatch(matchingTags, lowerCaseTag)) {
> 171:                 matchingTags.add(tag); // preserving the case of the input tag

And this comment, too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6789

From raymond.auge at liferay.com  Mon Dec 20 18:33:14 2021
From: raymond.auge at liferay.com (=?UTF-8?Q?Raymond_Aug=C3=A9?=)
Date: Mon, 20 Dec 2021 13:33:14 -0500
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
 <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
Message-ID: <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>

Thank you Mandy.

On Mon., Dec. 20, 2021, 1:19 p.m. Mandy Chung, <mandy.chung at oracle.com>
wrote:

> Yes this bug is known and tracked by JDK-8277681.  The proper solution
> should make each JdepsTask to maintain its own map of multi-versioned
> entries rather than a global nameToVersion map for the running VM as
> described in
> JDK-8277681.
>
> Mandy
>
> On 12/18/21 7:47 PM, Raymond Aug? wrote:
>
> Hello everyone,
>
> At Alan's request [3] I'm posting this here. Alan mentions this is likely a
> manifestation of JDK-8277681 [4]. From the description I would agree.
>
> Here is a copy of the original message for posterity.
> -------------------
> I believe I have found a small bug in jdeps tool when used as ToolProvider.
>
> I am invoking the jdeps impl via the ToolProvider API as follows (this code
> is also available here [2]):
>
>   try (final StringWriter stdout = new StringWriter();
>       final StringWriter stderr = new StringWriter();
>       final PrintWriter pwout = new PrintWriter(stdout);
>       final PrintWriter pwerr = new PrintWriter(stderr)) {
>
>     return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
> args) == 0) ?
>       stdout.toString() :
>       "Error: ".concat(stderr.toString());
>   }
>   catch (Throwable t) {
>     t.printStackTrace();
>     return "Error: " + t.getMessage();
>   }
>
> However repeat invocations result in the following exception:
>
> java.lang.Error: java.util.concurrent.ExecutionException:
> com.sun.tools.jdeps.MultiReleaseException
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
> at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
> at
> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
> at
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
> at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
> at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>   [snip]
> Caused by: java.util.concurrent.ExecutionException:
> com.sun.tools.jdeps.MultiReleaseException
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
> ... 24 more
> Caused by: com.sun.tools.jdeps.MultiReleaseException
> at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
> at
> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
> at
> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
> at
> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
> In order to get around the error I do the following:
>
> public static final Field field;
> public static final Map<?,?> map;
>
> static {
>   try {
>     Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>     field = clazz.getDeclaredField("nameToVersion");
>     field.setAccessible(true);
>     map = (Map<?,?>)field.get(null);
>   }
>   catch (ReflectiveOperationException e) {
>     throw new RuntimeException(e);
>   }
> }
>
> and tack a finally to the end of the try above:
>
> finally {
>   map.clear();
> }
>
> Now, additionally to be able to do that, I need to add an `--add-opens`:
>
> --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>
> I believe the solution is to clear the map in [1] when jdeps finishes.
>
> Finally, I would send a PR myself except I do not (yet) have an OCA and the
> solution seems simple enough if someone can confirm that this is indeed a
> bug.
>
> Ray
>
> [1]https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java
> [2] https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852
> [3]https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
> [4] https://bugs.openjdk.java.net/browse/JDK-8277681
>
>
>

From darcy at openjdk.java.net  Mon Dec 20 18:55:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 20 Dec 2021 18:55:58 GMT
Subject: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
Message-ID: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>

Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods.

-------------

Commit messages:
 - JDK-8278953: Clarify Class.getDeclaredConstructor specification

Changes: https://git.openjdk.java.net/jdk/pull/6897/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6897&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278953
  Stats: 20 lines in 1 file changed: 11 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6897.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6897/head:pull/6897

PR: https://git.openjdk.java.net/jdk/pull/6897

From mchung at openjdk.java.net  Mon Dec 20 20:45:31 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 20 Dec 2021 20:45:31 GMT
Subject: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor
 specification
In-Reply-To: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
References: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
Message-ID: <EVVe4ql3WxAuP0_0TXZLVq42snXMdtMe6mmxi30uXOU=.1931b2df-c7d1-4a50-b277-e60f67070057@github.com>

On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods.

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6897

From alanb at openjdk.java.net  Mon Dec 20 20:51:30 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 20 Dec 2021 20:51:30 GMT
Subject: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor
 specification
In-Reply-To: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
References: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
Message-ID: <NkD_v0laeWNUIIINd3wiEZsNSvr9tI2bC-8OLRDetdw=.842b0273-18e5-4e69-b4af-a79c73dbe2d4@github.com>

On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods.

This looks okay, just wondering if expanded NoSuchMethodException description warrants a CSR.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6897

From darcy at openjdk.java.net  Mon Dec 20 21:56:36 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 20 Dec 2021 21:56:36 GMT
Subject: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor
 specification
In-Reply-To: <NkD_v0laeWNUIIINd3wiEZsNSvr9tI2bC-8OLRDetdw=.842b0273-18e5-4e69-b4af-a79c73dbe2d4@github.com>
References: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
 <NkD_v0laeWNUIIINd3wiEZsNSvr9tI2bC-8OLRDetdw=.842b0273-18e5-4e69-b4af-a79c73dbe2d4@github.com>
Message-ID: <bo6zzTgoFZZU1rAgQW-0GOJdlLn_Us2346L50xh7bQ8=.567cf4e5-c45b-44b2-ae43-068990bddbc5@github.com>

On Mon, 20 Dec 2021 20:48:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay, just wondering if expanded NoSuchMethodException description warrants a CSR.

Hmm. I don't think a CSR is strictly necessary as the additional conditions are arguably implied by the rest of the spec, but I can run a quick CSR for this.

I have not written new regression tests for this fix, but quickly checked in jshell that the expected exceptions are indeed thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6897

From smarks at openjdk.java.net  Mon Dec 20 22:35:34 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 20 Dec 2021 22:35:34 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <oE3n-Qm346QGuezStReumP2mNEKVFlbLEussXV_C6kc=.5bc857bc-fd94-40e3-8513-1db06f320f6d@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

I think there's little to worry about with custom configurations of the `rmiregistry` tool. What somebody might do is to enable a customized security manager using properties... of course they'd also have to ensure that the customized SM is somewhere in the classpath as well, by adding more command line options. That seems fairly unlikely to me. Anyone who wants to run an RMI registry service in some specialized configuration would probably just set things up themselves and then use the `LocateRegistry.createRegistry` API instead of trying to tinker with the `rmiregistry` command.

If `rmiregistry` enables the SM using properties, then yes we can probably change the code to assert that the SM is running instead of conditionally enabling it like it does now.

Next headache is that `tools/launcher/VersionCheck.jtr` fails because it sees the warning messages instead of the version string. (Argh!) Interestingly this test passes even though `rmiregistry` currently fails to operate normally, because it runs well enough to print its version string, but not well enough to start up a registry service. (Double argh!)

The warnings policy is a separate issue being discussed elsewhere.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/45

From darcy at openjdk.java.net  Tue Dec 21 00:29:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 21 Dec 2021 00:29:19 GMT
Subject: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor
 specification
In-Reply-To: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
References: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
Message-ID: <4TpRWfO5-xCnOjpdYyCFHBp9q841YNA6l9FY87_717Y=.e4927736-82a3-4b00-a1ea-7f62fb4bd109@github.com>

On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods.

CSR filed and approved: https://bugs.openjdk.java.net/browse/JDK-8279046

-------------

PR: https://git.openjdk.java.net/jdk/pull/6897

From darcy at openjdk.java.net  Tue Dec 21 00:29:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 21 Dec 2021 00:29:19 GMT
Subject: Integrated: JDK-8278953: Clarify Class.getDeclaredConstructor
 specification
In-Reply-To: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
References: <gRxxORzFLhO2wiN9-00W062EcACfmT4yj1tlX6q4gOI=.27076c81-79bd-4784-a51c-1e019d438791@github.com>
Message-ID: <OPwH8x_dlNrCRIMpXvp-oZkttyMBBU-0RCr6og-juIM=.8b76341b-09cd-4160-b2b2-befdfb75a638@github.com>

On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods.

This pull request has now been integrated.

Changeset: 51796728
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/517967284cf607c0137e088a33ab5eb98d59542d
Stats:     20 lines in 1 file changed: 11 ins; 4 del; 5 mod

8278953: Clarify Class.getDeclaredConstructor specification

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6897

From raymond.auge at liferay.com  Tue Dec 21 03:38:46 2021
From: raymond.auge at liferay.com (=?UTF-8?Q?Raymond_Aug=C3=A9?=)
Date: Mon, 20 Dec 2021 22:38:46 -0500
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
 <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
 <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>
Message-ID: <CAMm6HcAWA-6ADCZWzVaChCUO5g2PVRiXnfRGX=pQmu9bP756Kg@mail.gmail.com>

I should add that I have reproduced this issue on Java 11 and 17. The
ticket only indicates Java 18 but that in not accurate.

On Mon., Dec. 20, 2021, 1:33 p.m. Raymond Aug?, <raymond.auge at liferay.com>
wrote:

> Thank you Mandy.
>
> On Mon., Dec. 20, 2021, 1:19 p.m. Mandy Chung, <mandy.chung at oracle.com>
> wrote:
>
>> Yes this bug is known and tracked by JDK-8277681.  The proper solution
>> should make each JdepsTask to maintain its own map of multi-versioned
>> entries rather than a global nameToVersion map for the running VM as
>> described in
>> JDK-8277681.
>>
>> Mandy
>>
>> On 12/18/21 7:47 PM, Raymond Aug? wrote:
>>
>> Hello everyone,
>>
>> At Alan's request [3] I'm posting this here. Alan mentions this is likely a
>> manifestation of JDK-8277681 [4]. From the description I would agree.
>>
>> Here is a copy of the original message for posterity.
>> -------------------
>> I believe I have found a small bug in jdeps tool when used as ToolProvider.
>>
>> I am invoking the jdeps impl via the ToolProvider API as follows (this code
>> is also available here [2]):
>>
>>   try (final StringWriter stdout = new StringWriter();
>>       final StringWriter stderr = new StringWriter();
>>       final PrintWriter pwout = new PrintWriter(stdout);
>>       final PrintWriter pwerr = new PrintWriter(stderr)) {
>>
>>     return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
>> args) == 0) ?
>>       stdout.toString() :
>>       "Error: ".concat(stderr.toString());
>>   }
>>   catch (Throwable t) {
>>     t.printStackTrace();
>>     return "Error: " + t.getMessage();
>>   }
>>
>> However repeat invocations result in the following exception:
>>
>> java.lang.Error: java.util.concurrent.ExecutionException:
>> com.sun.tools.jdeps.MultiReleaseException
>> at
>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
>> at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
>> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
>> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
>> at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
>> at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>>   [snip]
>> Caused by: java.util.concurrent.ExecutionException:
>> com.sun.tools.jdeps.MultiReleaseException
>> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
>> ... 24 more
>> Caused by: com.sun.tools.jdeps.MultiReleaseException
>> at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
>> at
>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>> at
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>> at
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>> at
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>> at java.base/java.lang.Thread.run(Thread.java:829)
>>
>> In order to get around the error I do the following:
>>
>> public static final Field field;
>> public static final Map<?,?> map;
>>
>> static {
>>   try {
>>     Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>>     field = clazz.getDeclaredField("nameToVersion");
>>     field.setAccessible(true);
>>     map = (Map<?,?>)field.get(null);
>>   }
>>   catch (ReflectiveOperationException e) {
>>     throw new RuntimeException(e);
>>   }
>> }
>>
>> and tack a finally to the end of the try above:
>>
>> finally {
>>   map.clear();
>> }
>>
>> Now, additionally to be able to do that, I need to add an `--add-opens`:
>>
>> --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>>
>> I believe the solution is to clear the map in [1] when jdeps finishes.
>>
>> Finally, I would send a PR myself except I do not (yet) have an OCA and the
>> solution seems simple enough if someone can confirm that this is indeed a
>> bug.
>>
>> Ray
>>
>> [1]https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java
>> [2] https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852
>> [3]https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
>> [4] https://bugs.openjdk.java.net/browse/JDK-8277681
>>
>>
>>

From roland at openjdk.java.net  Tue Dec 21 12:54:16 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 21 Dec 2021 12:54:16 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <RHrlUP_vYtB1WVKsd0GFKIanvvncbKiMcHCv8seP1Cs=.48e38264-bce3-4800-a08c-3941085b89ad@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <ArLWV3AldnAQRPGn46-DQATjBZ3fec4N23PZKkQU0lQ=.9a29b27d-b0ab-4b98-99b3-039c20a943e6@github.com>
 <RHrlUP_vYtB1WVKsd0GFKIanvvncbKiMcHCv8seP1Cs=.48e38264-bce3-4800-a08c-3941085b89ad@github.com>
Message-ID: <BeOmFEPfHPD54-XrtYAWrQKFLUyJgTHWlvuJE6gOTOo=.084d3194-03b2-4c29-a96d-3e774874bce0@github.com>

On Sat, 18 Dec 2021 21:48:33 GMT, amirhadadi <duke at openjdk.java.net> wrote:

>> This does look like a HotSpot JIT compiler issue to me.  My guess is that it is related to how checkBoundsOffCount() checks for offset < 0:
>> 
>> 396          if ((length | fromIndex | size) < 0 || size > length - fromIndex)
>> 
>> using | to combine three values.
>
> @dean-long actually the issue reproduces with Java 17 where `checkBoundsOffCount` was implemented in a more straight forward manner:
> 
> 
> static void checkBoundsOffCount(int offset, int count, int length) {
>     if (offset < 0 || count < 0 || offset > length - count) {
>         throw new StringIndexOutOfBoundsException(
>             "offset " + offset + ", count " + count + ", length " + length);
>     }
> }
> 
> 
> 
> Here's a [gist](https://gist.github.com/amirhadadi/9505c3f5d9ad68cad2fbfd1b9e01f0b8) with a benchmark you can run. This benchmark compares safe and unsafe reads from the byte array  (In this gist I didn't modify the code to add the offset >= 0 condition).
> 
> Here are the results:
> 
> 
> OpenJDK 17.0.1+12
> OSX with 2.9 GHz Quad-Core Intel Core i7
> 
> 
> 
> Benchmark                       Mode  Cnt    Score    Error  Units
> StringBenchmark.safeDecoding    avgt   20  120.312 ? 11.674  ns/op
> StringBenchmark.unsafeDecoding  avgt   20   72.628 ?  0.479  ns/op

@amirhadadi unsafeDecode() is buggy I think. Offsets in the array when read with unsafe should be computed as `offset * unsafe.ARRAY_BYTE_INDEX_SCALE + unsafe.ARRAY_BYTE_BASE_OFFSET`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From rriggs at openjdk.java.net  Tue Dec 21 14:28:19 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 14:28:19 GMT
Subject: Integrated: 8278087: Deserialization filter and filter factory
 property error reporting under specified
In-Reply-To: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
References: <kQmnE_2k9XjnOdrMiHcceN0o3t32goW-_7vFMfiAXgQ=.c9db6577-448a-4d9c-97a5-9cce113caca9@github.com>
Message-ID: <mpHL3gKa4cMl8lyOGzNsOHwjLT3w3PJh41r_khXtpAU=.d515496e-a3be-436f-affb-1e7259a13440@github.com>

On Wed, 1 Dec 2021 18:19:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The effects of invalid values of `jdk.serialFilter` and `jdk.serialFilterFactory` properties are 
> incompletely specified. The behavior for invalid values of the properties is different and
> use an unconventional exception type, `ExceptionInInitializerError` and leave the `OIF.Config` class
> uninitialized. 
> 
> The exceptions in the `ObjectInputFilter.Config` class initialization caused by invalid values of the two properties, 
> either by system properties supplied on the command line or security properties are logged.
> The `Config` class marks either or both the filter and filter factory values as unusable
> and remembers the exception message.
> 
> Subsequent calls to the methods that get or set the filter or filter factory or create 
> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the remembered exception message.
> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and `Config.getSerialFilterFactory`.
> The nature of the invalid property is reported as an `IllegalStateException` on first use.
> 
> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that setting an invalid property jdk.serialFilter disables deserialization

This pull request has now been integrated.

Changeset: f90425a1
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f90425a1cbbc686045c87086af586e62f05f6c49
Stats:     219 lines in 4 files changed: 136 ins; 15 del; 68 mod

8278087: Deserialization filter and filter factory property error reporting under specified

Reviewed-by: lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6645

From rriggs at openjdk.java.net  Tue Dec 21 15:20:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 15:20:47 GMT
Subject: RFR: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases. [v3]
In-Reply-To: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
References: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
Message-ID: <M5ujjlKnVxFwXtHW3KwUBSssgCxcBWLzY2HaUtq6mv8=.2d9fbeed-a266-41e4-8086-f81bb2dd7039@github.com>

> The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.
> 
> In both constructors, add the following to the paragraph the describes invoking the factory:
> 
>      * When the filter factory {@code apply} method is invoked it may throw a runtime exception
>      * preventing the {@code ObjectInputStream} from being constructed.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8278044-factory-runtime-exceptions
 - Merge branch 'master' into 8278044-factory-runtime-exceptions
 - Clarified that a runtime exception may be thrown by the filter factory returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
   not by the `getSerialFilterFactory` method.
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6704/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6704&range=02
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6704.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6704/head:pull/6704

PR: https://git.openjdk.java.net/jdk/pull/6704

From rriggs at openjdk.java.net  Tue Dec 21 15:20:49 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 15:20:49 GMT
Subject: Integrated: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases.
In-Reply-To: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
References: <bmjfV6vr2bX2bVOKqtyYliVJrkDKi-vQoTYQytDGKkA=.f2a07ac2-f8af-40d8-9a68-0e093f5c9f21@github.com>
Message-ID: <XuToaUeEfH17bSmtPtc_lNDiMkWUjd7mLxb6PG7nPsI=.ebef723d-07df-4e9a-90ce-e9da279208c5@github.com>

On Fri, 3 Dec 2021 16:16:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The specification of ObjectInputStream constructors that invoke `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention exceptions that may be thrown by the apply() method.
> 
> In both constructors, add the following to the paragraph the describes invoking the factory:
> 
>      * When the filter factory {@code apply} method is invoked it may throw a runtime exception
>      * preventing the {@code ObjectInputStream} from being constructed.

This pull request has now been integrated.

Changeset: 8c0bb53f
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c0bb53f5ba6e71b81c9cb99e6f1587150fe531a
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

Reviewed-by: lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/6704

From rriggs at openjdk.java.net  Tue Dec 21 15:47:40 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 15:47:40 GMT
Subject: [jdk18] Integrated: 8278087: Deserialization filter and filter factory
 property error reporting under specified
Message-ID: <TSeIwdsjgDFm5BF6GfdkzmGXgqMMH8xRsRQUaRtgMsQ=.4b45e1fc-6671-4cea-bf56-0b03b4c65af4@github.com>

8278087: Deserialization filter and filter factory property error reporting under specified

-------------

Commit messages:
 - Backport f90425a1cbbc686045c87086af586e62f05f6c49

Changes: https://git.openjdk.java.net/jdk18/pull/55/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=55&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278087
  Stats: 219 lines in 4 files changed: 136 ins; 15 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/55.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/55/head:pull/55

PR: https://git.openjdk.java.net/jdk18/pull/55

From rriggs at openjdk.java.net  Tue Dec 21 15:47:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 15:47:41 GMT
Subject: [jdk18] Integrated: 8278087: Deserialization filter and filter factory
 property error reporting under specified
In-Reply-To: <TSeIwdsjgDFm5BF6GfdkzmGXgqMMH8xRsRQUaRtgMsQ=.4b45e1fc-6671-4cea-bf56-0b03b4c65af4@github.com>
References: <TSeIwdsjgDFm5BF6GfdkzmGXgqMMH8xRsRQUaRtgMsQ=.4b45e1fc-6671-4cea-bf56-0b03b4c65af4@github.com>
Message-ID: <p7VQElThavDLVL_-Xd4kZeKUy5iKyMmDZOakUv0QTRY=.5c856593-1987-4dd7-aa50-46ddeb6dac69@github.com>

On Tue, 21 Dec 2021 15:35:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 8278087: Deserialization filter and filter factory property error reporting under specified

This pull request has now been integrated.

Changeset: db3d6d77
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/db3d6d772411c4e7bc81d6411abb139462e1581f
Stats:     219 lines in 4 files changed: 136 ins; 15 del; 68 mod

8278087: Deserialization filter and filter factory property error reporting under specified

Backport-of: f90425a1cbbc686045c87086af586e62f05f6c49

-------------

PR: https://git.openjdk.java.net/jdk18/pull/55

From rriggs at openjdk.java.net  Tue Dec 21 16:35:31 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 16:35:31 GMT
Subject: [jdk18] Integrated: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases.
Message-ID: <rACcE9RrE1tqOeKR4WqoaZMDN1ZCzGwqwNsBp2FVAyg=.237bc6ae-2479-46f6-b077-8b534859488e@github.com>

8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

-------------

Commit messages:
 - Backport 8c0bb53f5ba6e71b81c9cb99e6f1587150fe531a

Changes: https://git.openjdk.java.net/jdk18/pull/58/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=58&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278044
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/58.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/58/head:pull/58

PR: https://git.openjdk.java.net/jdk18/pull/58

From rriggs at openjdk.java.net  Tue Dec 21 16:35:32 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Dec 2021 16:35:32 GMT
Subject: [jdk18] Integrated: 8278044: ObjectInputStream methods invoking the
 OIF.CFG.getSerialFilterFactory() silent about error cases.
In-Reply-To: <rACcE9RrE1tqOeKR4WqoaZMDN1ZCzGwqwNsBp2FVAyg=.237bc6ae-2479-46f6-b077-8b534859488e@github.com>
References: <rACcE9RrE1tqOeKR4WqoaZMDN1ZCzGwqwNsBp2FVAyg=.237bc6ae-2479-46f6-b077-8b534859488e@github.com>
Message-ID: <ae7rq6Qhft66fLsLfm6EK7ezfSo8llUOLDt7D0gKLug=.8d32c227-82e2-4d4a-a22c-8c9e515f231c@github.com>

On Tue, 21 Dec 2021 16:24:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

This pull request has now been integrated.

Changeset: ac7430cf
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/ac7430cf7efba519c1fd8b1c1b23136bf158f19f
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.

Backport-of: 8c0bb53f5ba6e71b81c9cb99e6f1587150fe531a

-------------

PR: https://git.openjdk.java.net/jdk18/pull/58

From duke at openjdk.java.net  Tue Dec 21 17:04:13 2021
From: duke at openjdk.java.net (amirhadadi)
Date: Tue, 21 Dec 2021 17:04:13 GMT
Subject: RFR: 8278518: String(byte[], int, int,
 Charset) constructor and String.translateEscapes() miss bounds check
 elimination
In-Reply-To: <BeOmFEPfHPD54-XrtYAWrQKFLUyJgTHWlvuJE6gOTOo=.084d3194-03b2-4c29-a96d-3e774874bce0@github.com>
References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com>
 <ArLWV3AldnAQRPGn46-DQATjBZ3fec4N23PZKkQU0lQ=.9a29b27d-b0ab-4b98-99b3-039c20a943e6@github.com>
 <RHrlUP_vYtB1WVKsd0GFKIanvvncbKiMcHCv8seP1Cs=.48e38264-bce3-4800-a08c-3941085b89ad@github.com>
 <BeOmFEPfHPD54-XrtYAWrQKFLUyJgTHWlvuJE6gOTOo=.084d3194-03b2-4c29-a96d-3e774874bce0@github.com>
Message-ID: <NwPLjd6W6MooY6qKy45z7QRifyJTjRn8OX8vdrczB7E=.708bfac1-805d-4080-be96-8b5fe1e4955e@github.com>

On Tue, 21 Dec 2021 12:50:36 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @dean-long actually the issue reproduces with Java 17 where `checkBoundsOffCount` was implemented in a more straight forward manner:
>> 
>> 
>> static void checkBoundsOffCount(int offset, int count, int length) {
>>     if (offset < 0 || count < 0 || offset > length - count) {
>>         throw new StringIndexOutOfBoundsException(
>>             "offset " + offset + ", count " + count + ", length " + length);
>>     }
>> }
>> 
>> 
>> 
>> Here's a [gist](https://gist.github.com/amirhadadi/9505c3f5d9ad68cad2fbfd1b9e01f0b8) with a benchmark you can run. This benchmark compares safe and unsafe reads from the byte array  (In this gist I didn't modify the code to add the offset >= 0 condition).
>> 
>> Here are the results:
>> 
>> 
>> OpenJDK 17.0.1+12
>> OSX with 2.9 GHz Quad-Core Intel Core i7
>> 
>> 
>> 
>> Benchmark                       Mode  Cnt    Score    Error  Units
>> StringBenchmark.safeDecoding    avgt   20  120.312 ? 11.674  ns/op
>> StringBenchmark.unsafeDecoding  avgt   20   72.628 ?  0.479  ns/op
>
> @amirhadadi unsafeDecode() is buggy I think. Offsets in the array when read with unsafe should be computed as `offset * unsafe.ARRAY_BYTE_INDEX_SCALE + unsafe.ARRAY_BYTE_BASE_OFFSET`.

@rwestrel thanks for the correction!

Here are the updated results:


Benchmark                       Mode  Cnt    Score   Error  Units
StringBenchmark.safeDecoding    avgt   20  113.849 ? 1.609  ns/op
StringBenchmark.unsafeDecoding  avgt   20   85.272 ? 1.462  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/6812

From jwilhelm at openjdk.java.net  Tue Dec 21 19:59:51 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 19:59:51 GMT
Subject: RFR: Merge jdk18
Message-ID: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8278627: Shenandoah: TestHeapDump test failed
 - 8279074: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.
 - 8278087: Deserialization filter and filter factory property error reporting under specified
 - 8279011: JFR: JfrChunkWriter incorrectly handles int64_t chunk size as size_t
 - 8274323: compiler/codegen/aes/TestAESMain.java failed with "Error: invalid offset: -1434443640" after 8273297
 - 8278609: [macos] accessibility frame is misplaced on a secondary monitor on macOS
 - 8278413: C2 crash when allocating array of size too large
 - 8278970: [macos] SigningPackageTest is failed with runtime exception
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f31dead6...d5d5bad9

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6911/files
  Stats: 1086 lines in 80 files changed: 695 ins; 107 del; 284 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911

PR: https://git.openjdk.java.net/jdk/pull/6911

From mandy.chung at oracle.com  Tue Dec 21 20:25:52 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Dec 2021 12:25:52 -0800
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <CAMm6HcAWA-6ADCZWzVaChCUO5g2PVRiXnfRGX=pQmu9bP756Kg@mail.gmail.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
 <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
 <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>
 <CAMm6HcAWA-6ADCZWzVaChCUO5g2PVRiXnfRGX=pQmu9bP756Kg@mail.gmail.com>
Message-ID: <e7f9f24c-1f84-451d-ef83-38b7835d23bc@oracle.com>

The issue has existed since the initial support of multi-release JARs 
(JDK-8153654 <https://bugs.openjdk.java.net/browse/JDK-8153654>) since 
JDK 9.

Mandy

On 12/20/21 7:38 PM, Raymond Aug? wrote:
> I should add that I have reproduced this issue on Java 11 and 17. The 
> ticket only indicates Java 18 but that in not accurate.
>
> On Mon., Dec. 20, 2021, 1:33 p.m. Raymond Aug?, 
> <raymond.auge at liferay.com> wrote:
>
>     Thank you Mandy.
>
>     On Mon., Dec. 20, 2021, 1:19 p.m. Mandy Chung,
>     <mandy.chung at oracle.com> wrote:
>
>         Yes this bug is known and tracked by JDK-8277681.? The proper
>         solution should make each JdepsTask to maintain its own map of
>         multi-versioned entries rather than a global nameToVersion map
>         for the running VM as described in
>         JDK-8277681.
>
>         Mandy
>
>         On 12/18/21 7:47 PM, Raymond Aug? wrote:
>>         Hello everyone,
>>
>>         At Alan's request [3] I'm posting this here. Alan mentions this is likely a
>>         manifestation of JDK-8277681 [4]. From the description I would agree.
>>
>>         Here is a copy of the original message for posterity.
>>         -------------------
>>         I believe I have found a small bug in jdeps tool when used as ToolProvider.
>>
>>         I am invoking the jdeps impl via the ToolProvider API as follows (this code
>>         is also available here [2]):
>>
>>            try (final StringWriter stdout = new StringWriter();
>>                final StringWriter stderr = new StringWriter();
>>                final PrintWriter pwout = new PrintWriter(stdout);
>>                final PrintWriter pwerr = new PrintWriter(stderr)) {
>>
>>              return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
>>         args) == 0) ?
>>                stdout.toString() :
>>                "Error: ".concat(stderr.toString());
>>            }
>>            catch (Throwable t) {
>>              t.printStackTrace();
>>              return "Error: " + t.getMessage();
>>            }
>>
>>         However repeat invocations result in the following exception:
>>
>>         java.lang.Error: java.util.concurrent.ExecutionException:
>>         com.sun.tools.jdeps.MultiReleaseException
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
>>         at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
>>         at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
>>         at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
>>         at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
>>         at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>>            [snip]
>>         Caused by: java.util.concurrent.ExecutionException:
>>         com.sun.tools.jdeps.MultiReleaseException
>>         at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>>         at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
>>         ... 24 more
>>         Caused by: com.sun.tools.jdeps.MultiReleaseException
>>         at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
>>         at
>>         jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
>>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>         at
>>         java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>         at
>>         java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>         at
>>         java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>         at java.base/java.lang.Thread.run(Thread.java:829)
>>
>>         In order to get around the error I do the following:
>>
>>         public static final Field field;
>>         public static final Map<?,?> map;
>>
>>         static {
>>            try {
>>              Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>>              field = clazz.getDeclaredField("nameToVersion");
>>              field.setAccessible(true);
>>              map = (Map<?,?>)field.get(null);
>>            }
>>            catch (ReflectiveOperationException e) {
>>              throw new RuntimeException(e);
>>            }
>>         }
>>
>>         and tack a finally to the end of the try above:
>>
>>         finally {
>>            map.clear();
>>         }
>>
>>         Now, additionally to be able to do that, I need to add an `--add-opens`:
>>
>>         --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>>
>>         I believe the solution is to clear the map in [1] when jdeps finishes.
>>
>>         Finally, I would send a PR myself except I do not (yet) have an OCA and the
>>         solution seems simple enough if someone can confirm that this is indeed a
>>         bug.
>>
>>         Ray
>>
>>         [1]
>>         https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java  <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg4gPsG-7A$>
>>         [2]https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852  <https://urldefense.com/v3/__https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg69o94Tag$>
>>         [3]
>>         https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
>>         [4]https://bugs.openjdk.java.net/browse/JDK-8277681
>

From raymond.auge at liferay.com  Tue Dec 21 20:38:16 2021
From: raymond.auge at liferay.com (=?UTF-8?Q?Raymond_Aug=C3=A9?=)
Date: Tue, 21 Dec 2021 15:38:16 -0500
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <e7f9f24c-1f84-451d-ef83-38b7835d23bc@oracle.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
 <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
 <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>
 <CAMm6HcAWA-6ADCZWzVaChCUO5g2PVRiXnfRGX=pQmu9bP756Kg@mail.gmail.com>
 <e7f9f24c-1f84-451d-ef83-38b7835d23bc@oracle.com>
Message-ID: <CAMm6HcCj5sk7AKYOars4NNQpLg_mw3tA3Zevz=i5=pLyhr_Skg@mail.gmail.com>

Mandy, would you accept a PR for this?

(I would have to start the process to get an OCA.)

Ray

On Tue, Dec 21, 2021 at 3:26 PM Mandy Chung <mandy.chung at oracle.com> wrote:

> The issue has existed since the initial support of multi-release JARs (
> JDK-8153654 <https://bugs.openjdk.java.net/browse/JDK-8153654>) since JDK
> 9.
>
> Mandy
>
> On 12/20/21 7:38 PM, Raymond Aug? wrote:
>
> I should add that I have reproduced this issue on Java 11 and 17. The
> ticket only indicates Java 18 but that in not accurate.
>
> On Mon., Dec. 20, 2021, 1:33 p.m. Raymond Aug?, <raymond.auge at liferay.com>
> wrote:
>
>> Thank you Mandy.
>>
>> On Mon., Dec. 20, 2021, 1:19 p.m. Mandy Chung, <mandy.chung at oracle.com>
>> wrote:
>>
>>> Yes this bug is known and tracked by JDK-8277681.  The proper solution
>>> should make each JdepsTask to maintain its own map of multi-versioned
>>> entries rather than a global nameToVersion map for the running VM as
>>> described in
>>> JDK-8277681.
>>>
>>> Mandy
>>>
>>> On 12/18/21 7:47 PM, Raymond Aug? wrote:
>>>
>>> Hello everyone,
>>>
>>> At Alan's request [3] I'm posting this here. Alan mentions this is likely a
>>> manifestation of JDK-8277681 [4]. From the description I would agree.
>>>
>>> Here is a copy of the original message for posterity.
>>> -------------------
>>> I believe I have found a small bug in jdeps tool when used as ToolProvider.
>>>
>>> I am invoking the jdeps impl via the ToolProvider API as follows (this code
>>> is also available here [2]):
>>>
>>>   try (final StringWriter stdout = new StringWriter();
>>>       final StringWriter stderr = new StringWriter();
>>>       final PrintWriter pwout = new PrintWriter(stdout);
>>>       final PrintWriter pwerr = new PrintWriter(stderr)) {
>>>
>>>     return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
>>> args) == 0) ?
>>>       stdout.toString() :
>>>       "Error: ".concat(stderr.toString());
>>>   }
>>>   catch (Throwable t) {
>>>     t.printStackTrace();
>>>     return "Error: " + t.getMessage();
>>>   }
>>>
>>> However repeat invocations result in the following exception:
>>>
>>> java.lang.Error: java.util.concurrent.ExecutionException:
>>> com.sun.tools.jdeps.MultiReleaseException
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
>>> at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
>>> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
>>> at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
>>> at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
>>> at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>>>   [snip]
>>> Caused by: java.util.concurrent.ExecutionException:
>>> com.sun.tools.jdeps.MultiReleaseException
>>> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>>> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
>>> ... 24 more
>>> Caused by: com.sun.tools.jdeps.MultiReleaseException
>>> at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
>>> at
>>> jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
>>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>> at
>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>> at
>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>> at
>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>> at java.base/java.lang.Thread.run(Thread.java:829)
>>>
>>> In order to get around the error I do the following:
>>>
>>> public static final Field field;
>>> public static final Map<?,?> map;
>>>
>>> static {
>>>   try {
>>>     Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>>>     field = clazz.getDeclaredField("nameToVersion");
>>>     field.setAccessible(true);
>>>     map = (Map<?,?>)field.get(null);
>>>   }
>>>   catch (ReflectiveOperationException e) {
>>>     throw new RuntimeException(e);
>>>   }
>>> }
>>>
>>> and tack a finally to the end of the try above:
>>>
>>> finally {
>>>   map.clear();
>>> }
>>>
>>> Now, additionally to be able to do that, I need to add an `--add-opens`:
>>>
>>> --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>>>
>>> I believe the solution is to clear the map in [1] when jdeps finishes.
>>>
>>> Finally, I would send a PR myself except I do not (yet) have an OCA and the
>>> solution seems simple enough if someone can confirm that this is indeed a
>>> bug.
>>>
>>> Ray
>>>
>>> [1]https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg4gPsG-7A$>
>>> [2] https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852 <https://urldefense.com/v3/__https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg69o94Tag$>
>>> [3]https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8277681
>>>
>>>
>>>
>

-- 
*Raymond Aug?* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

From mandy.chung at oracle.com  Tue Dec 21 20:59:14 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Dec 2021 12:59:14 -0800
Subject: possible bug in jdeps as ToolProvider
In-Reply-To: <CAMm6HcCj5sk7AKYOars4NNQpLg_mw3tA3Zevz=i5=pLyhr_Skg@mail.gmail.com>
References: <CAMm6HcCrREc8Q-7TehdW2X__N0B9Kqmz7A8_3fSpqrsmQyAniA@mail.gmail.com>
 <c0e3b6c2-67ca-c5e1-d646-d94274624caa@oracle.com>
 <CAMm6HcDVYLXk7Cb+1qzXRkzOF5kk9Kv4gX65bYAuzqxE9oR8pA@mail.gmail.com>
 <CAMm6HcAWA-6ADCZWzVaChCUO5g2PVRiXnfRGX=pQmu9bP756Kg@mail.gmail.com>
 <e7f9f24c-1f84-451d-ef83-38b7835d23bc@oracle.com>
 <CAMm6HcCj5sk7AKYOars4NNQpLg_mw3tA3Zevz=i5=pLyhr_Skg@mail.gmail.com>
Message-ID: <8bb9f3bb-d30e-2b16-b5b4-c6b98efe1d95@oracle.com>

Your contribution is welcome but this may not be a starter bug.?? The 
proper fix is to change it to per-jdeps-invocation map but not clearing 
the map.? I haven't put time to think through the best way to fix it 
cleanly.

Mandy

On 12/21/21 12:38 PM, Raymond Aug? wrote:
> Mandy, would you accept a PR for this?
>
> (I would have to start the process to get an OCA.)
>
> Ray
>
> On Tue, Dec 21, 2021 at 3:26 PM Mandy Chung <mandy.chung at oracle.com> 
> wrote:
>
>     The issue has existed since the initial support of multi-release
>     JARs (JDK-8153654
>     <https://bugs.openjdk.java.net/browse/JDK-8153654>) since JDK 9.
>
>     Mandy
>
>     On 12/20/21 7:38 PM, Raymond Aug? wrote:
>>     I should add that I have reproduced this issue on Java 11 and 17.
>>     The ticket only indicates Java 18 but that in not accurate.
>>
>>     On Mon., Dec. 20, 2021, 1:33 p.m. Raymond Aug?,
>>     <raymond.auge at liferay.com> wrote:
>>
>>         Thank you Mandy.
>>
>>         On Mon., Dec. 20, 2021, 1:19 p.m. Mandy Chung,
>>         <mandy.chung at oracle.com> wrote:
>>
>>             Yes this bug is known and tracked by JDK-8277681.? The
>>             proper solution should make each JdepsTask to maintain
>>             its own map of multi-versioned entries rather than a
>>             global nameToVersion map for the running VM as described in
>>             JDK-8277681.
>>
>>             Mandy
>>
>>             On 12/18/21 7:47 PM, Raymond Aug? wrote:
>>>             Hello everyone,
>>>
>>>             At Alan's request [3] I'm posting this here. Alan mentions this is likely a
>>>             manifestation of JDK-8277681 [4]. From the description I would agree.
>>>
>>>             Here is a copy of the original message for posterity.
>>>             -------------------
>>>             I believe I have found a small bug in jdeps tool when used as ToolProvider.
>>>
>>>             I am invoking the jdeps impl via the ToolProvider API as follows (this code
>>>             is also available here [2]):
>>>
>>>                try (final StringWriter stdout = new StringWriter();
>>>                    final StringWriter stderr = new StringWriter();
>>>                    final PrintWriter pwout = new PrintWriter(stdout);
>>>                    final PrintWriter pwerr = new PrintWriter(stderr)) {
>>>
>>>                  return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
>>>             args) == 0) ?
>>>                    stdout.toString() :
>>>                    "Error: ".concat(stderr.toString());
>>>                }
>>>                catch (Throwable t) {
>>>                  t.printStackTrace();
>>>                  return "Error: " + t.getMessage();
>>>                }
>>>
>>>             However repeat invocations result in the following exception:
>>>
>>>             java.lang.Error: java.util.concurrent.ExecutionException:
>>>             com.sun.tools.jdeps.MultiReleaseException
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
>>>             at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
>>>             at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
>>>             at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
>>>             at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
>>>             at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
>>>                [snip]
>>>             Caused by: java.util.concurrent.ExecutionException:
>>>             com.sun.tools.jdeps.MultiReleaseException
>>>             at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>>>             at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
>>>             ... 24 more
>>>             Caused by: com.sun.tools.jdeps.MultiReleaseException
>>>             at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
>>>             at
>>>             jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
>>>             at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>>             at
>>>             java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>>>             at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>>             at
>>>             java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>>             at
>>>             java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>>             at java.base/java.lang.Thread.run(Thread.java:829)
>>>
>>>             In order to get around the error I do the following:
>>>
>>>             public static final Field field;
>>>             public static final Map<?,?> map;
>>>
>>>             static {
>>>                try {
>>>                  Class<?> clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
>>>                  field = clazz.getDeclaredField("nameToVersion");
>>>                  field.setAccessible(true);
>>>                  map = (Map<?,?>)field.get(null);
>>>                }
>>>                catch (ReflectiveOperationException e) {
>>>                  throw new RuntimeException(e);
>>>                }
>>>             }
>>>
>>>             and tack a finally to the end of the try above:
>>>
>>>             finally {
>>>                map.clear();
>>>             }
>>>
>>>             Now, additionally to be able to do that, I need to add an `--add-opens`:
>>>
>>>             --add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
>>>
>>>             I believe the solution is to clear the map in [1] when jdeps finishes.
>>>
>>>             Finally, I would send a PR myself except I do not (yet) have an OCA and the
>>>             solution seems simple enough if someone can confirm that this is indeed a
>>>             bug.
>>>
>>>             Ray
>>>
>>>             [1]
>>>             https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java  <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg4gPsG-7A$>
>>>             [2]https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852  <https://urldefense.com/v3/__https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852__;!!ACWV5N9M2RV99hQ!ep-GUts1P9CJOX1wA0Rd6QP3kuSFocnoeMKvPETK7DYwDQJqLJcxumOCMg69o94Tag$>
>>>             [3]
>>>             https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
>>>             [4]https://bugs.openjdk.java.net/browse/JDK-8277681
>>
>
>
>
> -- 
> *Raymond Aug?*?(@rotty3000)
> Senior Software Architect *Liferay, Inc.*?(@Liferay)
> OSGi Fellow, Java Champion

From dholmes at openjdk.java.net  Tue Dec 21 21:45:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 21:45:14 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <XCbGplub5NvbUblllEMQxytUHkXupGhgFKHw5yW8jmQ=.e33a3f0a-94cb-45ac-b2ef-b023da85a175@github.com>
Message-ID: <lOWbt6DA6Y3Po8N2D8gFQm1BRhbeEC9N6Wnql2u4c_k=.44a8986c-38db-489e-bd78-02c4c2f0a7dd@github.com>

On Sun, 19 Dec 2021 07:37:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the default SM. Some difference may be observed if someone is running rmiregistry with a custom system class loader set, or custom file system provider, or running it with a JVM TI agent that is looking at events between VMStart and VMInit but these seem somewhat obscure scenarios for a command line program If rmiregstry worked with ToolProvider then I think there would be more to discuss. If the final patch is to have the launcher set the default security manager then we may want to change RegistryImpl.createRegistry to fail if not set.
> 
> The warning that is emitted for both cases is expected. JEP 411 is very clear that it there is no mechanism to suppress it. We may need to add a release note to document that rmiregistry will emit a warning a startup, that will at least be something to point at in the event that anyone asks or reports an issue.

In the same kind of PR (https://github.com/openjdk/jdk18/pull/53) for `jstatd` @AlanBateman writes:
> This looks okay in that it is now worked exactly as it did in JDK 17.

And that PR uses `allow` as I have suggested here (to preserve existing behaviour). All the affected launchers should be fixed in the same consistent way.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/45

From jwilhelm at openjdk.java.net  Tue Dec 21 22:02:00 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 22:02:00 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
Message-ID: <06_kDiLlkp6QNtnHGLkuV7TxzucQtDwRaGLnjWX0dpM=.a14aed52-214c-4723-be0c-6bf07ef3a6e0@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:

 - Merge
 - 8279043: Some Security Exception Messages Miss Spaces
   
   Reviewed-by: weijun
 - 8278793: Interpreter(x64) intrinsify Thread.currentThread()
   
   Reviewed-by: rkennke, dcubed, dholmes
 - 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases.
   
   Reviewed-by: lancea, bpb
 - 8278087: Deserialization filter and filter factory property error reporting under specified
   
   Reviewed-by: lancea, bpb
 - 8278917: Use Prev Bitmap for recording evac failed objects
   
   Reviewed-by: ayang, mli, tschatzl
 - 8277893: Arraycopy stress tests
   
   Reviewed-by: kvn, mli
 - 8278893: Parallel: Remove GCWorkerDelayMillis
   
   Reviewed-by: ayang, mli
 - 8278953: Clarify Class.getDeclaredConstructor specification
   
   Reviewed-by: mchung, alanb
 - 8277100: Dynamic dump can inadvertently overwrite default CDS archive
   
   Reviewed-by: iklam, minqi, dholmes
 - ... and 86 more: https://git.openjdk.java.net/jdk/compare/1128674d...d5d5bad9

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6911/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6911&range=01
  Stats: 18631 lines in 509 files changed: 14435 ins; 3002 del; 1194 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6911/head:pull/6911

PR: https://git.openjdk.java.net/jdk/pull/6911

From jwilhelm at openjdk.java.net  Tue Dec 21 22:02:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 21 Dec 2021 22:02:03 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
References: <2qAXnV7AsRJ0Z5Of9gkLOHIACVFGRfrl3MVhJsfpSew=.b02d2da2-3ce5-497d-a979-4e602c3834be@github.com>
Message-ID: <TnCXLVYvZ6SiDvL3L7DRxa_QvPaRL5uUITCHiS9QCsM=.e6e56e39-bf83-40f9-a83c-be5cda06fce3@github.com>

On Tue, 21 Dec 2021 19:50:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 803cb8a7
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/803cb8a76827a21fcf9e033b4ca6a777c509169b
Stats:     1086 lines in 80 files changed: 695 ins; 107 del; 284 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6911

From smarks at openjdk.java.net  Wed Dec 22 01:18:58 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 01:18:58 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>

> Enable the security manager in rmiregistry's launcher arguments.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Change java.security.manager to "allow"; filter warning lines from VersionCheck

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/45/files
  - new: https://git.openjdk.java.net/jdk18/pull/45/files/e899bd2d..f713e731

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=45&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=45&range=00-01

  Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/45/head:pull/45

PR: https://git.openjdk.java.net/jdk18/pull/45

From smarks at openjdk.java.net  Wed Dec 22 01:30:15 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 01:30:15 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <j9NA-OXmsxCzk4qdqOD2zt8y8hTAQS35ShajqVh0t0I=.39eee2a3-eccd-4f61-a938-18d71d9560c0@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

Enabling the security manager using a property, versus setting the property to `allow` and enabling it in code, is mostly a distinction without a difference. I don't think there is really a need to have the different tools be consistent. Local tool considerations probably swamp the need for any cross-tool consistency.

In this case some of the RMI registry tests set the property to `allow` on the command line and then rely on the code to enable the security manager using the API, so it's much easier to switch the `rmiregistry` launcher to use the `allow` technique instead. This is sort-of the tail (the tests) wagging the doc (the tool) but there doesn't seem to any benefit to be gained from fiddling around with the tests and the RMI test library.

I've also updated VersionCheck.java to filter out the security manager warning messages.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/45

From duke at openjdk.java.net  Wed Dec 22 07:33:55 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:33:55 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight
 when matching "*" (as if it is 1) [v2]
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

Daniel Le has updated the pull request incrementally with one additional commit since the last revision:

  Address most review comments
  
  - Include "// change to lowercase for case-insensitive matching" and "//
    preserving the case of the input tag" in the if branch in the for loop
    of LocaleMatcher.{filterBasic,filterExtended}
  
  - Remove LocaleMatcher.removeDuplicates since is it no longer used
  
  - For Bug7069824.java, add 8276302 to the @bug tag and update the
    copyright year to 2021
  
  https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6789/files
  - new: https://git.openjdk.java.net/jdk/pull/6789/files/85d71141..c3abb980

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6789&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6789&range=00-01

  Stats: 17 lines in 2 files changed: 4 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6789/head:pull/6789

PR: https://git.openjdk.java.net/jdk/pull/6789

From duke at openjdk.java.net  Wed Dec 22 07:44:19 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:44:19 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight
 when matching "*" (as if it is 1) [v2]
In-Reply-To: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
Message-ID: <fPVNFVfbz9RgxD3xTTqkBVfS8lIvFVzpJR2X7KLdbrc=.40b1cc92-bd5e-436d-a5ea-f0010928abb5@github.com>

On Wed, 22 Dec 2021 07:33:55 GMT, Daniel Le <duke at openjdk.java.net> wrote:

>> Locale.filterTags methods ignore actual weight when matching "*" (as if
>> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>> 
>> Fix the bug and add regression test cases for it as well as existing
>> behavior.
>
> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address most review comments
>   
>   - Include "// change to lowercase for case-insensitive matching" and "//
>     preserving the case of the input tag" in the if branch in the for loop
>     of LocaleMatcher.{filterBasic,filterExtended}
>   
>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>   
>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>     copyright year to 2021
>   
>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

I've addressed most of your comments in https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415 except for https://github.com/openjdk/jdk/pull/6789/files#r772577336. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6789

From duke at openjdk.java.net  Wed Dec 22 07:44:22 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:44:22 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight
 when matching "*" (as if it is 1) [v2]
In-Reply-To: <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>
Message-ID: <GSZqhE7VJ4P5G5j5IDUz634s6XAEb7PlgisB3ZLX_Y0=.098ee3f3-b663-488d-a733-12be2dd62b78@github.com>

On Mon, 20 Dec 2021 18:18:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address most review comments
>>   
>>   - Include "// change to lowercase for case-insensitive matching" and "//
>>     preserving the case of the input tag" in the if branch in the for loop
>>     of LocaleMatcher.{filterBasic,filterExtended}
>>   
>>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>>   
>>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>>     copyright year to 2021
>>   
>>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415
>
> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 131:
> 
>> 129: 
>> 130:                     if (!caseInsensitiveMatch(list, lowerCaseTag)
>> 131:                             && !shouldIgnoreFilterBasicMatch(zeroRanges, lowerCaseTag)) {
> 
> Is there any reason to flip the evaluation order of the `if` statement?

Two reasons:
  - It's consistent with the `else`  branch in the `for` loop of `LocaleMatcher.{filterBasic,filterExtended}` (main)
  - I thought that `caseInsensitiveMatch` being first made it clear the need for `lowerCaseTag` but now noticed that the comment was meant for `{shouldIgnoreFilterBasicMatch,shouldIgnoreFilterExtendedMatch}` instead

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 157:
> 
>> 155:      * returning all the tags, remove those which are matching the range with
>> 156:      * quality weight q=0.
>> 157:      */
> 
> Please keep the comments in the modified code (except the `*` part). Although it's OK to remove this method as it eliminates extra `ArrayList` allocation, please keep the comments in the modified code (except the `*` part).

I've tried to follow your suggestion but I think this comment is no longer necessary. (The tags are no longer removed and no collections are updated.)

I had noticed that this comment could not be added back verbatim to the modified code. Hence, I tried to rewrite it. However, I noticed that the comments for `LocaleMatcher{shouldIgnoreFilterBasicMatch,shouldIgnoreFilterExtendedMatch}` clearly covers what we wanted to highlight here.

Let me know if you disagree together with a comment that you'd like me to include verbatim.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 161:
> 
>> 159:             List<LanguageRange> zeroRange, Collection<String> tags) {
>> 160:         if (zeroRange.isEmpty()) {
>> 161:             tags = removeDuplicates(tags);
> 
> Can `removeDuplicates()` now be removed? There seems to be no usage.

Done.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 167:
> 
>> 165:         List<String> matchingTags = new ArrayList<>();
>> 166:         for (String tag : tags) {
>> 167:             // change to lowercase for case-insensitive matching
> 
> Applies to this comment.

Done.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 171:
> 
>> 169:             if (!shouldIgnoreFilterBasicMatch(zeroRange, lowerCaseTag)
>> 170:                     && !caseInsensitiveMatch(matchingTags, lowerCaseTag)) {
>> 171:                 matchingTags.add(tag); // preserving the case of the input tag
> 
> And this comment, too.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6789

From alanb at openjdk.java.net  Wed Dec 22 10:38:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 22 Dec 2021 10:38:27 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <e0AhmU1AsthfpxKX-ewDJSp-UfO6V7z-8WA_NxnF6mk=.e3ceb171-14e6-4bcd-b4d5-4476fc6bb4ad@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

This version looks okay, avoids having an attempt to set the SM in createRegistry always be skipped.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/45

From serb at openjdk.java.net  Wed Dec 22 10:57:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 22 Dec 2021 10:57:37 GMT
Subject: RFR: 8279134: Fix Amazon copyright in various files
Message-ID: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>

This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094

Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year):

"Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." 

@simonis @phohensee

-------------

Commit messages:
 - Initial fix JDK-8279134

Changes: https://git.openjdk.java.net/jdk/pull/6915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279134
  Stats: 15 lines in 14 files changed: 0 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6915/head:pull/6915

PR: https://git.openjdk.java.net/jdk/pull/6915

From erikj at openjdk.java.net  Wed Dec 22 13:40:12 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 22 Dec 2021 13:40:12 GMT
Subject: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled [v2]
In-Reply-To: <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
 <dq9vvL2gRPYKbKvfrU-hjqXFbgueqNRYW5KEcr9Liho=.74d63971-ce7e-4440-b161-3b8c259fd41a@github.com>
Message-ID: <kdpb7afCAOo48qmkWEhACRErDBfXKhyq_kjt7exSgZE=.f01d9fab-4fbd-49ea-8610-97fd7f7e9d49@github.com>

On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java.security.manager to "allow"; filter warning lines from VersionCheck

Build change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/45

From jwilhelm at openjdk.java.net  Wed Dec 22 16:12:51 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:12:51 GMT
Subject: RFR: Merge jdk18
Message-ID: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8274315: JFR: One closed state per file or stream
 - 8271447: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters
 - 8278987: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in __write_sample_info__
 - 8279007: jstatd fails to start because SecurityManager is disabled
 - 8278508: Enable X86 maskAll instruction pattern for 32 bit JVM.
 - 8279045: Intrinsics missing vzeroupper instruction

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6918/files
  Stats: 260 lines in 21 files changed: 170 ins; 55 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918

PR: https://git.openjdk.java.net/jdk/pull/6918

From jwilhelm at openjdk.java.net  Wed Dec 22 16:51:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:51:03 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
Message-ID: <F4hx0Py0VaieiF4QlekcSe5e5ApHCSYgKX-jdlEOULY=.0942e438-8ba7-4460-89f7-62a7dcfe66de@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 104 commits:

 - Merge
 - 8279063: Consolidate push and push_if_necessary in PreservedMarks
   
   Reviewed-by: rkennke, mli, tschatzl
 - 8279024: Remove javascript references from clhsdb.html
   
   Reviewed-by: kevinw, sspitsyn
 - Merge
 - 8244670: convert clhsdb "whatis" command from javascript to java
   
   Reviewed-by: sspitsyn, kevinw
 - 8279066: entries.remove(entry) is useless in PKCS12KeyStore
   
   Reviewed-by: mullan
 - Merge
 - 8279060: Parallel: Remove unused PSVirtualSpace constructors
   
   Reviewed-by: mli, sjohanss, tschatzl
 - 8278396: G1: Initialize the BOT threshold to be region bottom
   
   Reviewed-by: tschatzl, sjohanss
 - 8279043: Some Security Exception Messages Miss Spaces
   
   Reviewed-by: weijun
 - ... and 94 more: https://git.openjdk.java.net/jdk/compare/dfb15c3e...70630b7b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6918/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6918&range=01
  Stats: 18775 lines in 519 files changed: 14457 ins; 3098 del; 1220 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6918/head:pull/6918

PR: https://git.openjdk.java.net/jdk/pull/6918

From jwilhelm at openjdk.java.net  Wed Dec 22 16:51:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 22 Dec 2021 16:51:06 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
References: <3lthdMVqcFajPqeEx-jq-zEJrqH9TepzZcwKuANCPmA=.fdf1ba32-4e8c-4d40-8568-4467b9e82993@github.com>
Message-ID: <gwBOG6dixu-scUaTjURYxwudcIN4f5wf1jav_dJINCE=.9cc3f162-bc51-46bd-a309-1254000d862f@github.com>

On Wed, 22 Dec 2021 16:03:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: f1fbba23
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1fbba23ebdb28a32977241f8e85b60e10878cbc
Stats:     260 lines in 21 files changed: 170 ins; 55 del; 35 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6918

From naoto at openjdk.java.net  Wed Dec 22 17:52:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 22 Dec 2021 17:52:13 GMT
Subject: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight
 when matching "*" (as if it is 1) [v2]
In-Reply-To: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
Message-ID: <lr1D7AHXylo1RIu2RKOB3LZw2ZADPN9sfE9MesQrzBc=.2eb1bb38-bac0-4eb3-9bc6-5e2113e63168@github.com>

On Wed, 22 Dec 2021 07:33:55 GMT, Daniel Le <duke at openjdk.java.net> wrote:

>> Locale.filterTags methods ignore actual weight when matching "*" (as if
>> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>> 
>> Fix the bug and add regression test cases for it as well as existing
>> behavior.
>
> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address most review comments
>   
>   - Include "// change to lowercase for case-insensitive matching" and "//
>     preserving the case of the input tag" in the if branch in the for loop
>     of LocaleMatcher.{filterBasic,filterExtended}
>   
>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>   
>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>     copyright year to 2021
>   
>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

Thanks for the changes. Those all look good. I will sponsor this PR once it is integrated.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6789

From smarks at openjdk.java.net  Wed Dec 22 19:00:22 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 22 Dec 2021 19:00:22 GMT
Subject: [jdk18] Integrated: JDK-8278967 rmiregistry fails to start because
 SecurityManager is disabled
In-Reply-To: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
References: <SziE17Iv5XvNQ3fXtIPMLyhyevlw5BMZrqsC2HDhy2o=.39c1f9fd-22a2-40d0-ac98-8da95f34f52f@github.com>
Message-ID: <gysG0Nmb72FD1H__mYsvemMT2k220M3Pd2qvQpPZ_0k=.46182bd6-4427-424a-bdbc-566c50808b8f@github.com>

On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Enable the security manager in rmiregistry's launcher arguments.

This pull request has now been integrated.

Changeset: 04ee9211
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/04ee9211fcc59178b3bfdfdda5e0def9b0f29ada
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8278967: rmiregistry fails to start because SecurityManager is disabled

Reviewed-by: alanb, erikj

-------------

PR: https://git.openjdk.java.net/jdk18/pull/45

From myano at openjdk.java.net  Thu Dec 23 11:03:45 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 23 Dec 2021 11:03:45 GMT
Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException)
Message-ID: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>

Could you please review the JDK-8272746 bug fixes?
Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries.
It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance.
In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large.

-------------

Commit messages:
 - 8272746: ZipFile can't open big file (NegativeArraySizeException)

Changes: https://git.openjdk.java.net/jdk/pull/6927/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272746
  Stats: 80 lines in 2 files changed: 80 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927

PR: https://git.openjdk.java.net/jdk/pull/6927

From duke at openjdk.java.net  Thu Dec 23 14:15:25 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Thu, 23 Dec 2021 14:15:25 GMT
Subject: Integrated: JDK-8276302: Locale.filterTags methods ignore actual
 weight when matching "*" (as if it is 1)
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <Ja4XWfocBad0_8vnXUizG1uKL_8yy_3NMyxqTci-I18=.e6cc0a6e-50a7-483c-8bbe-f50df0897676@github.com>

On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le <duke at openjdk.java.net> wrote:

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

This pull request has now been integrated.

Changeset: 87cc4e50
Author:    Daniel Le <greenrecyclebin at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/87cc4e5009f6b900c62a91dda1c2f98e4821a492
Stats:     138 lines in 2 files changed: 63 ins; 65 del; 10 mod

8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6789

From alanb at openjdk.java.net  Thu Dec 23 16:46:16 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 23 Dec 2021 16:46:16 GMT
Subject: RFR: 8272746: ZipFile can't open big file
 (NegativeArraySizeException)
In-Reply-To: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>
References: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>
Message-ID: <rSvAD3Boi3h4YE3ZnVkjZR5VF02iC5-4a0K95OJDmA8=.5e6bf819-d7b6-4ed1-83d3-d32753abe2a3@github.com>

On Thu, 23 Dec 2021 10:55:08 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the JDK-8272746 bug fixes?
> Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries.
> It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance.
> In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:

> 1499:                 // read in the CEN and END
> 1500:                 if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) {
> 1501:                     zerror("invalid END header (too large central directory size)");

This check looks correct. It might be a bit clearer to say that "central directory size too large" rather than "too large central directory size".

The bug report says that JDK 8 and the native zip handle these zip files, were you able to check that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6927

From jwilhelm at openjdk.java.net  Thu Dec 23 17:19:53 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 17:19:53 GMT
Subject: RFR: Merge jdk18
Message-ID: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>

Forwardport JDK 18 -> JDK 19

-------------

Commit messages:
 - Merge
 - 8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large
 - 8268297: jdk/jfr/api/consumer/streaming/TestLatestEvent.java times out
 - 8279076: C2: Bad AD file when matching SqrtF with UseSSE=0
 - 8278967: rmiregistry fails to start because SecurityManager is disabled
 - 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/6931/files
  Stats: 299 lines in 17 files changed: 141 ins; 126 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6931/head:pull/6931

PR: https://git.openjdk.java.net/jdk/pull/6931

From javalists at cbfiddle.com  Thu Dec 23 17:59:18 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 23 Dec 2021 09:59:18 -0800
Subject: a quick question about String
Message-ID: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>

Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?


From psandoz at openjdk.java.net  Thu Dec 23 18:34:16 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 23 Dec 2021 18:34:16 GMT
Subject: RFR: 8277155: Compress and expand vector operations
In-Reply-To: <khYJPl1QcmxuX80aPl_hsapCbSnWmB7WmePbUEuZHwM=.fce04a9a-e037-4393-9da4-2a3a98301d8b@github.com>
References: <khYJPl1QcmxuX80aPl_hsapCbSnWmB7WmePbUEuZHwM=.fce04a9a-e037-4393-9da4-2a3a98301d8b@github.com>
Message-ID: <pEQEyMy_TigcJSKJ1pHVlUKN71DCir_DmriqQMb5OB8=.cd8aedbc-a81c-4e65-ab4f-34e4edd230a6@github.com>

On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Add two new cross-lane vector operations, `compress` and `expand`.
> 
> An example of such usage might be code that selects elements from array `a` and stores those selected elements in array `z`:
> 
> 
> int[] a = ...;
> 
> int[] z = ...;
> int ai = 0, zi = 0;
> while (ai < a.length) {
>     IntVector av = IntVector.fromArray(SPECIES, a, ai);
>     // query over elements of vector av
>     // returning a mask marking elements of interest
>     VectorMask<Integer> m = interestingBits(av, ...);
>     IntVector zv = av.compress(m);
>     zv.intoArray(z, zi, m.compress());
>     ai += SPECIES.length();
>     zi += m.trueCount();
> }
> 
> 
> (There's also a more sophisticated version using `unslice` to coalesce matching elements with non-masked stores.)
> 
> Given RDP 1 for 18 is getting close, 2021/12/09, we may not get this reviewed in time and included in [JEP 417](https://openjdk.java.net/jeps/417). Still I think I think it worth starting the review now (the CSR is marked provisional).

keep-alive

-------------

PR: https://git.openjdk.java.net/jdk/pull/6545

From jwilhelm at openjdk.java.net  Thu Dec 23 21:22:01 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 21:22:01 GMT
Subject: RFR: Merge jdk18 [v2]
In-Reply-To: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
References: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
Message-ID: <U55hVLEFuwsZjYsuXiVBXYDFfsCJf4VpKIaj62sWdos=.e9efafae-50cc-42bb-ba02-c177ded59d08@github.com>

> Forwardport JDK 18 -> JDK 19

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:

 - Merge
 - 8279115: Fix internal doc comment errors.
   
   Reviewed-by: mli
 - 8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)
   
   Reviewed-by: naoto
 - 8278766: Enable OpenJDK build support for reproducible jars and jmods using --date
   
   Reviewed-by: erikj
 - 8278125: Some preallocated OOMEs are missing stack trace
   
   Co-authored-by: dongyun.tdy <dongyun.tdy at alibaba-inc.com>
   Reviewed-by: dholmes, coleenp
 - 8244669: convert clhsdb "mem" command from javascript to java
   
   Reviewed-by: sspitsyn, kevinw, poonam
 - 8209398: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed with "PKCS11Exception: CKR_ATTRIBUTE_SENSITIVE"
   
   Reviewed-by: hchao, weijun
 - Merge
 - 8279022: JCmdTestFileSafety.java should check file time stamp for test result
   
   Reviewed-by: ccheung
 - 8279018: CRC calculation in CDS should not include _version and _head_size
   
   Reviewed-by: iklam, ccheung
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/04ad6689...a3fcfa2b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6931/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=01
  Stats: 19323 lines in 545 files changed: 14840 ins; 3205 del; 1278 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6931/head:pull/6931

PR: https://git.openjdk.java.net/jdk/pull/6931

From jwilhelm at openjdk.java.net  Thu Dec 23 21:22:04 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 23 Dec 2021 21:22:04 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
References: <6P4qa0-ey3ccmAWsQvfIev6IB087sfu4lpYtowgR1gE=.1daef932-9673-4d89-98b2-81a35c04e36f@github.com>
Message-ID: <IDIFsv5ilpyholvzSNEyosRm8Ufm5r2cUvejdFAcLH0=.4431daf0-9246-4e36-9bcc-68181165b256@github.com>

On Thu, 23 Dec 2021 17:11:15 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: a3b1c6b0
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a3b1c6b03600da21b00a1f37ea4712096d636b14
Stats:     299 lines in 17 files changed: 141 ins; 126 del; 32 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/6931

From xliu at openjdk.java.net  Thu Dec 23 21:40:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 21:40:16 GMT
Subject: RFR: 8279134: Fix Amazon copyright in various files
In-Reply-To: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
References: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
Message-ID: <VMO_WPDzUzxBDvJo0JLH1uOKZbtEpZeuAxEVFKbQezw=.3c2df08e-4e8d-4988-9926-706656e462b6@github.com>

On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
> 
> Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." 
> 
> @simonis @phohensee

LGTM.  I am not a reviewer. Need other reviewers to approve it.

-------------

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/6915

From ecki at zusammenkunft.net  Thu Dec 23 21:51:55 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 23 Dec 2021 21:51:55 +0000
Subject: a quick question about String
In-Reply-To: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
Message-ID: <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

new String() always creates a new instance.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Alan Snyder <javalists at cbfiddle.com>
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: a quick question about String

Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?


From xenoamess at gmail.com  Thu Dec 23 21:53:46 2021
From: xenoamess at gmail.com (Xeno Amess)
Date: Thu, 23 Dec 2021 21:53:46 +0000
Subject: a quick question about String
In-Reply-To: <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>

never should?as Object can be use as lock.

XenoAmess
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Bernd Eckenfels <ecki at zusammenkunft.net>
Sent: Friday, December 24, 2021 5:51:55 AM
To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: a quick question about String

new String() always creates a new instance.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Alan Snyder <javalists at cbfiddle.com>
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: a quick question about String

Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?


From phh at openjdk.java.net  Thu Dec 23 22:47:11 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 23 Dec 2021 22:47:11 GMT
Subject: RFR: 8279134: Fix Amazon copyright in various files
In-Reply-To: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
References: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
Message-ID: <7ozNgn5YKtgY8XsZYqexriYLPTVz-yZJJcEs2cxSfuQ=.d731d200-f8ef-4999-9e14-f6be115bdf14@github.com>

On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
> 
> Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." 
> 
> @simonis @phohensee

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6915

From simon at dancingcloudservices.com  Thu Dec 23 22:55:45 2021
From: simon at dancingcloudservices.com (Simon Roberts)
Date: Thu, 23 Dec 2021 15:55:45 -0700
Subject: a quick question about String
In-Reply-To: <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>

I think there are two things at stake here, one is that as I understand it,
"new means new", in every case. This is at least partly why the
constructors on soon-to-be value objects are deprecated; they become
meaningless. The other is that if the presumption is that we should
always intern new Strings, I must disagree. Pooling takes time and memory
to manage, and if there are very few duplicates, it's a waste of both. I
believe it should be up to the programmer to decide if this is appropriate
in their situation. Of course, the GC system seems to be capable of
stepping in in some incarnations, which adds something of a counterexample,
but that is, if I recall, configurable.


On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:

> never should?as Object can be use as lock.
>
> XenoAmess
> ________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
> Bernd Eckenfels <ecki at zusammenkunft.net>
> Sent: Friday, December 24, 2021 5:51:55 AM
> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
> core-libs-dev at openjdk.java.net>
> Subject: Re: a quick question about String
>
> new String() always creates a new instance.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
> Alan Snyder <javalists at cbfiddle.com>
> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> An: core-libs-dev <core-libs-dev at openjdk.java.net>
> Betreff: a quick question about String
>
> Do the public constructors of String actually do what their documentation
> says (allocate a new instance), or is there some kind of compiler magic
> that might avoid allocation?
>
>

-- 
Simon Roberts
(303) 249 3613

From serb at openjdk.java.net  Fri Dec 24 00:50:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 24 Dec 2021 00:50:57 GMT
Subject: RFR: 8279134: Fix Amazon copyright in various files [v2]
In-Reply-To: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
References: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
Message-ID: <4TylKnNJehPUtdh9y0wh4Cgq93jq4y4mEQfHEKBJdmA=.907bb3ab-9b11-40da-8957-dfef5f3e21e4@github.com>

> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
> 
> Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." 
> 
> @simonis @phohensee

Sergey Bylokhov 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 JDK-8279134
 - Initial fix JDK-8279134

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6915/files
  - new: https://git.openjdk.java.net/jdk/pull/6915/files/cb05f5bb..52c5d9c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=00-01

  Stats: 619 lines in 42 files changed: 446 ins; 100 del; 73 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6915/head:pull/6915

PR: https://git.openjdk.java.net/jdk/pull/6915

From eolivelli at gmail.com  Fri Dec 24 07:33:27 2021
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Fri, 24 Dec 2021 08:33:27 +0100
Subject: a quick question about String
In-Reply-To: <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
Message-ID: <CACcefge-YY+B7GkZdkp-pEp7Xbq3KvSva8kCfCUdPciw-hDwpQ@mail.gmail.com>

Alan,
are you talking about the fact that you cannot "wrap" an existing
byte[] that you know that you are already encoded ?

In that case the main problem is that the String is supposed to be
immutable and when you pass the byte[] it must be copied in order to
prevent someone else to modify the contents of the array behind the String


Enrico

Il giorno gio 23 dic 2021 alle ore 23:56 Simon Roberts
<simon at dancingcloudservices.com> ha scritto:
>
> I think there are two things at stake here, one is that as I understand it,
> "new means new", in every case. This is at least partly why the
> constructors on soon-to-be value objects are deprecated; they become
> meaningless. The other is that if the presumption is that we should
> always intern new Strings, I must disagree. Pooling takes time and memory
> to manage, and if there are very few duplicates, it's a waste of both. I
> believe it should be up to the programmer to decide if this is appropriate
> in their situation. Of course, the GC system seems to be capable of
> stepping in in some incarnations, which adds something of a counterexample,
> but that is, if I recall, configurable.
>
>
> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
>
> > never should?as Object can be use as lock.
> >
> > XenoAmess
> > ________________________________
> > From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
> > Bernd Eckenfels <ecki at zusammenkunft.net>
> > Sent: Friday, December 24, 2021 5:51:55 AM
> > To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
> > core-libs-dev at openjdk.java.net>
> > Subject: Re: a quick question about String
> >
> > new String() always creates a new instance.
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
> > Alan Snyder <javalists at cbfiddle.com>
> > Gesendet: Thursday, December 23, 2021 6:59:18 PM
> > An: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Betreff: a quick question about String
> >
> > Do the public constructors of String actually do what their documentation
> > says (allocate a new instance), or is there some kind of compiler magic
> > that might avoid allocation?
> >
> >
>
> --
> Simon Roberts
> (303) 249 3613

From myano at openjdk.java.net  Fri Dec 24 11:07:04 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 24 Dec 2021 11:07:04 GMT
Subject: RFR: 8272746: ZipFile can't open big file
 (NegativeArraySizeException) [v2]
In-Reply-To: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>
References: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>
Message-ID: <zCS25YdM8Tpw1DLT-MSyII89VWb8JtDDLEva0VnVPlk=.052d8c47-83e4-4438-a532-d57eea996922@github.com>

> Could you please review the JDK-8272746 bug fixes?
> Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries.
> It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance.
> In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8272746: ZipFile can't open big file (NegativeArraySizeException)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6927/files
  - new: https://git.openjdk.java.net/jdk/pull/6927/files/a85ef0f5..c54c50eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927

PR: https://git.openjdk.java.net/jdk/pull/6927

From myano at openjdk.java.net  Fri Dec 24 11:07:05 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 24 Dec 2021 11:07:05 GMT
Subject: RFR: 8272746: ZipFile can't open big file
 (NegativeArraySizeException) [v2]
In-Reply-To: <rSvAD3Boi3h4YE3ZnVkjZR5VF02iC5-4a0K95OJDmA8=.5e6bf819-d7b6-4ed1-83d3-d32753abe2a3@github.com>
References: <jlMHgWv2FLxrePcljAkKerh-fv1FIT_ntaU7bd-vwK0=.1186e9cf-69ea-4b49-96fa-b718a4d0a9f6@github.com>
 <rSvAD3Boi3h4YE3ZnVkjZR5VF02iC5-4a0K95OJDmA8=.5e6bf819-d7b6-4ed1-83d3-d32753abe2a3@github.com>
Message-ID: <px7thVpLbVW-LXewSLiIizBJz-xBupQtG4qEvFkrPDY=.c362e5ec-d766-4ca3-acd0-de61bdfe10e4@github.com>

On Thu, 23 Dec 2021 16:42:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8272746: ZipFile can't open big file (NegativeArraySizeException)
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1501:
> 
>> 1499:                 // read in the CEN and END
>> 1500:                 if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) {
>> 1501:                     zerror("invalid END header (too large central directory size)");
> 
> This check looks correct. It might be a bit clearer to say that "central directory size too large" rather than "too large central directory size".
> 
> The bug report says that JDK 8 and the native zip handle these zip files, were you able to check that?

I will correct the message as you pointed out.

I checked the JDK8 and Linux unzip commands and found no exceptions or errors. Since JDK9, [JDK-8145260](https://bugs.openjdk.java.net/browse/JDK-8145260) has been modified to significantly change the way zip files are handled, resulting in a different result than jdk8.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6927

From javalists at cbfiddle.com  Fri Dec 24 16:12:00 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 24 Dec 2021 08:12:00 -0800
Subject: a quick question about String
In-Reply-To: <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
Message-ID: <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>

Just when I thought the answer was simple, now it seems more complex.

Are you saying that new would always create a new object but the GC might merge multiple instances of String into a single instance?

Also, if new String() always creates a new instance, then it seems that this statement (from String.java) is not quite right:

Because String objects are immutable they can be shared. For example:

     String str = "abc";
is equivalent to:

     char data[] = {'a', 'b', 'c'};
     String str = new String(data);




> On Dec 23, 2021, at 2:55 PM, Simon Roberts <simon at dancingcloudservices.com> wrote:
> 
> I think there are two things at stake here, one is that as I understand it,
> "new means new", in every case. This is at least partly why the
> constructors on soon-to-be value objects are deprecated; they become
> meaningless. The other is that if the presumption is that we should
> always intern new Strings, I must disagree. Pooling takes time and memory
> to manage, and if there are very few duplicates, it's a waste of both. I
> believe it should be up to the programmer to decide if this is appropriate
> in their situation. Of course, the GC system seems to be capable of
> stepping in in some incarnations, which adds something of a counterexample,
> but that is, if I recall, configurable.
> 
> 
> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
> 
>> never should?as Object can be use as lock.
>> 
>> XenoAmess
>> ________________________________
>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>> Bernd Eckenfels <ecki at zusammenkunft.net>
>> Sent: Friday, December 24, 2021 5:51:55 AM
>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>> core-libs-dev at openjdk.java.net>
>> Subject: Re: a quick question about String
>> 
>> new String() always creates a new instance.
>> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> ________________________________
>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
>> Alan Snyder <javalists at cbfiddle.com>
>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Betreff: a quick question about String
>> 
>> Do the public constructors of String actually do what their documentation
>> says (allocate a new instance), or is there some kind of compiler magic
>> that might avoid allocation?
>> 
>> 
> 
> -- 
> Simon Roberts
> (303) 249 3613
> 


From brian.goetz at oracle.com  Fri Dec 24 16:29:17 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 24 Dec 2021 16:29:17 +0000
Subject: a quick question about String
In-Reply-To: <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>
Message-ID: <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>

As the language currently stands, new means new; it is guaranteed to create a new identity.  (When Valhalla comes along, instances of certain classes will be identity-free, so the meaning of new will change somewhat, but String seems likely to stay as it is.)  

The language is allowed (in some cases required) to intern string _literals_, so the expression

    ?foo? == ?foo?

can be true.  That?s OK because no one said ?new?.  

In your example, the two instances would not be ==, but would be .equals.  But since ?equivalent? is not a precise term, we can have an angels-on-pins debate about whether they are indeed equivalent.  IMO equivalent here means ?for practical purposes?; locking on an arbitrary string which you did not allocate is a silly thing to do, so it is reasonable that the doc opted for a common-sense interpretation of equivalent, rather than a more precise one.  



> On Dec 24, 2021, at 11:12 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> Just when I thought the answer was simple, now it seems more complex.
> 
> Are you saying that new would always create a new object but the GC might merge multiple instances of String into a single instance?
> 
> Also, if new String() always creates a new instance, then it seems that this statement (from String.java) is not quite right:
> 
> Because String objects are immutable they can be shared. For example:
> 
>     String str = "abc";
> is equivalent to:
> 
>     char data[] = {'a', 'b', 'c'};
>     String str = new String(data);
> 
> 
> 
> 
>> On Dec 23, 2021, at 2:55 PM, Simon Roberts <simon at dancingcloudservices.com> wrote:
>> 
>> I think there are two things at stake here, one is that as I understand it,
>> "new means new", in every case. This is at least partly why the
>> constructors on soon-to-be value objects are deprecated; they become
>> meaningless. The other is that if the presumption is that we should
>> always intern new Strings, I must disagree. Pooling takes time and memory
>> to manage, and if there are very few duplicates, it's a waste of both. I
>> believe it should be up to the programmer to decide if this is appropriate
>> in their situation. Of course, the GC system seems to be capable of
>> stepping in in some incarnations, which adds something of a counterexample,
>> but that is, if I recall, configurable.
>> 
>> 
>> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
>> 
>>> never should?as Object can be use as lock.
>>> 
>>> XenoAmess
>>> ________________________________
>>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>>> Bernd Eckenfels <ecki at zusammenkunft.net>
>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>>> core-libs-dev at openjdk.java.net>
>>> Subject: Re: a quick question about String
>>> 
>>> new String() always creates a new instance.
>>> 
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> ________________________________
>>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
>>> Alan Snyder <javalists at cbfiddle.com>
>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Betreff: a quick question about String
>>> 
>>> Do the public constructors of String actually do what their documentation
>>> says (allocate a new instance), or is there some kind of compiler magic
>>> that might avoid allocation?
>>> 
>>> 
>> 
>> -- 
>> Simon Roberts
>> (303) 249 3613
>> 
> 


From xenoamess at gmail.com  Fri Dec 24 16:39:19 2021
From: xenoamess at gmail.com (Xeno Amess)
Date: Sat, 25 Dec 2021 00:39:19 +0800
Subject: a quick question about String
In-Reply-To: <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>
 <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>
Message-ID: <CAFF4x5K1uCveA2qoWRsBxnYi-34mhiYk1e3X-AxfGX0LN8=7Xw@mail.gmail.com>

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

class SyncDemo1 {

    static volatile int count;

    public static void add() {
        synchronized (Demo.getString1()) {
            System.out.println("count1 : " + (count++));
        }
    }

}

class SyncDemo2 {

    static volatile int count;

    public static void add() {
        synchronized (Demo.getString2()) {
            System.out.println("count2 : " + (count++));
        }
    }

}

public class Demo {

    public static String getString1() {
        String str = "abc";
        return str;
    }

    public static String getString2() {
        char data[] = {'a', 'b', 'c'};
        String str = new String(data);
        return str;
    }

    public static void main(String[] args) throws InterruptedException {
        System.out.println("test1");
        ExecutorService executorService1 = Executors.newFixedThreadPool(20);
        for (int i = 0; i < 1000; i++) {
            executorService1.submit(
                    SyncDemo1::add
            );
        }

        ExecutorService executorService2 = Executors.newFixedThreadPool(20);
        for (int i = 0; i < 1000; i++) {
            executorService2.submit(
                    SyncDemo2::add
            );
        }
    }

}


run the codes I send you, at a multi-core machine.
count1 can remain sequential, but count2 not.
That is what I said several hours ago : never should?as Object can be use
as lock.
And String is a kind of Object.


Brian Goetz <brian.goetz at oracle.com> ?2021?12?25??? 00:29???

> As the language currently stands, new means new; it is guaranteed to
> create a new identity.  (When Valhalla comes along, instances of certain
> classes will be identity-free, so the meaning of new will change somewhat,
> but String seems likely to stay as it is.)
>
> The language is allowed (in some cases required) to intern string
> _literals_, so the expression
>
>     ?foo? == ?foo?
>
> can be true.  That?s OK because no one said ?new?.
>
> In your example, the two instances would not be ==, but would be .equals.
> But since ?equivalent? is not a precise term, we can have an angels-on-pins
> debate about whether they are indeed equivalent.  IMO equivalent here means
> ?for practical purposes?; locking on an arbitrary string which you did not
> allocate is a silly thing to do, so it is reasonable that the doc opted for
> a common-sense interpretation of equivalent, rather than a more precise
> one.
>
>
>
> > On Dec 24, 2021, at 11:12 AM, Alan Snyder <javalists at cbfiddle.com>
> wrote:
> >
> > Just when I thought the answer was simple, now it seems more complex.
> >
> > Are you saying that new would always create a new object but the GC
> might merge multiple instances of String into a single instance?
> >
> > Also, if new String() always creates a new instance, then it seems that
> this statement (from String.java) is not quite right:
> >
> > Because String objects are immutable they can be shared. For example:
> >
> >     String str = "abc";
> > is equivalent to:
> >
> >     char data[] = {'a', 'b', 'c'};
> >     String str = new String(data);
> >
> >
> >
> >
> >> On Dec 23, 2021, at 2:55 PM, Simon Roberts <
> simon at dancingcloudservices.com> wrote:
> >>
> >> I think there are two things at stake here, one is that as I understand
> it,
> >> "new means new", in every case. This is at least partly why the
> >> constructors on soon-to-be value objects are deprecated; they become
> >> meaningless. The other is that if the presumption is that we should
> >> always intern new Strings, I must disagree. Pooling takes time and
> memory
> >> to manage, and if there are very few duplicates, it's a waste of both. I
> >> believe it should be up to the programmer to decide if this is
> appropriate
> >> in their situation. Of course, the GC system seems to be capable of
> >> stepping in in some incarnations, which adds something of a
> counterexample,
> >> but that is, if I recall, configurable.
> >>
> >>
> >> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
> >>
> >>> never should?as Object can be use as lock.
> >>>
> >>> XenoAmess
> >>> ________________________________
> >>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
> >>> Bernd Eckenfels <ecki at zusammenkunft.net>
> >>> Sent: Friday, December 24, 2021 5:51:55 AM
> >>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
> >>> core-libs-dev at openjdk.java.net>
> >>> Subject: Re: a quick question about String
> >>>
> >>> new String() always creates a new instance.
> >>>
> >>> Gruss
> >>> Bernd
> >>> --
> >>> http://bernd.eckenfels.net
> >>> ________________________________
> >>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag
> von
> >>> Alan Snyder <javalists at cbfiddle.com>
> >>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> >>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
> >>> Betreff: a quick question about String
> >>>
> >>> Do the public constructors of String actually do what their
> documentation
> >>> says (allocate a new instance), or is there some kind of compiler magic
> >>> that might avoid allocation?
> >>>
> >>>
> >>
> >> --
> >> Simon Roberts
> >> (303) 249 3613
> >>
> >
>
>

From javalists at cbfiddle.com  Fri Dec 24 16:45:25 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 24 Dec 2021 08:45:25 -0800
Subject: a quick question about String
In-Reply-To: <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>
 <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>
Message-ID: <9C19655B-5F6B-4B09-9404-AEB119046C03@cbfiddle.com>

Thanks. That makes sense.

Speaking of Valhalla, how is that coming along? Should I start reading about it now, or would it be better to wait?

  Alan



> On Dec 24, 2021, at 8:29 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> As the language currently stands, new means new; it is guaranteed to create a new identity.  (When Valhalla comes along, instances of certain classes will be identity-free, so the meaning of new will change somewhat, but String seems likely to stay as it is.)  
> 
> The language is allowed (in some cases required) to intern string _literals_, so the expression
> 
>    ?foo? == ?foo?
> 
> can be true.  That?s OK because no one said ?new?.  
> 
> In your example, the two instances would not be ==, but would be .equals.  But since ?equivalent? is not a precise term, we can have an angels-on-pins debate about whether they are indeed equivalent.  IMO equivalent here means ?for practical purposes?; locking on an arbitrary string which you did not allocate is a silly thing to do, so it is reasonable that the doc opted for a common-sense interpretation of equivalent, rather than a more precise one.  
> 
> 
> 
>> On Dec 24, 2021, at 11:12 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> Just when I thought the answer was simple, now it seems more complex.
>> 
>> Are you saying that new would always create a new object but the GC might merge multiple instances of String into a single instance?
>> 
>> Also, if new String() always creates a new instance, then it seems that this statement (from String.java) is not quite right:
>> 
>> Because String objects are immutable they can be shared. For example:
>> 
>>    String str = "abc";
>> is equivalent to:
>> 
>>    char data[] = {'a', 'b', 'c'};
>>    String str = new String(data);
>> 
>> 
>> 
>> 
>>> On Dec 23, 2021, at 2:55 PM, Simon Roberts <simon at dancingcloudservices.com> wrote:
>>> 
>>> I think there are two things at stake here, one is that as I understand it,
>>> "new means new", in every case. This is at least partly why the
>>> constructors on soon-to-be value objects are deprecated; they become
>>> meaningless. The other is that if the presumption is that we should
>>> always intern new Strings, I must disagree. Pooling takes time and memory
>>> to manage, and if there are very few duplicates, it's a waste of both. I
>>> believe it should be up to the programmer to decide if this is appropriate
>>> in their situation. Of course, the GC system seems to be capable of
>>> stepping in in some incarnations, which adds something of a counterexample,
>>> but that is, if I recall, configurable.
>>> 
>>> 
>>> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
>>> 
>>>> never should?as Object can be use as lock.
>>>> 
>>>> XenoAmess
>>>> ________________________________
>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>>>> Bernd Eckenfels <ecki at zusammenkunft.net>
>>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>>>> core-libs-dev at openjdk.java.net>
>>>> Subject: Re: a quick question about String
>>>> 
>>>> new String() always creates a new instance.
>>>> 
>>>> Gruss
>>>> Bernd
>>>> --
>>>> http://bernd.eckenfels.net
>>>> ________________________________
>>>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
>>>> Alan Snyder <javalists at cbfiddle.com>
>>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Betreff: a quick question about String
>>>> 
>>>> Do the public constructors of String actually do what their documentation
>>>> says (allocate a new instance), or is there some kind of compiler magic
>>>> that might avoid allocation?
>>>> 
>>>> 
>>> 
>>> -- 
>>> Simon Roberts
>>> (303) 249 3613
>>> 
>> 
> 


From liangchenblue at gmail.com  Fri Dec 24 19:46:39 2021
From: liangchenblue at gmail.com (-)
Date: Fri, 24 Dec 2021 13:46:39 -0600
Subject: a quick question about String
In-Reply-To: <CAFF4x5K1uCveA2qoWRsBxnYi-34mhiYk1e3X-AxfGX0LN8=7Xw@mail.gmail.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com>
 <D32FE762-8BF1-41E3-955B-707F22A0A051@oracle.com>
 <CAFF4x5K1uCveA2qoWRsBxnYi-34mhiYk1e3X-AxfGX0LN8=7Xw@mail.gmail.com>
Message-ID: <CABe8uE31+8PFJcFvB7dORqdO7L3XOFqDgrt=z1Zocf8Gv1oAcA@mail.gmail.com>

I don't recommend obtaining new String objects by calling the
constructor unless you have specific requirements, such as decode a
byte array with a char set, which is the most frequent use case: new
String(Files.readAllBytes(path), StandardCharsets.UTF_8)

Strings from java files like "abc" are compiled to ldc (load constant)
instructions (as opposed to anew and calling <init> method compiled
from new String()), which provides an already interned string object,
meaning all "abc" references in java code will yield the same String
object.

You can safely use == if you know both string objects you compare are
interned: for example, method names from Method::getName are interned
as well, so InvocationHandler implementations in jdk, such as in
MethodHandleProxies, just compare them directly (significantly faster
than equals if strings don't match), like
(Object)name == "getWrapperInstanceTarget"

This demo proves the constant identity of "load constant" String
objects; in practice, synchronizing on arbitrary String objects is
definitely a bad idea, especially in libraries, just like setting
System.out by random, as it may cause conflicts.

> Are you saying that new would always create a new object but the GC might merge multiple instances of String into a single instance?

About jvm's string optimizations, jvm may make different string
objects with the same content share the backing array in order to
reduce allocation (like what the original poster alan wonders). This
optimization does not alter the identity of the relative string
objects and thus has zero effect on the user end.

Another point about (the slowness of) interning is that the intern
table is a hash table, but unlike jdk hashmaps that feature
red-black-tree buckets once a bucket gets too large, the intern table
uses a linked list and can be quite inefficient when there are too
many strings.

On Fri, Dec 24, 2021 at 10:39 AM Xeno Amess <xenoamess at gmail.com> wrote:
>
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
>
> class SyncDemo1 {
>
>     static volatile int count;
>
>     public static void add() {
>         synchronized (Demo.getString1()) {
>             System.out.println("count1 : " + (count++));
>         }
>     }
>
> }
>
> class SyncDemo2 {
>
>     static volatile int count;
>
>     public static void add() {
>         synchronized (Demo.getString2()) {
>             System.out.println("count2 : " + (count++));
>         }
>     }
>
> }
>
> public class Demo {
>
>     public static String getString1() {
>         String str = "abc";
>         return str;
>     }
>
>     public static String getString2() {
>         char data[] = {'a', 'b', 'c'};
>         String str = new String(data);
>         return str;
>     }
>
>     public static void main(String[] args) throws InterruptedException {
>         System.out.println("test1");
>         ExecutorService executorService1 = Executors.newFixedThreadPool(20);
>         for (int i = 0; i < 1000; i++) {
>             executorService1.submit(
>                     SyncDemo1::add
>             );
>         }
>
>         ExecutorService executorService2 = Executors.newFixedThreadPool(20);
>         for (int i = 0; i < 1000; i++) {
>             executorService2.submit(
>                     SyncDemo2::add
>             );
>         }
>     }
>
> }
>
>
> run the codes I send you, at a multi-core machine.
> count1 can remain sequential, but count2 not.
> That is what I said several hours ago : never should?as Object can be use
> as lock.
> And String is a kind of Object.
>
>
> Brian Goetz <brian.goetz at oracle.com> ?2021?12?25??? 00:29???
>
> > As the language currently stands, new means new; it is guaranteed to
> > create a new identity.  (When Valhalla comes along, instances of certain
> > classes will be identity-free, so the meaning of new will change somewhat,
> > but String seems likely to stay as it is.)
> >
> > The language is allowed (in some cases required) to intern string
> > _literals_, so the expression
> >
> >     ?foo? == ?foo?
> >
> > can be true.  That?s OK because no one said ?new?.
> >
> > In your example, the two instances would not be ==, but would be .equals.
> > But since ?equivalent? is not a precise term, we can have an angels-on-pins
> > debate about whether they are indeed equivalent.  IMO equivalent here means
> > ?for practical purposes?; locking on an arbitrary string which you did not
> > allocate is a silly thing to do, so it is reasonable that the doc opted for
> > a common-sense interpretation of equivalent, rather than a more precise
> > one.
> >
> >
> >
> > > On Dec 24, 2021, at 11:12 AM, Alan Snyder <javalists at cbfiddle.com>
> > wrote:
> > >
> > > Just when I thought the answer was simple, now it seems more complex.
> > >
> > > Are you saying that new would always create a new object but the GC
> > might merge multiple instances of String into a single instance?
> > >
> > > Also, if new String() always creates a new instance, then it seems that
> > this statement (from String.java) is not quite right:
> > >
> > > Because String objects are immutable they can be shared. For example:
> > >
> > >     String str = "abc";
> > > is equivalent to:
> > >
> > >     char data[] = {'a', 'b', 'c'};
> > >     String str = new String(data);
> > >
> > >
> > >
> > >
> > >> On Dec 23, 2021, at 2:55 PM, Simon Roberts <
> > simon at dancingcloudservices.com> wrote:
> > >>
> > >> I think there are two things at stake here, one is that as I understand
> > it,
> > >> "new means new", in every case. This is at least partly why the
> > >> constructors on soon-to-be value objects are deprecated; they become
> > >> meaningless. The other is that if the presumption is that we should
> > >> always intern new Strings, I must disagree. Pooling takes time and
> > memory
> > >> to manage, and if there are very few duplicates, it's a waste of both. I
> > >> believe it should be up to the programmer to decide if this is
> > appropriate
> > >> in their situation. Of course, the GC system seems to be capable of
> > >> stepping in in some incarnations, which adds something of a
> > counterexample,
> > >> but that is, if I recall, configurable.
> > >>
> > >>
> > >> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
> > >>
> > >>> never should?as Object can be use as lock.
> > >>>
> > >>> XenoAmess
> > >>> ________________________________
> > >>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
> > >>> Bernd Eckenfels <ecki at zusammenkunft.net>
> > >>> Sent: Friday, December 24, 2021 5:51:55 AM
> > >>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
> > >>> core-libs-dev at openjdk.java.net>
> > >>> Subject: Re: a quick question about String
> > >>>
> > >>> new String() always creates a new instance.
> > >>>
> > >>> Gruss
> > >>> Bernd
> > >>> --
> > >>> http://bernd.eckenfels.net
> > >>> ________________________________
> > >>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag
> > von
> > >>> Alan Snyder <javalists at cbfiddle.com>
> > >>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> > >>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
> > >>> Betreff: a quick question about String
> > >>>
> > >>> Do the public constructors of String actually do what their
> > documentation
> > >>> says (allocate a new instance), or is there some kind of compiler magic
> > >>> that might avoid allocation?
> > >>>
> > >>>
> > >>
> > >> --
> > >> Simon Roberts
> > >> (303) 249 3613
> > >>
> > >
> >
> >

From duke at openjdk.java.net  Sun Dec 26 17:38:39 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 26 Dec 2021 17:38:39 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
Message-ID: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>

Implementation of JDK-8279283

-------------

Commit messages:
 - BufferedInputStream::transferTo

Changes: https://git.openjdk.java.net/jdk/pull/6935/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279283
  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Sun Dec 26 20:10:10 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 26 Dec 2021 20:10:10 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
Message-ID: <EcDyByb6rKUGoedo9lICM7Arz2xXv4ybJYlBxbfM4us=.f13f742a-2ed1-4eaf-a0ef-aa51e0157538@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop
> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5481

From serb at openjdk.java.net  Sun Dec 26 22:14:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 26 Dec 2021 22:14:15 GMT
Subject: Integrated: 8279134: Fix Amazon copyright in various files
In-Reply-To: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
References: <JcaV2Md2ympuLnRHpecLgQWMYT0JipOgDHapxBMctvA=.c84bd6a1-5bf7-4b35-b668-a2890499bb09@github.com>
Message-ID: <Yqh6Q3To6ZJ0yiD-eoUPnKD4Vn23Gy8ivvp66wdiNdM=.17ed9926-2a4f-46e9-91a1-4d40856a10a2@github.com>

On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
> 
> Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year):
> 
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." 
> 
> @simonis @phohensee

This pull request has now been integrated.

Changeset: 7fea1032
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7fea10327ed27fcf8eae474ca5b15c3b4bafff2a
Stats:     15 lines in 14 files changed: 0 ins; 1 del; 14 mod

8279134: Fix Amazon copyright in various files

Reviewed-by: xliu, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/6915

From alanb at openjdk.java.net  Mon Dec 27 08:53:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 27 Dec 2021 08:53:14 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <9250pLGnax5ry8f9bMhZNTKh6EFu15Iia_zt1O6qtaA=.f628c452-e517-410a-92bc-28cc24ac8f85@github.com>

On Sun, 26 Dec 2021 17:30:41 GMT, Markus KARG <duke at openjdk.java.net> wrote:

> Implementation of JDK-8279283

BIS is not specified to be thread safe but the existing read/write operations are. If transferTo is overridden then this is an area that will require close attention.

Have you surveyed the existing tests to see if transferTo is invoked on a BIS? New tests may be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 09:21:52 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 09:21:52 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
 [v2]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <jWLvgqDnQniYlmeuhOU3hWwP37arFQQGe1eVOKgz2mE=.f7432dc2-c89c-4b0e-9e89-7637ab9b7b9d@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  synchronized BufferedInputStream::transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6935/files
  - new: https://git.openjdk.java.net/jdk/pull/6935/files/2831898e..8dac240d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 09:33:10 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 09:33:10 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
In-Reply-To: <9250pLGnax5ry8f9bMhZNTKh6EFu15Iia_zt1O6qtaA=.f628c452-e517-410a-92bc-28cc24ac8f85@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <9250pLGnax5ry8f9bMhZNTKh6EFu15Iia_zt1O6qtaA=.f628c452-e517-410a-92bc-28cc24ac8f85@github.com>
Message-ID: <VOgL-OVFOevadvzULhcCibKNTEnhERBrvmurvGlifnI=.7781b521-a652-45b7-ac18-06a218a97f70@github.com>

On Mon, 27 Dec 2021 08:50:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> BIS is not specified to be thread safe but the existing read/write operations are. If transferTo is overridden then this is an area that will require close attention.

In analogy to the other read/write operations I now have synchronized transferTo in https://github.com/openjdk/jdk/pull/6935/commits/8dac240d2716a9d14c997ea62b7f96637acc8d66 to be on the safe side.

> Have you surveyed the existing tests to see if transferTo is invoked on a BIS? New tests may be needed.

Did not find an existing test for BIS.transferTo, so I will write a new test for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 13:04:10 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 13:04:10 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
 [v3]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <MWRRx9jk_lGWlum2Yz7MD-Xp2BbML0bkR9W0wMYKyQ4=.e8be318a-5765-4555-938b-02be066fb4e2@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  test for BufferedInputStream.transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6935/files
  - new: https://git.openjdk.java.net/jdk/pull/6935/files/8dac240d..fbc5def7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=01-02

  Stats: 210 lines in 1 file changed: 210 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 13:07:14 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 13:07:14 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
In-Reply-To: <VOgL-OVFOevadvzULhcCibKNTEnhERBrvmurvGlifnI=.7781b521-a652-45b7-ac18-06a218a97f70@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <9250pLGnax5ry8f9bMhZNTKh6EFu15Iia_zt1O6qtaA=.f628c452-e517-410a-92bc-28cc24ac8f85@github.com>
 <VOgL-OVFOevadvzULhcCibKNTEnhERBrvmurvGlifnI=.7781b521-a652-45b7-ac18-06a218a97f70@github.com>
Message-ID: <fZENBio3NuMHVf_uaw8V1B-Y4HVROCis5xd7AEvhbIk=.e86dc831-fe60-47ef-83ae-decdd89d070d@github.com>

On Mon, 27 Dec 2021 09:30:25 GMT, Markus KARG <duke at openjdk.java.net> wrote:

> Have you surveyed the existing tests to see if transferTo is invoked on a BIS? New tests may be needed.

I have provided a test for BIS.transferTo in https://github.com/openjdk/jdk/pull/6935/commits/fbc5def7af6634b630c0bf423d8c7a2715b25cf4.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 13:33:53 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 13:33:53 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
 [v4]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <IIe9joKmINmpNNuZYd6eXmAoMCnuBtRts3aNbn6iZA8=.1daf6622-742c-4176-b6df-c662594d4eb4@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  removed unused code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6935/files
  - new: https://git.openjdk.java.net/jdk/pull/6935/files/fbc5def7..304a4aa4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.java.net/jdk/pull/6935

From duke at openjdk.java.net  Mon Dec 27 13:43:12 2021
From: duke at openjdk.java.net (Markus KARG)
Date: Mon, 27 Dec 2021 13:43:12 GMT
Subject: RFR: 8279283 - (ch) BufferedInputStream should override transferTo
 [v5]
In-Reply-To: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
Message-ID: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>

> Implementation of JDK-8279283

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  fixed missing BufferedInputStream

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6935/files
  - new: https://git.openjdk.java.net/jdk/pull/6935/files/304a4aa4..0d3528ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6935.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935

PR: https://git.openjdk.java.net/jdk/pull/6935

From lancea at openjdk.java.net  Mon Dec 27 18:12:12 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 27 Dec 2021 18:12:12 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
Message-ID: <y-T2j9Cuoi5S6qUihx-FbhhIkPZ6e9HIbt8i3NnnvVs=.09771803-cd05-46a2-ac63-19f710127792@github.com>

On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop
> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5481

From duke at openjdk.java.net  Mon Dec 27 20:07:10 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 27 Dec 2021 20:07:10 GMT
Subject: RFR: 8274811: Remove superfluous use of boxing in java.base
In-Reply-To: <v9rzeOBEguCXoOFqzMfHzK7Tksg9bq0Il6f-2h6gQDk=.f42c7ec5-f09b-4d14-afdb-5f56f222208b@github.com>
References: <KzR5MeAXRP5JToOBbUvQnySh-BuzdHU8e_E3futzSrA=.bff2bc38-cecf-42a2-92b7-538fadbed808@github.com>
 <v9rzeOBEguCXoOFqzMfHzK7Tksg9bq0Il6f-2h6gQDk=.f42c7ec5-f09b-4d14-afdb-5f56f222208b@github.com>
Message-ID: <8IjGbdX2WK-ehSvj8t2tOXFwizmWpqX_iXIvErThatQ=.e201c353-ed8a-4789-9c8e-3d6b37097b42@github.com>

On Sat, 27 Nov 2021 17:41:58 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Usages of primitive types should be preferred and makes code easier to read.
>> Similar cleanups:
>> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop
>> 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset
>
> let's wait for review a bit more

@turbanoff I think now you can integrate the PR

-------------

PR: https://git.openjdk.java.net/jdk/pull/5481

From fabrice.tiercelin at yahoo.fr  Wed Dec 29 06:43:21 2021
From: fabrice.tiercelin at yahoo.fr (Fabrice Tiercelin)
Date: Wed, 29 Dec 2021 06:43:21 +0000 (UTC)
Subject: Type narrowing security leak
References: <417610419.33595.1640760201406.ref@mail.yahoo.com>
Message-ID: <417610419.33595.1640760201406@mail.yahoo.com>

Greetings,
Any Java application may be concerned by a hacker attack using a type narrowing leak. If a program does the following things in this order:
?- Assert that a numerical id is allowed?- Do a type narrowing among other things, even followed by a type widening?- Do an action with the numerical id
...the hacker can do forbidden actions. Let's say that a given user doesn't have rights to change an amount for the id 63:
public void changeAmount(long userId, double newAmount) throws IllegalArgumentException {? isUserIdAllowedOrThrowException(userId); // userId = 4294967359

 ? int theUserId = (int) userId; // theUserId = 63  ? userId = theUserId; // userId = 63
? doChangeAmount(userId, newAmount); // userId = 63
}
It will fail passing 63 but it will success passing 4294967359 because 4_294_967_359 is narrowed into 63. Let's call?4_294_967_359  a?rebound of 63. 4294967359 can be retrieved in few seconds by a basic program like this:
public class MyClass {
??? public static void main(String args[]) {
????? long targettedNumber = 63;
???? ?
 ????? for (long rebound = Integer.MAX_VALUE + 1; true; rebound++) {????????? int typeNarrowing = (int) rebound;
????????? long typeWidening = typeNarrowing;
???????? ?
????????? if (typeWidening == targettedNumber) {
????????????? System.out.println("Rebound for " + targettedNumber + " found: " + rebound);
????????????? return;
????????? }
????? }
??? }
}
And it can be optimized. It works for any type narrowing. It not only works for numerical id but also for flags. If a numerical value should contain or not several flags, you can search a rebound among billions of rebounds until you find one with the perfect features. All the Java versions are concerned. The security layer can even be coded in another programming language.

To fix it, I suggest to add a test just before the type narrowing in the bytecode. The test verifies if the type narrowing will alter the numerical value. If true, it throws an unchecked exception or an error. Otherwise, it continues as currently. Note that it changes the behavior but the current behavior is dangerous, useless and is a failing case. You can add a compiler option to restore the original behavior but the new behavior should be the default.

Best regards,Fabrice TIERCELIN


From openjdk at icemanx.nl  Wed Dec 29 10:32:37 2021
From: openjdk at icemanx.nl (Rob Spoor)
Date: Wed, 29 Dec 2021 11:32:37 +0100
Subject: Type narrowing security leak
In-Reply-To: <417610419.33595.1640760201406@mail.yahoo.com>
References: <417610419.33595.1640760201406.ref@mail.yahoo.com>
 <417610419.33595.1640760201406@mail.yahoo.com>
Message-ID: <ba3d61c5-d7b9-b4c7-387d-fa0f928a4d42@icemanx.nl>

This isn't a security leak in Java (because that would mean it would be 
a security leak in any language that supports narrowing). This is a 
security leak in the application that does the narrowing. Developers 
should be aware that narrowing can change values. And furthermore, I 
don't think there are many developers that would perform this bounds 
check before the narrowing. Well, at least I wouldn't.

The fix you suggest could break many, many applications that use 
narrowing that actually *want* the value to be changed. An example is 
reading input streams byte-by-byte: the result is an int between 0 and 
255 (inclusive), or -1 for EOF. If the result is not -1, the result is 
almost always cast to a byte. The suggested fix would break for all 
values between 128 and 255 (inclusive) - half the available values.

I would rather have developers fix this in their code. There's already a 
method for "checked narrowing" from long to int: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#toIntExact(long).


Rob


On 29/12/2021 07:43, Fabrice Tiercelin wrote:
> Greetings,
> Any Java application may be concerned by a hacker attack using a type narrowing leak. If a program does the following things in this order:
>  ?- Assert that a numerical id is allowed?- Do a type narrowing among other things, even followed by a type widening?- Do an action with the numerical id
> ...the hacker can do forbidden actions. Let's say that a given user doesn't have rights to change an amount for the id 63:
> public void changeAmount(long userId, double newAmount) throws IllegalArgumentException {? isUserIdAllowedOrThrowException(userId); // userId = 4294967359
> 
>   ? int theUserId = (int) userId; // theUserId = 63  ? userId = theUserId; // userId = 63
>  ? doChangeAmount(userId, newAmount); // userId = 63
> }
> It will fail passing 63 but it will success passing 4294967359 because 4_294_967_359 is narrowed into 63. Let's call?4_294_967_359  a?rebound of 63. 4294967359 can be retrieved in few seconds by a basic program like this:
> public class MyClass {
>  ??? public static void main(String args[]) {
>  ????? long targettedNumber = 63;
>        
>   ????? for (long rebound = Integer.MAX_VALUE + 1; true; rebound++) {????????? int typeNarrowing = (int) rebound;
>  ????????? long typeWidening = typeNarrowing;
>            
>  ????????? if (typeWidening == targettedNumber) {
>  ????????????? System.out.println("Rebound for " + targettedNumber + " found: " + rebound);
>  ????????????? return;
>  ????????? }
>  ????? }
>  ??? }
> }
> And it can be optimized. It works for any type narrowing. It not only works for numerical id but also for flags. If a numerical value should contain or not several flags, you can search a rebound among billions of rebounds until you find one with the perfect features. All the Java versions are concerned. The security layer can even be coded in another programming language.
> 
> To fix it, I suggest to add a test just before the type narrowing in the bytecode. The test verifies if the type narrowing will alter the numerical value. If true, it throws an unchecked exception or an error. Otherwise, it continues as currently. Note that it changes the behavior but the current behavior is dangerous, useless and is a failing case. You can add a compiler option to restore the original behavior but the new behavior should be the default.
> 
> Best regards,Fabrice TIERCELIN
> 


From fabrice.tiercelin at yahoo.fr  Thu Dec 30 12:13:18 2021
From: fabrice.tiercelin at yahoo.fr (Fabrice Tiercelin)
Date: Thu, 30 Dec 2021 12:13:18 +0000 (UTC)
Subject: Type narrowing security leak
In-Reply-To: <ba3d61c5-d7b9-b4c7-387d-fa0f928a4d42@icemanx.nl>
References: <417610419.33595.1640760201406.ref@mail.yahoo.com>
 <417610419.33595.1640760201406@mail.yahoo.com>
 <ba3d61c5-d7b9-b4c7-387d-fa0f928a4d42@icemanx.nl>
Message-ID: <856578817.213106.1640866398894@mail.yahoo.com>

 Hi,

    Le mercredi 29 d?cembre 2021, 11:35:12 UTC+1, Rob Spoor <openjdk at icemanx.nl> a ?crit :  
> An example is 
> reading input streams byte-by-byte: the result is an int between 0 and > 255 (inclusive), or -1 for EOF. If the result is not -1, the result is > almost always cast to a byte 


Does your example mean that a whole virus can bypass an antivirus this way?
Fabrice


On 29/12/2021 07:43, Fabrice Tiercelin wrote:
> Greetings,
> Any Java application may be concerned by a hacker attack using a type narrowing leak. If a program does the following things in this order:
>? ?- Assert that a numerical id is allowed?- Do a type narrowing among other things, even followed by a type widening?- Do an action with the numerical id
> ...the hacker can do forbidden actions. Let's say that a given user doesn't have rights to change an amount for the id 63:
> public void changeAmount(long userId, double newAmount) throws IllegalArgumentException {? isUserIdAllowedOrThrowException(userId); // userId = 4294967359
> 
>? ? int theUserId = (int) userId; // theUserId = 63? ? userId = theUserId; // userId = 63
>? ? doChangeAmount(userId, newAmount); // userId = 63
> }
> It will fail passing 63 but it will success passing 4294967359 because 4_294_967_359 is narrowed into 63. Let's call?4_294_967_359? a?rebound of 63. 4294967359 can be retrieved in few seconds by a basic program like this:
> public class MyClass {
>? ??? public static void main(String args[]) {
>? ????? long targettedNumber = 63;
>? ? ? ? 
>? ????? for (long rebound = Integer.MAX_VALUE + 1; true; rebound++) {????????? int typeNarrowing = (int) rebound;
>? ????????? long typeWidening = typeNarrowing;
>? ? ? ? ? ? 
>? ????????? if (typeWidening == targettedNumber) {
>? ????????????? System.out.println("Rebound for " + targettedNumber + " found: " + rebound);
>? ????????????? return;
>? ????????? }
>? ????? }
>? ??? }
> }
> And it can be optimized. It works for any type narrowing. It not only works for numerical id but also for flags. If a numerical value should contain or not several flags, you can search a rebound among billions of rebounds until you find one with the perfect features. All the Java versions are concerned. The security layer can even be coded in another programming language.
> 
> To fix it, I suggest to add a test just before the type narrowing in the bytecode. The test verifies if the type narrowing will alter the numerical value. If true, it throws an unchecked exception or an error. Otherwise, it continues as currently. Note that it changes the behavior but the current behavior is dangerous, useless and is a failing case. You can add a compiler option to restore the original behavior but the new behavior should be the default.
> 
> Best regards,Fabrice TIERCELIN
> 

  

From openjdk at icemanx.nl  Thu Dec 30 12:37:30 2021
From: openjdk at icemanx.nl (Rob Spoor)
Date: Thu, 30 Dec 2021 13:37:30 +0100
Subject: Type narrowing security leak
In-Reply-To: <856578817.213106.1640866398894@mail.yahoo.com>
References: <417610419.33595.1640760201406.ref@mail.yahoo.com>
 <417610419.33595.1640760201406@mail.yahoo.com>
 <ba3d61c5-d7b9-b4c7-387d-fa0f928a4d42@icemanx.nl>
 <856578817.213106.1640866398894@mail.yahoo.com>
Message-ID: <274e8cbf-2432-f75f-e421-4806fee13d27@icemanx.nl>

No it doesn't. It's still the same byte. However, the 0 to 255 range is 
for unsigned bytes, a type that does exist in some other language like 
C. In Java bytes are signed, so the same value is represented 
differently. However, both 200 (unsigned) and -56 (signed) represent the 
same binary value: 1100_1000.


On 30/12/2021 13:13, Fabrice Tiercelin wrote:
>   Hi,
> 
>      Le mercredi 29 d?cembre 2021, 11:35:12 UTC+1, Rob Spoor <openjdk at icemanx.nl> a ?crit :
>> An example is
>> reading input streams byte-by-byte: the result is an int between 0 and > 255 (inclusive), or -1 for EOF. If the result is not -1, the result is > almost always cast to a byte
> 
> 
> Does your example mean that a whole virus can bypass an antivirus this way?
> Fabrice
> 
> 
> On 29/12/2021 07:43, Fabrice Tiercelin wrote:
>> Greetings,
>> Any Java application may be concerned by a hacker attack using a type narrowing leak. If a program does the following things in this order:
>>  ? ?- Assert that a numerical id is allowed?- Do a type narrowing among other things, even followed by a type widening?- Do an action with the numerical id
>> ...the hacker can do forbidden actions. Let's say that a given user doesn't have rights to change an amount for the id 63:
>> public void changeAmount(long userId, double newAmount) throws IllegalArgumentException {? isUserIdAllowedOrThrowException(userId); // userId = 4294967359
>>
>>  ? ? int theUserId = (int) userId; // theUserId = 63? ? userId = theUserId; // userId = 63
>>  ? ? doChangeAmount(userId, newAmount); // userId = 63
>> }
>> It will fail passing 63 but it will success passing 4294967359 because 4_294_967_359 is narrowed into 63. Let's call?4_294_967_359? a?rebound of 63. 4294967359 can be retrieved in few seconds by a basic program like this:
>> public class MyClass {
>>  ? ??? public static void main(String args[]) {
>>  ? ????? long targettedNumber = 63;
>>          
>>  ? ????? for (long rebound = Integer.MAX_VALUE + 1; true; rebound++) {????????? int typeNarrowing = (int) rebound;
>>  ? ????????? long typeWidening = typeNarrowing;
>>              
>>  ? ????????? if (typeWidening == targettedNumber) {
>>  ? ????????????? System.out.println("Rebound for " + targettedNumber + " found: " + rebound);
>>  ? ????????????? return;
>>  ? ????????? }
>>  ? ????? }
>>  ? ??? }
>> }
>> And it can be optimized. It works for any type narrowing. It not only works for numerical id but also for flags. If a numerical value should contain or not several flags, you can search a rebound among billions of rebounds until you find one with the perfect features. All the Java versions are concerned. The security layer can even be coded in another programming language.
>>
>> To fix it, I suggest to add a test just before the type narrowing in the bytecode. The test verifies if the type narrowing will alter the numerical value. If true, it throws an unchecked exception or an error. Otherwise, it continues as currently. Note that it changes the behavior but the current behavior is dangerous, useless and is a failing case. You can add a compiler option to restore the original behavior but the new behavior should be the default.
>>
>> Best regards,Fabrice TIERCELIN

From alexander.scherbatiy at bell-sw.com  Thu Dec 30 16:12:11 2021
From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy)
Date: Thu, 30 Dec 2021 19:12:11 +0300
Subject: a quick question about String
In-Reply-To: <CACcefge-YY+B7GkZdkp-pEp7Xbq3KvSva8kCfCUdPciw-hDwpQ@mail.gmail.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <CACcefge-YY+B7GkZdkp-pEp7Xbq3KvSva8kCfCUdPciw-hDwpQ@mail.gmail.com>
Message-ID: <3c5244a8-5656-f24b-e4fc-e8d0fa188b2e@bell-sw.com>

On 12/24/21 10:33 AM, Enrico Olivelli wrote:

> Alan,
> are you talking about the fact that you cannot "wrap" an existing
> byte[] that you know that you are already encoded ?
>
> In that case the main problem is that the String is supposed to be
> immutable and when you pass the byte[] it must be copied in order to
> prevent someone else to modify the contents of the array behind the String

In java desktop where are arrays which values once created are not 
updated anymore.
It needs to make a defensive copy of such arrays every time when the 
arrays are used
by other classes to prevent them from being modified outside (InputEvent 
[1],? SunFontManager [2], JOptionPane [3]).

Would it be useful to have some kind of an immutable array in Java language
which works in the same way as ordinary array except it is not to 
possible to change
its values after creation?

[1] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/java/awt/event/InputEvent.java#L218
[2] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/sun/font/SunFontManager.java#L3337
[3] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/javax/swing/JOptionPane.java#L2010

Thanks,
Alexander.
> Enrico
>
> Il giorno gio 23 dic 2021 alle ore 23:56 Simon Roberts
> <simon at dancingcloudservices.com> ha scritto:
>> I think there are two things at stake here, one is that as I understand it,
>> "new means new", in every case. This is at least partly why the
>> constructors on soon-to-be value objects are deprecated; they become
>> meaningless. The other is that if the presumption is that we should
>> always intern new Strings, I must disagree. Pooling takes time and memory
>> to manage, and if there are very few duplicates, it's a waste of both. I
>> believe it should be up to the programmer to decide if this is appropriate
>> in their situation. Of course, the GC system seems to be capable of
>> stepping in in some incarnations, which adds something of a counterexample,
>> but that is, if I recall, configurable.
>>
>>
>> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
>>
>>> never should?as Object can be use as lock.
>>>
>>> XenoAmess
>>> ________________________________
>>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>>> Bernd Eckenfels <ecki at zusammenkunft.net>
>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>>> core-libs-dev at openjdk.java.net>
>>> Subject: Re: a quick question about String
>>>
>>> new String() always creates a new instance.
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> ________________________________
>>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
>>> Alan Snyder <javalists at cbfiddle.com>
>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Betreff: a quick question about String
>>>
>>> Do the public constructors of String actually do what their documentation
>>> says (allocate a new instance), or is there some kind of compiler magic
>>> that might avoid allocation?
>>>
>>>
>> --
>> Simon Roberts
>> (303) 249 3613

From info at j-kuhn.de  Thu Dec 30 16:37:43 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Thu, 30 Dec 2021 17:37:43 +0100
Subject: a quick question about String
In-Reply-To: <3c5244a8-5656-f24b-e4fc-e8d0fa188b2e@bell-sw.com>
References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com>
 <AM9P193MB1142EFAF4825918DDBDB21D1FF7E9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <LO2P123MB1934BA77ECA3CD93DF8390E0AF7E9@LO2P123MB1934.GBRP123.PROD.OUTLOOK.COM>
 <CADsQA7iRayE9FKW4J2n=mEGiszky5Zepb1E89movqGUjTsEBrw@mail.gmail.com>
 <CACcefge-YY+B7GkZdkp-pEp7Xbq3KvSva8kCfCUdPciw-hDwpQ@mail.gmail.com>
 <3c5244a8-5656-f24b-e4fc-e8d0fa188b2e@bell-sw.com>
Message-ID: <9032f0d8-613e-66da-8e6e-3b7ade33e2e9@j-kuhn.de>

You are looking for Frozen Arrays: https://openjdk.java.net/jeps/8261007

- Johannes

On 30-Dec-21 17:12, Alexander Scherbatiy wrote:
> On 12/24/21 10:33 AM, Enrico Olivelli wrote:
> 
>> Alan,
>> are you talking about the fact that you cannot "wrap" an existing
>> byte[] that you know that you are already encoded ?
>>
>> In that case the main problem is that the String is supposed to be
>> immutable and when you pass the byte[] it must be copied in order to
>> prevent someone else to modify the contents of the array behind the 
>> String
> 
> In java desktop where are arrays which values once created are not 
> updated anymore.
> It needs to make a defensive copy of such arrays every time when the 
> arrays are used
> by other classes to prevent them from being modified outside (InputEvent 
> [1],? SunFontManager [2], JOptionPane [3]).
> 
> Would it be useful to have some kind of an immutable array in Java language
> which works in the same way as ordinary array except it is not to 
> possible to change
> its values after creation?
> 
> [1] 
> https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/java/awt/event/InputEvent.java#L218 
> 
> [2] 
> https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/sun/font/SunFontManager.java#L3337 
> 
> [3] 
> https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/javax/swing/JOptionPane.java#L2010 
> 
> 
> Thanks,
> Alexander.
>> Enrico
>>
>> Il giorno gio 23 dic 2021 alle ore 23:56 Simon Roberts
>> <simon at dancingcloudservices.com> ha scritto:
>>> I think there are two things at stake here, one is that as I 
>>> understand it,
>>> "new means new", in every case. This is at least partly why the
>>> constructors on soon-to-be value objects are deprecated; they become
>>> meaningless. The other is that if the presumption is that we should
>>> always intern new Strings, I must disagree. Pooling takes time and 
>>> memory
>>> to manage, and if there are very few duplicates, it's a waste of both. I
>>> believe it should be up to the programmer to decide if this is 
>>> appropriate
>>> in their situation. Of course, the GC system seems to be capable of
>>> stepping in in some incarnations, which adds something of a 
>>> counterexample,
>>> but that is, if I recall, configurable.
>>>
>>>
>>> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoamess at gmail.com> wrote:
>>>
>>>> never should?as Object can be use as lock.
>>>>
>>>> XenoAmess
>>>> ________________________________
>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>>>> Bernd Eckenfels <ecki at zusammenkunft.net>
>>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>>>> core-libs-dev at openjdk.java.net>
>>>> Subject: Re: a quick question about String
>>>>
>>>> new String() always creates a new instance.
>>>>
>>>> Gruss
>>>> Bernd
>>>> -- 
>>>> http://bernd.eckenfels.net
>>>> ________________________________
>>>> Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von
>>>> Alan Snyder <javalists at cbfiddle.com>
>>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>>> An: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Betreff: a quick question about String
>>>>
>>>> Do the public constructors of String actually do what their 
>>>> documentation
>>>> says (allocate a new instance), or is there some kind of compiler magic
>>>> that might avoid allocation?
>>>>
>>>>
>>> -- 
>>> Simon Roberts
>>> (303) 249 3613

From hschreiber at openjdk.java.net  Fri Dec 31 08:35:11 2021
From: hschreiber at openjdk.java.net (Hendrik Schreiber)
Date: Fri, 31 Dec 2021 08:35:11 GMT
Subject: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs
In-Reply-To: <T9RRoppb3fcLUUDp5ULxQ3j5yRzu5J-YRdmhuwNZSM8=.28f56130-dca3-4e06-a790-ca4ba86da982@github.com>
References: <DXqYTIapXIiSRwOWNL6b-ZvDhxjlH4swj6880guHOG4=.b578edd5-fd66-4399-bc81-ff86f17371cd@github.com>
 <T9RRoppb3fcLUUDp5ULxQ3j5yRzu5J-YRdmhuwNZSM8=.28f56130-dca3-4e06-a790-ca4ba86da982@github.com>
Message-ID: <KvxaVAt9jwk3WuA0pI2pn-atBXJNlvUPeBXpmLlqZYQ=.4522cbf6-2f3f-4157-871a-8a5342224bd0@github.com>

On Tue, 9 Nov 2021 14:39:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Trivial improvement.
>> 
>> Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`.
>> Repeat (again) in the code example that the `State` `Runnable `should be implemented as static class and not reference the instance to be cleaned, to make the point even more clear to those people who never read the javadoc *prose*.
>> 
>> I have signed the OCA a while back as [hschreiber](https://openjdk.java.net/census#hschreiber).
>
> As for compilable code, this may be a good place to use Snippets.  
> [JEP 413: Code Snippets in Java API Documentation](https://openjdk.java.net/jeps/413)
> They are new but may offer some value add here.
> 
> Good standalone examples aren't always good programming practice.

@RogerRiggs @mlchung Could either of you please sponsor this? Thanks so much and hopefully a great start into 2022!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6076